How Do You Fix 1.04 Maps?
ThePhilips
Join Date: 2002-09-09 Member: 1302Members
Join Date: 2002-09-09 Member: 1302Members
Comments
Max
how do you fix it
$path\$file -hullfile C:\SIERRA\Half-Life\ns\nshulls.txt
Replacing c:\sierrazhalf-life\ with your hafllife path
This is the thread where i found out--
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=40771' target='_blank'>http://www.unknownworlds.com/forums/in...=ST&f=4&t=40771</a>
Generally speaking, the BSP format favors size and then loading speed over editing capability--compilation is a lossy process. Clip hulls are stored in a BSP tree without any face information -- the tree itself is used for collision detection. Shifting the planes in the tree sounds like an OK solution until you realize that entire nodes might be dropped since the volume of the leaves is shrinking. Creating a face list from the clip tree is possible--you'd want to use the hull 1 information (the vis hull would be missing cllip brush information) to compute the geometry given the new hull offsets. Once that's available, you'd need to recompute the winding for every face and reconstruct the tree from there.
From a computational geometry standpoint, it's far easier to offset the faces of the original brushes (since they are garunteed convex) and take their union than to perform the task the other way around. It's not conceptually difficult to convert from face format to BSP and back, but finding a robust solution isn't easy (the 95% solution is simple, but nobody wants clip hulls that are accurate 95% of the time).
If the algorithm performed correctly, you could theoretically get much better results from a hull than a brush list (bug #2 in my article becomes a thing of the past if you're working with a single solid), but it's mathematically complex enough that I haven't wanted to tackle it (yet). I've looked through academic research sites that archive computational geometry papers, but I haven't found a generalized solution to the problem. In private conversations I've narrowed the algorithm down to some very simple steps leading up to an ambiguous "stitch adjacent faces back together" where adjacency isn't well defined. See the attached image for why it's not well defined, keeping in mind that 2 dimensional algorithms don't necessarily extend to three dimensions <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. <i>As an aside, the older version of AutoCad that I use doesn't properly offset the shape in that image; I found that interesting.</i>
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->All it takes is some coder who knows enough about the bsp format and he could write a fix in an hour or two.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
For the record, opt_plns 1.0 took 30 minutes to write and another 20 minutes of work after bug reports came in before it was solid (v 1.4). It didn't require any knowledge of what the tools did--it just found unreferenced planes and removed them--very, very simple.
The clip code I wrote took 4 days of whiteboard work trying to figure out what the current code had done wrong and how to fix it, and about 2 hours of coding time (including user interface work). Valve's BSP generation code still has some geometry issues that I'm puzzling through (vis_leaf errors, "holes" in the union of brushes using both the original clipping code and my replacement).
Working on the tools is, in my experience, usually 5% programming and 95% mathematics... reclipping from the BSP isn't an exception <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.