I like XHLT <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Oh and Cagey, any word on whether you'd like me to do the docs?
<!--QuoteBegin-Reve+Feb 5 2004, 03:30 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Feb 5 2004, 03:30 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I like XHLT <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Oh and Cagey, any word on whether you'd like me to do the docs?
Reve <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Actually, that'd be a big help; I'd like to remain the final editor on the docs, but there's a lot of work to be done -- email me with any starting questions and let me know what resources you'll need.
What I'd like to see initially is text on the usage of each optional parameter. A comprehensive list of error messages would also be nice, but that's much less of a priority for the time being.
<!--QuoteBegin-amckern+Feb 11 2004, 03:12 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (amckern @ Feb 11 2004, 03:12 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> When i complied the map, it came up with a leek in hull 1,2,3, etc -using max view of defalt 4096
When i made the max viewable distance 9999999999, (10 9's) it had no leek.
Can some one please let me know why this is? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Sounds like a bug -- I'll look into it.
<!--QuoteBegin-XP-Cagey+Feb 11 2004, 06:32 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Feb 11 2004, 06:32 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin-amckern+Feb 11 2004, 03:12 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (amckern @ Feb 11 2004, 03:12 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> When i complied the map, it came up with a leek in hull 1,2,3, etc -using max view of defalt 4096
When i made the max viewable distance 9999999999, (10 9's) it had no leek.
Can some one please let me know why this is? <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Sounds like a bug -- I'll look into it. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I always get a leak when I have things past the view distance. I use p12 though.
you may want to leave 256 units of space just to make sure it wasn't a clipping issue somehow. Also you might want to PM cagey and see if he wants a copy of the .map file that generated this error.
Im being asked for MSVCP71.dll for my compile, and I can't find it! Help please lol. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
<!--QuoteBegin-Azraiel+Feb 12 2004, 02:16 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Azraiel @ Feb 12 2004, 02:16 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Im being asked for MSVCP71.dll for my compile, and I can't find it! Help please lol. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> It should have been in the download <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo-->
i would like to post a bug: infestation piles seem to be destroying my clipping hulls. normally i make them world brush so that they dont take up entities. ina hive rom im playing with this casues teh clip hull to become insane, unless the piles are put into an entity. ill be poting a fixed and broken .map
<a href='http://maps.confusionville.net/files/Bugged_maps.zip' target='_blank'>THe zip containing two broken .maps</a>
<!--QuoteBegin-confused!+Feb 20 2004, 02:57 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (confused! @ Feb 20 2004, 02:57 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> i would like to post a bug: infestation piles seem to be destroying my clipping hulls. normally i make them world brush so that they dont take up entities. ina hive rom im playing with this casues teh clip hull to become insane, unless the piles are put into an entity. ill be poting a fixed and broken .map
<a href='http://maps.confusionville.net/files/Bugged_maps.zip' target='_blank'>THe zip containing two broken .maps</a> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Thanks -- I'll get on this ASAP.
The problem you're having Confused! isn't in the compile tools but your map. You've got some invalid brushes that are causing problems. What's causing the difference in the maps you posted is this brush *Points to attached picture* - It's invalid in the bugged map but okay in the fixed map, whether the other ones are entities or not doesn't seem to make a difference.
You've got some other brush problems too, Quark reports a leak while the compile tools do not, which generally indicated some other less serious brush problems, (such as a concave brush with gets deformed during compiling but does not actually create a leak). Also during compiling HLRad gave this error "hlrad: Error: for Face 579 (texture wall_panelsb) at hlrad: Error: Bad surface extents (17 x 5) Check the file ZHLTProblems.html for a detailed explanation of this problem"
P.S. - Keep things on the grid! "-807.850232 -836.401440 -1.552555" is just <i>asking</i> for trouble.
P.P.S - You've got some Leaf Portal saw into leaf problems too.
Cagey: Does the "Could you please break my tools?" still apply to p13? I might be able to help <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
<!--QuoteBegin-Shadowics+Feb 21 2004, 03:49 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Shadowics @ Feb 21 2004, 03:49 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey: Does the "Could you please break my tools?" still apply to p13? I might be able to help <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Yeah -- I'm still trying to track down the sketchy bug that's causing clip hull problems after brush expansion.
im very much aware that some of my brushes are suspect, but the resulting behavior is bizare anyway. the point is not that i know how to fixthe problem. it its that while hammer throws no errors, the map compiles wrong. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> oh, the behavior is that both the diagonal walls extend infinately though the top one retains the window.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->oh, the behavior is that both the diagonal walls extend infinately though the top one retains the window. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<!--QuoteBegin-confused!+Feb 21 2004, 02:34 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (confused! @ Feb 21 2004, 02:34 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> The point is not that i know how to fix the problem. it its that while hammer throws no errors, the map compiles wrong. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I may not be able to do anything from looking at the map file exported by Hammer; it would take looking at the rmf before export in some to determine which faces / brushes are actually broken since the map file contains only the minimum amount of information necessary to desscribe a brush; I'll take a close look at the bad file in the zip and see if there are any tests I can run to detect and report errors. The invalid brushes could be described in the map file in a manner that actually requires those invisible walls to be generated in the clip hulls.
The correct solution would eventually be to autodetect problems in the rmf file and throw nonfatal errors that stop HLRAD and HLVIS from running and taking up useless CPU time; in the meantime HLFix will have to take on the role of warning users about bad geometry.
Okay. I knew that I had an old room laying around that was giving me some clipping problems. It is a bit convoluted but doesn't appear to have any invalid brushes and seems to provide a clear clipping issue. I also compared the original file with the exported .map and there doesn't appear to be any difference. (I use Quark)
There are never any errors during the compile. When compiled with -cliptype legacy or smallest the map appears fine, no errors with the clipping that I could notice. With -cliptype precise, simple, or normalized there is a big block of clip up at the top part. Just walk up the spiral stairs and you'll hit an invisible wall.
(Careful though, it's got real bad r_speeds and worse compile time if you tried to do a full vis/rad <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> )
I also had some variations of this room that had worse clipping issues - assorted non-solid geometry. I'll see what else I can dig up.
<!--QuoteBegin-Shadowics+Feb 21 2004, 11:27 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Shadowics @ Feb 21 2004, 11:27 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Okay. I knew that I had an old room laying around that was giving me some clipping problems. It is a bit convoluted but doesn't appear to have any invalid brushes and seems to provide a clear clipping issue. I also compared the original file with the exported .map and there doesn't appear to be any difference. (I use Quark)
There are never any errors during the compile. When compiled with -cliptype legacy or smallest the map appears fine, no errors with the clipping that I could notice. With -cliptype precise, simple, or normalized there is a big block of clip up at the top part. Just walk up the spiral stairs and you'll hit an invisible wall.
(Careful though, it's got real bad r_speeds and worse compile time if you tried to do a full vis/rad <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> )
I also had some variations of this room that had worse clipping issues - assorted non-solid geometry. I'll see what else I can dig up. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Sounds like this is the bug I've wanted to reproduce -- I'll look at it during the next week.
If it would help at all I just created another map that's completely different from the other one and has the same clipping problem. With -cliptype precise there's a block of solid air, but with -cliptype legacy it's fine. It's a bit smaller and simpler than the other one too, let me know if you'd like to see it.
Update: Eeek!!! I just made it worse! Now there's another piece of solid air near the first one, and a nearby worldbrush became non-solid. The pieces of solid air almost seem like the clip planes of nearby brushes where extended out. It's too bad it's not possible to look at the clipping planes like you can 'gl_wireframe 1'. If I had to guess though I'd say it's your changes to the beveling - while it solves a problem with an assumption the original tools make, it could be making some assumptions of its own that don't hold true for all brushes.
<!--QuoteBegin-Shadowics+Feb 26 2004, 08:27 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Shadowics @ Feb 26 2004, 08:27 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> If it would help at all I just created another map that's completely different from the other one and has the same clipping problem. With -cliptype precise there's a block of solid air, but with -cliptype legacy it's fine. It's a bit smaller and simpler than the other one too, let me know if you'd like to see it.
Update: Eeek!!! I just made it worse! Now there's another piece of solid air near the first one, and a nearby worldbrush became non-solid. The pieces of solid air almost seem like the clip planes of nearby brushes where extended out. It's too bad it's not possible to look at the clipping planes like you can 'gl_wireframe 1'. If I had to guess though I'd say it's your changes to the beveling - while it solves a problem with an assumption the original tools make, it could be making some assumptions of its own that don't hold true for all brushes. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> There may still be issues due to floating point error, but the geometry behind the new code is solid -- although it took me a few tries, I've verified the current code is correct through mathmatical principles.
The expanded brushes are the correct size and shape (verified this in practice by brute force check of every individual brush's clip information before they're combined on maps that still have problems); it's the code that combines them into a single hull that still seems buggy <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
I'm considering compiling p14+ using double precision math to help eliminate problems due to FP error.
If you could send over that other map, I'd like the additional example.
I was concerned over floating point errors due to the nature of this room I built, because if that I was very careful to keep every single vertex on the grid. I would think that floating point errors would be more likely to cause problems like tiny gaps that cause hidden leaks rather than large plane issues. How is your code that combines the clipping planes into a single hull different from the original?
This map is a room that I sealed off that is showing the clipping problems, I retextured the faces near the problems. 2 solid pieces of nothing and 2 partially non-solid brushs. Hope it helps.
<!--QuoteBegin-Shadowics+Feb 27 2004, 02:06 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Shadowics @ Feb 27 2004, 02:06 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I was concerned over floating point errors due to the nature of this room I built, because if that I was very careful to keep every single vertex on the grid. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> That doesn't help in practice because brushes are converted to plane equations by the tools--vertex information from the map file doesn't get past the first stage of CSG, and that initial conversion already introduces FP error. Error can't be avoided when you're going to be taking distances and cross products--you could attempt to use a rational number class and explicitly store numerator and denominator, but the precision of your incoming data is already a problem.
As you can see, those aren't integers (and even if they were, the first transform into plane offset format would make them non-integer values anyway).
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I would think that floating point errors would be more likely to cause problems like tiny gaps that cause hidden leaks rather than large plane issues.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
When FP errors cause face-to-plane collision detection to fail during BSP compilation, that's going to have a major effect. Shifting a plane offset slightly *will* cause major problems if the plane is no longer in the error threshold of its ideal value.
Another problem related to FP is small face removal... any face under an area threshold is removed and the brush is reconstructed as if that plane wasn't a participant. This can cause large spikes to form when the remaining sides converge slowly, and is one cantidate of the brushes-to-hull conversion that I need to look at as a potential error source.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->How is your code that combines the clipping planes into a single hull different from the original?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
It isn't <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> -- the code has always had issues with non-axial planes; people had hull 1 leaks without hull 0 leaks long before I started working on the tools. The new brush generation code increases the likelihood of those errors happening because it adds many non-axial planes to the mix. The clipping mode isn't causing the error later in the pipeline; it's exposing the problem.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This map is a room that I sealed off that is showing the clipping problems, I retextured the faces near the problems. 2 solid pieces of nothing and 2 partially non-solid brushs. Hope it helps.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Looking at it with the compiler right now -- thanks for the sample.
<!--QuoteBegin-XP-Cagey+Feb 27 2004, 05:51 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Feb 27 2004, 05:51 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->That doesn't help in practice because brushes are converted to plane equations by the tools--vertex information from the map file doesn't get past the first stage of CSG, and that initial conversion already introduces FP error. Error can't be avoided when you're going to be taking distances and cross products--you could attempt to use a rational number class and explicitly store numerator and denominator, but the precision of your incoming data is already a problem.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->I see... so that's where the problem comes from. I don't know the code but even storing them as rational number sets wouldn't help much because any operation done would still have the result truncated.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Another problem related to FP is small face removal... any face under an area threshold is removed and the brush is reconstructed as if that plane wasn't a participant. This can cause large spikes to form when the remaining sides converge slowly, and is one cantidate of the brushes-to-hull conversion that I need to look at as a potential error source.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->I think I know what you're talking about here, HLcsg has the option -tiny, which sets the threshold for small face removal, with a default of 0.5 units. I just set it to -tiny 0.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->It isn't <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> -- the code has always had issues with non-axial planes; people had hull 1 leaks without hull 0 leaks long before I started working on the tools. The new brush generation code increases the likelihood of those errors happening because it adds many non-axial planes to the mix. The clipping mode isn't causing the error later in the pipeline; it's exposing the problem.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->That's what I thought. Is it possible that the old brush generation code was deliberately expanding brushes incorrectly so that when the expanded planes where combined in to the clipping hull they resembled the appropriate planes?
Non-axial planes... that's why the compiles break everything on 90* angles. Is that what the HL engine expects, or just convention to avoid more problems like what we're seeing here?
There is something wrong in hlrad when running BuildVisLeafs. Lots of page faults: <img src='http://hullu.xtragaming.com/hlrad_pagefault_problem.gif' border='0' alt='user posted image' />
<!--QuoteBegin-hullu+Mar 4 2004, 08:00 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (hullu @ Mar 4 2004, 08:00 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->There is something wrong in hlrad when running BuildVisLeafs. Lots of page faults:<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> <!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->It might be caused by the large stack object in "vismatrixutil.cpp:CompressTransferIndicies".<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I actually made the change to the preallocated memory that was in your copy of the source... I'll try to figure out what's going on.
If you'd like to help, Microsoft as a <a href='http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/pfmon-o.asp' target='_blank'>tool</a> that can trace the function call that's causing page faults under Win2000 -- I could give you a debug copy of p13 to run with whatever map is causing the issue so that we can find the function that's actually causing the faults.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This command-line tool lets a developer or system administrator monitor page faults that occur while an application is running. While you can easily resolve soft page faults with Virtual Memory Manager, use Pfmon to trace hard page faults. A sustained high rate of hard page faults might indicate a shortage of memory and cause a disk bottleneck. Use Pfmon to trace the source and number of page faults in a process and display the data in the command window, write it to a log file, or both.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<!--QuoteBegin-Shadowics+Feb 27 2004, 04:23 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Shadowics @ Feb 27 2004, 04:23 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->That's what I thought. Is it possible that the old brush generation code was deliberately expanding brushes incorrectly so that when the expanded planes where combined in to the clipping hull they resembled the appropriate planes? <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Possible? Sure. I don't think that's the case, though. id Software was aware that the software had potential issues when they made it open source in '96:
<!--QuoteBegin-John Carmack+October 13, 1996--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (John Carmack @ October 13, 1996)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->There is new source code available. ftp.idsoftware.com : /idstuff/source/qutils.zip has win-32 compiled versions and VC++ projects for all of the quake command line utilities. The qbsp/light/vis programs have not been tested all that well here, because we still use a dec alpha running unix for most of our work, but it has been converted from doubles to floats, which should reduce the memory requirements quite a bit (and possibly cause more numeric instabilities...).
ZHLT is a direct descendant of that released source <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Non-axial planes... that's why the compiles break everything on 90* angles. Is that what the HL engine expects, or just convention to avoid more problems like what we're seeing here?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
It's convention; axial planes are slightly more efficient, but they aren't a requirement. I don't believe the use of planes that have three nonzero components in the normal was common until after newer .map file texture formats allowed textures to map to those planes without distortion. If you load up Quake, I don't think there's a single plane like that in the entire game. Aside from terrain, they're rare in Half-Life as well.
The precise vs. smallest clipping differences only affect that type of face in practice -- box clipping takes care of the rest.
I've been playing with your latest sample map, and it seems like the BSP construction algorithm is ignoring faces when it's dividing the world -- the right corridor (looking uphill), for instance, is blocked along the extension of the large center brush as if the left side of the channel is being ignored. It should be noted that the brush itself is being created correctly -- if you remove it from that room and put it in an axial box it'll behave itself. It's the combination of brushes that makes the hull assembly routine choke.
I want to get p14 released soon to fix the file handler/name@isp.com directory name issue, but I'm probably going to take a long look at fixing this for p15.
Comments
Oh and Cagey, any word on whether you'd like me to do the docs?
Reve
Oh and Cagey, any word on whether you'd like me to do the docs?
Reve <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Actually, that'd be a big help; I'd like to remain the final editor on the docs, but there's a lot of work to be done -- email me with any starting questions and let me know what resources you'll need.
What I'd like to see initially is text on the usage of each optional parameter. A comprehensive list of error messages would also be nice, but that's much less of a priority for the time being.
I made a cylinder out of world brushes - 16 sided cylinder
It was (dont know the proper numbers), the size of the hammer grid all but the 64 unit hull file space around the out side
When i complied the map, it came up with a leek in hull 1,2,3, etc -using max view of defalt 4096
When i made the max viewable distance 9999999999, (10 9's) it had no leek.
Can some one please let me know why this is?
BTW - i am trying to make the AVP2 Fwd pods in Half Life - for Sven Coop, and hence the massive cylinder
Thanks
amckern
When i made the max viewable distance 9999999999, (10 9's) it had no leek.
Can some one please let me know why this is?
<!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Sounds like a bug -- I'll look into it.
amckern
When i made the max viewable distance 9999999999, (10 9's) it had no leek.
Can some one please let me know why this is?
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Sounds like a bug -- I'll look into it. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
I always get a leak when I have things past the view distance. I use p12 though.
I don't know... odd.
~ DarkATi
It should have been in the download <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo-->
Try grabbing the p13 download again.
amckern
Thanks.
infestation piles seem to be destroying my clipping hulls. normally i make them world brush so that they dont take up entities. ina hive rom im playing with this casues teh clip hull to become insane, unless the piles are put into an entity. ill be poting a fixed and broken .map
<a href='http://maps.confusionville.net/files/Bugged_maps.zip' target='_blank'>THe zip containing two broken .maps</a>
infestation piles seem to be destroying my clipping hulls. normally i make them world brush so that they dont take up entities. ina hive rom im playing with this casues teh clip hull to become insane, unless the piles are put into an entity. ill be poting a fixed and broken .map
<a href='http://maps.confusionville.net/files/Bugged_maps.zip' target='_blank'>THe zip containing two broken .maps</a> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Thanks -- I'll get on this ASAP.
You've got some other brush problems too, Quark reports a leak while the compile tools do not, which generally indicated some other less serious brush problems, (such as a concave brush with gets deformed during compiling but does not actually create a leak). Also during compiling HLRad gave this error "hlrad: Error: for Face 579 (texture wall_panelsb) at hlrad: Error: Bad surface extents (17 x 5) Check the file ZHLTProblems.html for a detailed explanation of this problem"
P.S. - Keep things on the grid! "-807.850232 -836.401440 -1.552555" is just <i>asking</i> for trouble.
P.P.S - You've got some Leaf Portal saw into leaf problems too.
Cagey: Does the "Could you please break my tools?" still apply to p13? I might be able to help <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
Yeah -- I'm still trying to track down the sketchy bug that's causing clip hull problems after brush expansion.
oh, the behavior is that both the diagonal walls extend infinately though the top one retains the window.
Invalid geometry do cause those errors.
I may not be able to do anything from looking at the map file exported by Hammer; it would take looking at the rmf before export in some to determine which faces / brushes are actually broken since the map file contains only the minimum amount of information necessary to desscribe a brush; I'll take a close look at the bad file in the zip and see if there are any tests I can run to detect and report errors. The invalid brushes could be described in the map file in a manner that actually requires those invisible walls to be generated in the clip hulls.
The correct solution would eventually be to autodetect problems in the rmf file and throw nonfatal errors that stop HLRAD and HLVIS from running and taking up useless CPU time; in the meantime HLFix will have to take on the role of warning users about bad geometry.
There are never any errors during the compile. When compiled with -cliptype legacy or smallest the map appears fine, no errors with the clipping that I could notice. With -cliptype precise, simple, or normalized there is a big block of clip up at the top part. Just walk up the spiral stairs and you'll hit an invisible wall.
(Careful though, it's got real bad r_speeds and worse compile time if you tried to do a full vis/rad <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> )
I also had some variations of this room that had worse clipping issues - assorted non-solid geometry. I'll see what else I can dig up.
There are never any errors during the compile. When compiled with -cliptype legacy or smallest the map appears fine, no errors with the clipping that I could notice. With -cliptype precise, simple, or normalized there is a big block of clip up at the top part. Just walk up the spiral stairs and you'll hit an invisible wall.
(Careful though, it's got real bad r_speeds and worse compile time if you tried to do a full vis/rad <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> )
I also had some variations of this room that had worse clipping issues - assorted non-solid geometry. I'll see what else I can dig up. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Sounds like this is the bug I've wanted to reproduce -- I'll look at it during the next week.
Update: Eeek!!! I just made it worse! Now there's another piece of solid air near the first one, and a nearby worldbrush became non-solid. The pieces of solid air almost seem like the clip planes of nearby brushes where extended out. It's too bad it's not possible to look at the clipping planes like you can 'gl_wireframe 1'. If I had to guess though I'd say it's your changes to the beveling - while it solves a problem with an assumption the original tools make, it could be making some assumptions of its own that don't hold true for all brushes.
Update: Eeek!!! I just made it worse! Now there's another piece of solid air near the first one, and a nearby worldbrush became non-solid. The pieces of solid air almost seem like the clip planes of nearby brushes where extended out. It's too bad it's not possible to look at the clipping planes like you can 'gl_wireframe 1'. If I had to guess though I'd say it's your changes to the beveling - while it solves a problem with an assumption the original tools make, it could be making some assumptions of its own that don't hold true for all brushes. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
There may still be issues due to floating point error, but the geometry behind the new code is solid -- although it took me a few tries, I've verified the current code is correct through mathmatical principles.
The expanded brushes are the correct size and shape (verified this in practice by brute force check of every individual brush's clip information before they're combined on maps that still have problems); it's the code that combines them into a single hull that still seems buggy <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
I'm considering compiling p14+ using double precision math to help eliminate problems due to FP error.
If you could send over that other map, I'd like the additional example.
This map is a room that I sealed off that is showing the clipping problems, I retextured the faces near the problems. 2 solid pieces of nothing and 2 partially non-solid brushs. Hope it helps.
That doesn't help in practice because brushes are converted to plane equations by the tools--vertex information from the map file doesn't get past the first stage of CSG, and that initial conversion already introduces FP error. Error can't be avoided when you're going to be taking distances and cross products--you could attempt to use a rational number class and explicitly store numerator and denominator, but the precision of your incoming data is already a problem.
Your interpretation of "on the grid" and a machine's will differ -- that's the heart of what FP error is... here's the first brush from the map you linked--the 3 sets of numbers in parenthses are the vertex information the tools use to build brushes:
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->// Brush 0
// Marine Start:g[2] -> new cube:p[1]
{
( 128.98843 504 -160.12355 ) ( 128.98843 632 -160.12355 ) ( 1.97686 504 -144.24711 ) INSIDEWALL [ -1.00000 0.00000 0.00000 129.99225 ] [ 0.00000 -1.00000 0.00000 504.00000 ] 0 0.99228 1.00000
( 119.19169 120 -126.39896 ) ( 119.19169 248 -126.39896 ) ( 246.20326 120 -142.27541 ) INSIDEWALL [ 1.00000 0.00000 0.00000 -120.11926 ] [ 0.00000 -1.00000 0.00000 120.00000 ] 0 0.99228 1.00000
( 355.05441 -142.16311 -48.48943 ) ( 362.90028 -150.13156 79.02115 ) ( 446.26297 -52.35776 -48.48943 ) INSIDEWALL [ 0.99811 0.00000 -0.06141 -502.46238 ] [ 0.00000 0.00000 -1.00000 -48.67554 ] 0 0.71122 0.99618
( 263.84586 231.96845 -48.48943 ) ( 271.69172 239.93691 79.02115 ) ( 172.63730 321.77381 -48.48943 ) INSIDEWALL [ -0.99811 0.00000 0.06141 374.46234 ] [ 0.00000 0.00000 -1.00000 -48.67554 ] 0 0.71122 0.99618
( 256 456 -176 ) ( 271.87645 456 -48.98843 ) ( 256 328 -176 ) INSIDEWALL [ 0.00000 -1.00000 0.00000 456.00000 ] [ 0.00000 0.00000 -1.00000 -177.36967 ] 0 1.00000 0.99228
( 387.96911 88 -160.24711 ) ( 403.84556 88 -33.23554 ) ( 387.96911 216 -160.24711 ) INSIDEWALL [ 0.00000 1.00000 0.00000 -88.00000 ] [ 0.00000 0.00000 -1.00000 -161.49419 ] 0 1.00000 0.99228
}<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
As you can see, those aren't integers (and even if they were, the first transform into plane offset format would make them non-integer values anyway).
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I would think that floating point errors would be more likely to cause problems like tiny gaps that cause hidden leaks rather than large plane issues.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
When FP errors cause face-to-plane collision detection to fail during BSP compilation, that's going to have a major effect. Shifting a plane offset slightly *will* cause major problems if the plane is no longer in the error threshold of its ideal value.
Another problem related to FP is small face removal... any face under an area threshold is removed and the brush is reconstructed as if that plane wasn't a participant. This can cause large spikes to form when the remaining sides converge slowly, and is one cantidate of the brushes-to-hull conversion that I need to look at as a potential error source.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->How is your code that combines the clipping planes into a single hull different from the original?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
It isn't <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> -- the code has always had issues with non-axial planes; people had hull 1 leaks without hull 0 leaks long before I started working on the tools. The new brush generation code increases the likelihood of those errors happening because it adds many non-axial planes to the mix. The clipping mode isn't causing the error later in the pipeline; it's exposing the problem.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This map is a room that I sealed off that is showing the clipping problems, I retextured the faces near the problems. 2 solid pieces of nothing and 2 partially non-solid brushs. Hope it helps.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Looking at it with the compiler right now -- thanks for the sample.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Another problem related to FP is small face removal... any face under an area threshold is removed and the brush is reconstructed as if that plane wasn't a participant. This can cause large spikes to form when the remaining sides converge slowly, and is one cantidate of the brushes-to-hull conversion that I need to look at as a potential error source.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->I think I know what you're talking about here, HLcsg has the option -tiny, which sets the threshold for small face removal, with a default of 0.5 units. I just set it to -tiny 0.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->It isn't <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> -- the code has always had issues with non-axial planes; people had hull 1 leaks without hull 0 leaks long before I started working on the tools. The new brush generation code increases the likelihood of those errors happening because it adds many non-axial planes to the mix. The clipping mode isn't causing the error later in the pipeline; it's exposing the problem.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->That's what I thought. Is it possible that the old brush generation code was deliberately expanding brushes incorrectly so that when the expanded planes where combined in to the clipping hull they resembled the appropriate planes?
Non-axial planes... that's why the compiles break everything on 90* angles. Is that what the HL engine expects, or just convention to avoid more problems like what we're seeing here?
Lots of page faults:
<img src='http://hullu.xtragaming.com/hlrad_pagefault_problem.gif' border='0' alt='user posted image' />
Lots of page faults:<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->It might be caused by the large stack object in "vismatrixutil.cpp:CompressTransferIndicies".<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I actually made the change to the preallocated memory that was in your copy of the source... I'll try to figure out what's going on.
If you'd like to help, Microsoft as a <a href='http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/pfmon-o.asp' target='_blank'>tool</a> that can trace the function call that's causing page faults under Win2000 -- I could give you a debug copy of p13 to run with whatever map is causing the issue so that we can find the function that's actually causing the faults.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This command-line tool lets a developer or system administrator monitor page faults that occur while an application is running. While you can easily resolve soft page faults with Virtual Memory Manager, use Pfmon to trace hard page faults. A sustained high rate of hard page faults might indicate a shortage of memory and cause a disk bottleneck. Use Pfmon to trace the source and number of page faults in a process and display the data in the command window, write it to a log file, or both.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Possible? Sure. I don't think that's the case, though. id Software was aware that the software had potential issues when they made it open source in '96:
<!--QuoteBegin-John Carmack+October 13, 1996--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (John Carmack @ October 13, 1996)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->There is new source code available. ftp.idsoftware.com : /idstuff/source/qutils.zip has win-32 compiled versions and VC++ projects for all of the quake command line utilities. The qbsp/light/vis programs have not been tested all that well here, because we still use a dec alpha running unix for most of our work, but it has been converted from doubles to floats, which should reduce the memory requirements quite a bit (and possibly cause more numeric instabilities...).
[<a href='http://www.bluesnews.com/archives/sept96-2.html' target='_blank'>quote source</a>]<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
ZHLT is a direct descendant of that released source <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Non-axial planes... that's why the compiles break everything on 90* angles. Is that what the HL engine expects, or just convention to avoid more problems like what we're seeing here?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
It's convention; axial planes are slightly more efficient, but they aren't a requirement. I don't believe the use of planes that have three nonzero components in the normal was common until after newer .map file texture formats allowed textures to map to those planes without distortion. If you load up Quake, I don't think there's a single plane like that in the entire game. Aside from terrain, they're rare in Half-Life as well.
The precise vs. smallest clipping differences only affect that type of face in practice -- box clipping takes care of the rest.
I've been playing with your latest sample map, and it seems like the BSP construction algorithm is ignoring faces when it's dividing the world -- the right corridor (looking uphill), for instance, is blocked along the extension of the large center brush as if the left side of the channel is being ignored. It should be noted that the brush itself is being created correctly -- if you remove it from that room and put it in an axial box it'll behave itself. It's the combination of brushes that makes the hull assembly routine choke.
I want to get p14 released soon to fix the file handler/name@isp.com directory name issue, but I'm probably going to take a long look at fixing this for p15.