<!--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-->i got a MAX MIPTEX error is this to do with the size of my wad or the size/amounts of the textures in the map? how does the -texdata work to put the 4mg memory up to 8mg.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> The texture limit for Natural Selection has been set at 4 Mb by Flayra, to support software mode and older video cards. So if you want your map to be official, don't increase the limit. Note that the limit depends on the total <i>size</i> of your textures, not the numbers. So maybe you should be using smaller textures. Use <a href='http://www.telefragged.com/wally/' target='_blank'>Wally</a> to look through the .wad files you're using and start decreasing texture sizes, keeping the dimensions powers of 2, especially when the dimensions of the original texture aren't a power of 2.
If you still want to increase the limit, it's well explained in <a href='http://dev.valve-erc.com/index.php?area=documents&document%5B%5D=103385110134880700&action=view' target='_blank'>ZHLT's documentation</a>: Add "-texdata xxxx" (xxxx in kb) to each compile tool with the <b>exact</b> same values for xxxx with each tool. So if you wanted the limit to be 8 Mb you'd write "-texdata 8192" in each compile tools' parameter box.
<!--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-->is the new zoners 1.7 .CSG compatable with the null tex<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Yes, the problem must lie elsewhere. Make sure you're using the latest version, since in older versions there are problems with maps that actually go over the limit. If you believe you may have found a bug in them, try to get more info about what causes it and post again with results/example maps.
<!--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-->Right, dl'd the tools, optimizer and DLL put the tools in place of my hlcsg and hlrad hit the run button in wc then hit go with the first 2 boxes checked, hit the ok button and nothing happens<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Which version of the tools works and which doesn't? Where did you download the tools and in which order? Did you try installing the tools to a different folder then the other tools, to make sure you have all required files? Did you try running the tools with a batch file or from the command line?
<!--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-->Which version of the tools works and which doesn't? Where did you download the tools and in which order? Did you try installing the tools to a different folder then the other tools, to make sure you have all required files? Did you try running the tools with a batch file or from the command line? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
[builder]hicks and I got the problem figured out, solution noted <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=22787' target='_blank'>here</a>. Thanks for troubleshooting Wolv <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
<!--QuoteBegin--Ollj+Feb 8 2003, 03:36 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Ollj @ Feb 8 2003, 03:36 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->if you have this +maxplanes tool and you know how to map with that detail you dond need to subdivide. If you use subdivide on this tool, you stupid.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> ... do you just want to flame me, or didnt you understand what my tool is good for? it is not for reducing planes like the opt_plns but for reducing w_poly --> add more detail in the maps
Fixed the problem that Token was having: his map had over 4MB of textures and opt_plns wasn't able to read it from file. Version 1.4 now automatically allocates as much memory as needed for the tex, light, and vis data when reading in the map. The chart printout reports amounts relative to 4MB, 4MB, and 2MB for reference, but going over those amounts won't hurt opt_plns (it WILL hurt the other tools with the exception of using -texdata to raise that amount).
I also added a "-logfile <filename>" switch as venomus requested, and relaxed the filename input requirements to match the requirements of the Valve SDK version of the tools.
If your map is going to be over the 4MB tex limit (maps that aren't trying for official NS status) and over the 32K planes limit, you'll definitely want this update.
I've almost finished a partial rewrite of HLCSG that contains an optional fix for half-life's crappy clip hull generation--no more sticking on invisible edges. People may also see a slight drop in their clipnodes depending on the complexity of their maps' architecture. My new CreateBrush code is about 90% faster than the old brute force method (knocked my overall csg time from 5 min to 30 seconds). I'll post a request for beta testers in a separate thread sometime later this week along with a layman's explanation of what changed.
EDIT: Going out of town for half a week, so this is being pushed off for next week.
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
Nice!!! your great man.. now you could do something that lowers the r_speeds (and there are enough possibilties... like the stupid thing that the compilers cut in a big plane when there is another plane that is touching it.. i never understood why but it incrases very much the r_speeds specialy when you have pipes... (cylinders))
There is some dispute about whether or not the limit is 4mb. Flayra himself said in the updated map 1.1 thread that software mode is NOT Supported by NS (its obvious if you try to play it, and not one single person has complained since release on here, which shows you how many people use software mode) and in the updated mapping guidelines thread he did NOT say 4mb texture limit was in effect.
<!--QuoteBegin--^Requiem^+Feb 11 2003, 05:24 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (^Requiem^ @ Feb 11 2003, 05:24 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> There is some dispute about whether or not the limit is 4mb. Flayra himself said in the updated map 1.1 thread that software mode is NOT Supported by NS (its obvious if you try to play it, and not one single person has complained since release on here, which shows you how many people use software mode) and in the updated mapping guidelines thread he did NOT say 4mb texture limit was in effect. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Yeah, I've been lurking in the thread about that subject. The good news is that whether the limit is actually still in effect or not--and I don't really have a position on this since it hasn't affected my own map yet--the optimizer now supports going over it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
<!--QuoteBegin--XP-Cagey+Feb 11 2003, 10:04 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Feb 11 2003, 10:04 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I've almost finished a partial rewrite of HLCSG that contains an optional fix for half-life's crappy clip hull generation--no more sticking on invisible edges. .... My new CreateBrush code is about 90% faster than the old brute force method .... <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> 1. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> sounds good 2. i'd like to betatest 3. the cliphull generation ... yet another common bug, need to build a list .... perhaps
<!--QuoteBegin--Asraniel+Feb 11 2003, 03:56 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Asraniel @ Feb 11 2003, 03:56 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Nice!!! your great man.. now you could do something that lowers the r_speeds (and there are enough possibilties... like the stupid thing that the compilers cut in a big plane when there is another plane that is touching it.. i never understood why but it incrases very much the r_speeds specialy when you have pipes... (cylinders)) <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Actually, dividing up the map that way allows the engine to work... look up "binary space partition" (with quotes) in Google and see what you get. I may be able to do some work to make the tools a little smarter about where to cut first, but r_speeds will probably always be something that smart planning will reduce better than a tool fix.
Try making your pipes func_walls or leaving a 1 pixel gap between the ends of the pipes and the wall, and they won't cut into the wall anymore. Traditionally, func_walls weren't practical in many situations because they didn't cast shadows, but some of the latest versions of zoner's tools allow you to have brush entities that do cast shadows. Details are <a href='http://collective.valve-erc.com/data/docs/1034150354-69206000/files/instructions.html?PHPSESSID=b9403763648ff5bdf65e0bde1848d4fc#9' target='_blank'>here</a>.
I'm out of town and afk for the next 4 days, hopefully I'll have that beta CSG out next week.
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
of course its always better to make pipes or so to func_walls.. but i dont have alsways the posibility (vis...), but sometimes its realy stupid how the brushes are cut (excample.. i have to make all my lights to func_wall, because when i dont, they cut the wall in three parts and there is a strange shadow on the wall out of nowere)
<!--QuoteBegin--^Requiem^+Feb 11 2003, 05:24 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (^Requiem^ @ Feb 11 2003, 05:24 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Flayra himself said in the updated map 1.1 thread that software mode is NOT Supported by NS (its obvious if you try to play it, and not one single person has complained since release on here, which shows you how many people use software mode)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Okay, here's a complaint for you, then. People running software mode (like me) rant and rave in silence and just go to other mods that <i>can</i> run software mode. There are many of us lurking in the gutters under the city. <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Back on topic:
I downloaded the new tools and recompiled one of my maps. Apart from increasing the size of the original Zoners compile of 3.3 MB to 4.0 MB, I've noticed <i>NO</i> reduction in r_speeds nor increase in fps, even after running opt_plns 1.2.
Judging by how everyone rant and raves in this thread about this custom release of Zoners, I must be doing something wrong. (See attached batch file.) Any ideas? Does this custom tools only make a difference for machines running in non-software modes?
<!--QuoteBegin--rebel without a pause+Feb 14 2003, 12:17 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (rebel without a pause @ Feb 14 2003, 12:17 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin--^Requiem^+Feb 11 2003, 05:24 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (^Requiem^ @ Feb 11 2003, 05:24 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Flayra himself said in the updated map 1.1 thread that software mode is NOT Supported by NS (its obvious if you try to play it, and not one single person has complained since release on here, which shows you how many people use software mode)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Okay, here's a complaint for you, then. People running software mode (like me) rant and rave in silence and just go to other mods that <i>can</i> run software mode. There are many of us lurking in the gutters under the city. <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Back on topic:
I downloaded the new tools and recompiled one of my maps. Apart from increasing the size of the original Zoners compile of 3.3 MB to 4.0 MB, I've noticed <i>NO</i> reduction in r_speeds nor increase in fps, even after running opt_plns 1.2.
Judging by how everyone rant and raves in this thread about this custom release of Zoners, I must be doing something wrong. (See attached batch file.) Any ideas? Does this custom tools only make a difference for machines running in non-software modes? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> It isn't MEANT to decrease r_speeds.. all it does is strip the unnecessary planes from the BSP, leaving you more room for planes.
Back in town <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<!--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-->It isn't MEANT to decrease r_speeds.. all it does is strip the unnecessary planes from the BSP, leaving you more room for planes. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Exactly.
<!--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--> but it reduces r_speeds.. not very much, not every were in the map... but it does.. (20-30 w_polys in some areas) <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Asraniel: I'd actually like to get in touch with you to see this--several people have reported lower r_speeds but I can't think of a reason why there would be any change--if there is an r_speed reduction from an exact point in an exact direction, I'll have to spend a night trying to figure out what's going on, since there isn't an obvious answer <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
BiTMAP had reported a hit to FPS when going over the plane limit that running the optimizer corrected (page two of this thread), which I can see happening. On my own map, and on several other peoples' according to reports, brush entites sometimes have missing faces before optimization in cases where the map was over 32K planes. If you're still under the planes limit, however, I'd expect the only benefit of opt_plns (and the current customizations in general) to be a slight file size drop. I've been hesitant to comment on this since I haven't verified any of it personally and there could <i>theoretically</i> be more going on than I realize, but we certainly don't need any more confusion on this topic <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->.
<!--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-->Apart from increasing the size of the original Zoners compile of 3.3 MB to 4.0 MB<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
rebel: I'd like to get more information on this too since I don't know why the file size would increase (unless you're using a version other than Merl's 1.7 as a baseline for comparison). I've already PM'd you with a few questions.
Edit: Busted by the grammar police <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html/emoticons/wow.gif' border='0' style='vertical-align:middle' alt='wow.gif'><!--endemo-->
For fairness sake I think I should just mention: I think I found the reason for the increase in my BSP file size. At about the same time as trying these new tools I also changed my VIS switch from -fast to -full.
I now also understand the tools better after Cagey PM'd me. Thanks, Cagey.
I've released another tool update that eliminates sticky corners in Half-Life maps. The change affects HLCSG, and is detailed at <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>http://xp-cagey.com/articles/clip_hull</a>. There is a thread about the update <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=24137' target='_blank'>here</a>, where you can download the updated HLCSG separately from the rest of the tools.
does your tool interface with Nem's Batch? - is there a way you two could hook up and combine this sweet baby into one monster program?
Link for Nem's Website: <a href='http://countermap.counter-strike.net/Nemesis/index.html' target='_blank'>http://countermap.counter-strike.net/Nemes...esis/index.html</a>
<!--QuoteBegin--Delarosa+Feb 27 2003, 01:57 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Delarosa @ Feb 27 2003, 01:57 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> does your tool interface with Nem's Batch? - is there a way you two could hook up and combine this sweet baby into one monster program? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> It'll require a modified .bcs file, but adding an opt_plns tab should be possible.
Nem talks about interfacing with my stuff briefly in <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=23829&hl=batch+compiler' target='_blank'>this thread</a>. I've posted a feature enhancement request on <a href='http://countermap.counter-strike.net/cgi-bin/ubb/forumdisplay.cgi?action=topics&number=11' target='_blank'>his util forum</a> to possibly make it easier to integrate independant tools as add-on tabs to multiple configurations in the future.
EDIT: modified bcs, not bcp... I'll be trying to get my foot out of my mouth for the next few minutes.
This tool, if it works, sounds absolutely fantastic <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> However.....
I have a rather bizarre bug-report for these tools. Firstly I apologise in advance if this is down to my own incompetence, but there may be a genuine problem here.....
I use my own batch files and normally use Merl's 1.6 tools release. I have tried compiling my map (standard HL, not NS) with the 1.7p3 tools. If I leave the HLCSG parameter "-cliptype" set to the default "legacy", then the map compiles fine (well, I haven't run RAD but the map runs fine unlit). However, if I set this parameter to "precise", the map fails to compile. The <i>reason</i> it fails to compile is that it has a leak! Here is the message: <span style='color:red'> BSP generation successful, writing portal file 'c:\graphics\hammer\maps\gmdm2_project\compiling\compile.prt' Warning: === LEAK in hull 1 === Entity info_player_deathmatch @ ( 584,-409, 44) </span> <snip>...load of standard bug-fix stuff from Zoner's...</snip> <span style='color:red'> Leak pointfile generated</span>
Note that the compile window indicates that the portal file has been created, but subsequently indicates a leak. I have never seen this - in my experience, leaks always occur before the portal file can be generated.
Also the leak is in hull 1. I believe that hull 0 is the usual hull for leaks, and so I expect that hull 0 is the "visible hull" and hull 1 is one of the clipping hulls. That would make some sense, given that the only difference between the two compiles should be a difference in clipping hull(s).
<!--QuoteBegin--Gollum+Feb 28 2003, 04:49 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Gollum @ Feb 28 2003, 04:49 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Note that the compile window indicates that the portal file has been created, but subsequently indicates a leak. I have never seen this - in my experience, leaks always occur before the portal file can be generated.
Also the leak is in hull 1. I believe that hull 0 is the usual hull for leaks, and so I expect that hull 0 is the "visible hull" and hull 1 is one of the clipping hulls. That would make some sense, given that the only difference between the two compiles should be a difference in clipping hull(s). <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> As you noted, the visible hull (and its portal file) are being created without any problem, but the clip hull is leaking.
The most common problem that leads to this behavior is an illegal brush shape--a brush with either a non-planar quad (which Hammer reports), a coplanar surface (which the tools will report), or a concave shape (which the tools can't catch due to recieving a list of planes instead of edges from Hammer, and Hammer doesn't report).
Because the precise and simple clipping types <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>use edge analysis</a> to add bevel planes, they're very sensitive to edges on illegal brushes, which violate some of the geometric assumptions made by the code. If all faces are planar, there aren't any duplicate planes, and the brush is convex, the new code works great--otherwise, it won't operate correctly. The end effect is a vis hull that's OK and a clip hull that has bad contributions from the illegal brush, which can knock holes in a clip hull that are actually larger than the original brush.
If you're using Hammer, check your map using Alt-P to see if there are any reported illegal brushes. If there aren't, it's probably a case of a concave brush. As an experiment, you can try exporting your file to map and then loading the map in Hammer--if it tells you solids were removed because they were invalid, you know you have a problem brush. Alternately, you can use Quark to detect invalid brushes, since it has a stricter check against brush shapes.
<!--QuoteBegin--Revenant+Feb 28 2003, 11:29 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Revenant @ Feb 28 2003, 11:29 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I see a big future for you Cagey. When can we see these tools getting past their "Buggy" Stages? As I am a bit picky on things like this . . .<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I completely sympathize with the sentiment--nobody wants to use a program they think may cause new problems.
I believe that opt_plns 1.4 is bug-free--I haven't had a report against that version to date.
Regarding the problems people are having with HLCSG 1.7p3... to date I've recieved one sample map that contained completely legal brushes and exhibited a reproducable bug. On that particular map, the exact same bug appears using the latest public version of Merl's build (version 1.7) but isn't present when using Zoner's version 2.5.3. With the map author's help I've narrowed down a test case and I'm comparing those two versions to attempt to see what the problem is--it should be noted that the changes between 1.7 and 1.7p3 didn't introduce that bug; it was inherited from the old codebase.
I'd like to point out that a subset of the problems that people have reported (massive file size increases, broken node counts) aren't related to my enchancements--although changing the compiler may seem like an obvious culprit for a new problem, there isn't necessarily a correlation. There are a few of these threads floating around the boards.
Other problems that people have had are a result of the new algorithm and fall into two categories: denormalization of brushes has narrowed passages to the point that they are too small to fit through, or edge detection beveling on an illegal brush has cut away a part of the clipping hull resulting in the ability to see into the void or an outright leak in a clipping hull. Let me address both of these issues:
<b>denormalization cutting off passages</b>: I may release an update that allows people to set -cliptype so that brushes are fully beveled and still normalized, which would allow existing maps with passages too small to denormalize to operate as they used to. This would fix some clipping issues, but people would still stick on exterior corners formed by multiple brushes. If I recieve requests for this, I'll probably add it in, but like "smallest" I would recommend against its use as it wouldn't completely solve the sticking problems.
As I noted in the clip fix article, I believe it is theoretically possible to create a new algorithm that intelligently cuts exterior corners off of normalized brushes, but I haven't investigated the technique and I suspect it will be a difficult problem to solve. I'd like to try my hand in some other areas before I refine clipping further--as one of my ex-bosses once put it, "let's see if there is any other low hanging fruit to pick before we go after the high ones".
<b>illegal brushes cause clipping holes</b>: There is a specific case that I can guard against and throw a warning about when it happens: unique edges (when only 1 face in a brush has a particular edge). I may add an error message when this happens, since it invariably means that a set of planes was exported by Hammer that came from an illegal shape. Unfortunately, without the .rmf format I simply can't detect concave brush shapes--the only information that I have to work with is the set of planes that form each brush, and every concave brush will create a smaller convex brush when it's reassembled from its planes, causing loss of information and inability to even know where a problem is coming from at map compilation time (see attached image).
I won't ever fix this bug at the tool level because it is resulting from an invalid input state--I really want to be able to notify people when they have a bad brush (preferably with an entity and brush number), but don't have sufficient information to do so. I've emailed Valve regarding their stance on reverse-engineering the .rmf format several weeks ago and never recieved a reply, so I expect their official stance to forbid programs that would compromise their intellectual property. It's a shame, but it's also out of my hands.
I don't want to publish a road map right now since I don't want to make any promises I can't keep--I do intend to make some very cool improvements to the compile process including some completely new functionality that should make people even more excited than what I've done to date (how's that for a tease? <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->), and I also intend to continue supporting my projects by correcting reproducible errors.
While I'm addressing quality control issues, I'd like to publicly thank the following people for trusting me with their map sources so that I can track down reproducable errors (in alphabetical order): Cadaver, gaggle, Ollj, Relic25, and Token. They have my gratitude for their assistance in improving the tools.
EDIT: fixed image background color EDIT (again) : unique edge meaning 1 face has the edge, not 1 plane
First off, there's no way they can restrict you from figuring out the file format for the .RMF files, Cagey. Second, from what I've heard they store the vertices, with each plane pointing to three verts that forms it. If this is true, wouldn't it be possible to check for a concave brush by comparing the location of one of more 'vertice points' used to define each plane of a brush against the rest of the brush, and if vertices on two seperate planes are outside of each other, throw the warning and/or try to fix the error then?
I.E. If one or more vertices for plane A are 'outside' plane B, and one or more vertices for plane B are 'outside' plane A on the same brush, assume concave brush at intersection of plane's A and B? Or have you tried that already?
And yes, I mean at the .MAP level for this test, not the .RMF level. At worst, it cuts up the brushwork a little too much, but those planes could/would get thrown out later in the chain anyways, right?
I hereby present XP-Cagey with the prestigious Onos Of The Year award, for services both to the NS mapping community and the Half-life mapping community as a whole.....
Thanks for your explanation and suggestions Cagey <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> I am using Hammer; the "check for problems" tool reports no problems, and loading the .map file rather than the .rmf file gives no indication of problems either. I shall experiment with Quark to see if I can track down these problem brushes.
<!--QuoteBegin--WolfWings+Mar 1 2003, 09:50 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Mar 1 2003, 09:50 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> First off, there's no way they can restrict you from figuring out the file format for the .RMF files, Cagey. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Very true, but I wouldn't use the information without their permission--file formats are less of an intellectual property issue than source code or commercial programs IMO, but if it's important in Valve's eyes I'll respect their wishes <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. Without wanting to start a debate, I'll just say that as a professional programmer I've made a personal decision to extend what I feel is professional courtesy to other programming teams even if I have the legal right to do otherwise. If someone on the forum feels differently, Valve wouldn't be able to restrict them, either--but I wouldn't advocate such a project.
<!--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-->Second, from what I've heard they store the vertices, with each plane pointing to three verts that forms it.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
The .MAP format is essentially stores [p1] [p2] [p3] [texinfo] for each face, where the three points chosen form the face's plane and are defined as integer triples. I'm not sure if the points chosen for each plane always lie within or on the bounds of the face they describe or not. The format would be more accurate if points could be chosen off of the actual face vertices, which wouldn't necessarily be at points on the integer grid. If I remember correctly, Hammer attempts to maintain geometry that is off of the grid, so this is probably the case.
<!--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-->If this is true, wouldn't it be possible to check for a concave brush by comparing the location of one of more 'vertice points' used to define each plane of a brush against the rest of the brush, and if vertices on two seperate planes are outside of each other, throw the warning and/or try to fix the error then?
I.E. If one or more vertices for plane A are 'outside' plane B, and one or more vertices for plane B are 'outside' plane A on the same brush, assume concave brush at intersection of plane's A and B? Or have you tried that already?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It would depend on how the map exporter is choosing the points for each plane -- I <i>can</i> warn the user if there are planes in the brush that don't contribute faces to the reconstructed shape. This is another case where bad geometry is currently resulting in a silent correction to the brush without a warning. The example of a bad reconstruction that I gave in my last post wouldn't be detected by this simple test, but might be using a point based test provided the points are in the faces.
<!--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-->And yes, I mean at the .MAP level for this test, not the .RMF level. At worst, it cuts up the brushwork a little too much, but those planes could/would get thrown out later in the chain anyways, right?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
If the planar points are always within the bounds of the face they describe, this is a great suggestion--I'm always up for a little brainstorming to solve a geometry problem. I'll probably write a subroutine for testing purposes that compares final brush shapes to initial point selection to see if legal brushes ever have off-face points for their plane descriptors. Unfortunately, my first inclination is to think that when choosing integer triples there wouldn't have been a motivation to look at points inside the brush face first--I doubt Valve thought about invalid brush detection at the .MAP level when they wrote their exporter.
The planes would get thrown out later--provided you're using opt_plns to strip out ones that aren't in use since the original tools don't do that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
I LOVE YOU!!!! YOU SEXY <!--emo&::onos::--><img src='http://www.unknownworlds.com/forums/html/emoticons/tiny.gif' border='0' style='vertical-align:middle' alt='tiny.gif'><!--endemo-->
I've fixed Gollum's issue (thanks for the test map), fixed an issue with threadlock on multithreaded execution of HLCSG (thanks 3D-Mike), and added a new -cliptype normalized setting for people who want properly beveled brushes without denormalization shrinking their hallways (maps will still have some sticking points, but will be better than ones compiled with legacy).
Version 1.7p4 is no longer the latest version -- see the first post in the thread for updated links.
Comments
how does the -texdata work to put the 4mg memory up to 8mg.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
The texture limit for Natural Selection has been set at 4 Mb by Flayra, to support software mode and older video cards. So if you want your map to be official, don't increase the limit.
Note that the limit depends on the total <i>size</i> of your textures, not the numbers. So maybe you should be using smaller textures. Use <a href='http://www.telefragged.com/wally/' target='_blank'>Wally</a> to look through the .wad files you're using and start decreasing texture sizes, keeping the dimensions powers of 2, especially when the dimensions of the original texture aren't a power of 2.
If you still want to increase the limit, it's well explained in <a href='http://dev.valve-erc.com/index.php?area=documents&document%5B%5D=103385110134880700&action=view' target='_blank'>ZHLT's documentation</a>: Add "-texdata xxxx" (xxxx in kb) to each compile tool with the <b>exact</b> same values for xxxx with each tool. So if you wanted the limit to be 8 Mb you'd write "-texdata 8192" in each compile tools' parameter box.
<!--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-->is the new zoners 1.7 .CSG compatable with the null tex<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Yes, the problem must lie elsewhere. Make sure you're using the latest version, since in older versions there are problems with maps that actually go over the limit. If you believe you may have found a bug in them, try to get more info about what causes it and post again with results/example maps.
<!--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-->Right, dl'd the tools, optimizer and DLL put the tools in place of my hlcsg and hlrad hit the run button in wc then hit go with the first 2 boxes checked, hit the ok button and nothing happens<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Which version of the tools works and which doesn't?
Where did you download the tools and in which order?
Did you try installing the tools to a different folder then the other tools, to make sure you have all required files?
Did you try running the tools with a batch file or from the command line?
Where did you download the tools and in which order?
Did you try installing the tools to a different folder then the other tools, to make sure you have all required files?
Did you try running the tools with a batch file or from the command line? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
[builder]hicks and I got the problem figured out, solution noted <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=22787' target='_blank'>here</a>. Thanks for troubleshooting Wolv <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
<!--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-->any advice welcome<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Token, if you'd like me to look at it, PM me a link to your zipped .map source--I'll see if I can track down what's going on.
If you use subdivide on this tool, you stupid.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
... do you just want to flame me, or didnt you understand what my tool is good for? it is not for reducing planes like the opt_plns but for reducing w_poly --> add more detail in the maps
I also added a "-logfile <filename>" switch as venomus requested, and relaxed the filename input requirements to match the requirements of the Valve SDK version of the tools.
If your map is going to be over the 4MB tex limit (maps that aren't trying for official NS status) and over the 32K planes limit, you'll definitely want this update.
I've almost finished a partial rewrite of HLCSG that contains an optional fix for half-life's crappy clip hull generation--no more sticking on invisible edges. People may also see a slight drop in their clipnodes depending on the complexity of their maps' architecture. My new CreateBrush code is about 90% faster than the old brute force method (knocked my overall csg time from 5 min to 30 seconds). I'll post a request for beta testers in a separate thread sometime later this week along with a layman's explanation of what changed.
EDIT: Going out of town for half a week, so this is being pushed off for next week.
Yeah, I've been lurking in the thread about that subject. The good news is that whether the limit is actually still in effect or not--and I don't really have a position on this since it hasn't affected my own map yet--the optimizer now supports going over it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
1. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> sounds good
2. i'd like to betatest
3. the cliphull generation ... yet another common bug, need to build a list .... perhaps
Actually, dividing up the map that way allows the engine to work... look up "binary space partition" (with quotes) in Google and see what you get. I may be able to do some work to make the tools a little smarter about where to cut first, but r_speeds will probably always be something that smart planning will reduce better than a tool fix.
Try making your pipes func_walls or leaving a 1 pixel gap between the ends of the pipes and the wall, and they won't cut into the wall anymore. Traditionally, func_walls weren't practical in many situations because they didn't cast shadows, but some of the latest versions of zoner's tools allow you to have brush entities that do cast shadows. Details are <a href='http://collective.valve-erc.com/data/docs/1034150354-69206000/files/instructions.html?PHPSESSID=b9403763648ff5bdf65e0bde1848d4fc#9' target='_blank'>here</a>.
I'm out of town and afk for the next 4 days, hopefully I'll have that beta CSG out next week.
Okay, here's a complaint for you, then. People running software mode (like me) rant and rave in silence and just go to other mods that <i>can</i> run software mode. There are many of us lurking in the gutters under the city. <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Back on topic:
I downloaded the new tools and recompiled one of my maps. Apart from increasing the size of the original Zoners compile of 3.3 MB to 4.0 MB, I've noticed <i>NO</i> reduction in r_speeds nor increase in fps, even after running opt_plns 1.2.
Judging by how everyone rant and raves in this thread about this custom release of Zoners, I must be doing something wrong. (See attached batch file.) Any ideas? Does this custom tools only make a difference for machines running in non-software modes?
Okay, here's a complaint for you, then. People running software mode (like me) rant and rave in silence and just go to other mods that <i>can</i> run software mode. There are many of us lurking in the gutters under the city. <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Back on topic:
I downloaded the new tools and recompiled one of my maps. Apart from increasing the size of the original Zoners compile of 3.3 MB to 4.0 MB, I've noticed <i>NO</i> reduction in r_speeds nor increase in fps, even after running opt_plns 1.2.
Judging by how everyone rant and raves in this thread about this custom release of Zoners, I must be doing something wrong. (See attached batch file.) Any ideas? Does this custom tools only make a difference for machines running in non-software modes? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
It isn't MEANT to decrease r_speeds.. all it does is strip the unnecessary planes from the BSP, leaving you more room for planes.
<!--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-->It isn't MEANT to decrease r_speeds.. all it does is strip the unnecessary planes from the BSP, leaving you more room for planes. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Exactly.
<!--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--> but it reduces r_speeds.. not very much, not every were in the map... but it does.. (20-30 w_polys in some areas) <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Asraniel: I'd actually like to get in touch with you to see this--several people have reported lower r_speeds but I can't think of a reason why there would be any change--if there is an r_speed reduction from an exact point in an exact direction, I'll have to spend a night trying to figure out what's going on, since there isn't an obvious answer <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
BiTMAP had reported a hit to FPS when going over the plane limit that running the optimizer corrected (page two of this thread), which I can see happening. On my own map, and on several other peoples' according to reports, brush entites sometimes have missing faces before optimization in cases where the map was over 32K planes. If you're still under the planes limit, however, I'd expect the only benefit of opt_plns (and the current customizations in general) to be a slight file size drop. I've been hesitant to comment on this since I haven't verified any of it personally and there could <i>theoretically</i> be more going on than I realize, but we certainly don't need any more confusion on this topic <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->.
<!--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-->Apart from increasing the size of the original Zoners compile of 3.3 MB to 4.0 MB<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
rebel: I'd like to get more information on this too since I don't know why the file size would increase (unless you're using a version other than Merl's 1.7 as a baseline for comparison). I've already PM'd you with a few questions.
Edit: Busted by the grammar police <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html/emoticons/wow.gif' border='0' style='vertical-align:middle' alt='wow.gif'><!--endemo-->
I now also understand the tools better after Cagey PM'd me. Thanks, Cagey.
Thanks for you guys' input. I appreciate it.
does your tool interface with Nem's Batch?
- is there a way you two could hook up and combine this sweet baby into one monster program?
Link for Nem's Website:
<a href='http://countermap.counter-strike.net/Nemesis/index.html' target='_blank'>http://countermap.counter-strike.net/Nemes...esis/index.html</a>
- is there a way you two could hook up and combine this sweet baby into one monster program? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It'll require a modified .bcs file, but adding an opt_plns tab should be possible.
Nem talks about interfacing with my stuff briefly in <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=23829&hl=batch+compiler' target='_blank'>this thread</a>. I've posted a feature enhancement request on <a href='http://countermap.counter-strike.net/cgi-bin/ubb/forumdisplay.cgi?action=topics&number=11' target='_blank'>his util forum</a> to possibly make it easier to integrate independant tools as add-on tabs to multiple configurations in the future.
EDIT: modified bcs, not bcp... I'll be trying to get my foot out of my mouth for the next few minutes.
I have a rather bizarre bug-report for these tools. Firstly I apologise in advance if this is down to my own incompetence, but there may be a genuine problem here.....
I use my own batch files and normally use Merl's 1.6 tools release. I have tried compiling my map (standard HL, not NS) with the 1.7p3 tools. If I leave the HLCSG parameter "-cliptype" set to the default "legacy", then the map compiles fine (well, I haven't run RAD but the map runs fine unlit). However, if I set this parameter to "precise", the map fails to compile. The <i>reason</i> it fails to compile is that it has a leak! Here is the message:
<span style='color:red'>
BSP generation successful, writing portal file 'c:\graphics\hammer\maps\gmdm2_project\compiling\compile.prt'
Warning: === LEAK in hull 1 ===
Entity info_player_deathmatch @ ( 584,-409, 44)
</span>
<snip>...load of standard bug-fix stuff from Zoner's...</snip>
<span style='color:red'>
Leak pointfile generated</span>
Note that the compile window indicates that the portal file has been created, but subsequently indicates a leak. I have never seen this - in my experience, leaks always occur before the portal file can be generated.
Also the leak is in hull 1. I believe that hull 0 is the usual hull for leaks, and so I expect that hull 0 is the "visible hull" and hull 1 is one of the clipping hulls. That would make some sense, given that the only difference between the two compiles should be a difference in clipping hull(s).
Also the leak is in hull 1. I believe that hull 0 is the usual hull for leaks, and so I expect that hull 0 is the "visible hull" and hull 1 is one of the clipping hulls. That would make some sense, given that the only difference between the two compiles should be a difference in clipping hull(s). <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
As you noted, the visible hull (and its portal file) are being created without any problem, but the clip hull is leaking.
The most common problem that leads to this behavior is an illegal brush shape--a brush with either a non-planar quad (which Hammer reports), a coplanar surface (which the tools will report), or a concave shape (which the tools can't catch due to recieving a list of planes instead of edges from Hammer, and Hammer doesn't report).
Because the precise and simple clipping types <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>use edge analysis</a> to add bevel planes, they're very sensitive to edges on illegal brushes, which violate some of the geometric assumptions made by the code. If all faces are planar, there aren't any duplicate planes, and the brush is convex, the new code works great--otherwise, it won't operate correctly. The end effect is a vis hull that's OK and a clip hull that has bad contributions from the illegal brush, which can knock holes in a clip hull that are actually larger than the original brush.
If you're using Hammer, check your map using Alt-P to see if there are any reported illegal brushes. If there aren't, it's probably a case of a concave brush. As an experiment, you can try exporting your file to map and then loading the map in Hammer--if it tells you solids were removed because they were invalid, you know you have a problem brush. Alternately, you can use Quark to detect invalid brushes, since it has a stricter check against brush shapes.
I completely sympathize with the sentiment--nobody wants to use a program they think may cause new problems.
I believe that opt_plns 1.4 is bug-free--I haven't had a report against that version to date.
Regarding the problems people are having with HLCSG 1.7p3... to date I've recieved one sample map that contained completely legal brushes and exhibited a reproducable bug. On that particular map, the exact same bug appears using the latest public version of Merl's build (version 1.7) but isn't present when using Zoner's version 2.5.3. With the map author's help I've narrowed down a test case and I'm comparing those two versions to attempt to see what the problem is--it should be noted that the changes between 1.7 and 1.7p3 didn't introduce that bug; it was inherited from the old codebase.
I'd like to point out that a subset of the problems that people have reported (massive file size increases, broken node counts) aren't related to my enchancements--although changing the compiler may seem like an obvious culprit for a new problem, there isn't necessarily a correlation. There are a few of these threads floating around the boards.
Other problems that people have had are a result of the new algorithm and fall into two categories: denormalization of brushes has narrowed passages to the point that they are too small to fit through, or edge detection beveling on an illegal brush has cut away a part of the clipping hull resulting in the ability to see into the void or an outright leak in a clipping hull. Let me address both of these issues:
<b>denormalization cutting off passages</b>: I may release an update that allows people to set -cliptype so that brushes are fully beveled and still normalized, which would allow existing maps with passages too small to denormalize to operate as they used to. This would fix some clipping issues, but people would still stick on exterior corners formed by multiple brushes. If I recieve requests for this, I'll probably add it in, but like "smallest" I would recommend against its use as it wouldn't completely solve the sticking problems.
As I noted in the clip fix article, I believe it is theoretically possible to create a new algorithm that intelligently cuts exterior corners off of normalized brushes, but I haven't investigated the technique and I suspect it will be a difficult problem to solve. I'd like to try my hand in some other areas before I refine clipping further--as one of my ex-bosses once put it, "let's see if there is any other low hanging fruit to pick before we go after the high ones".
<b>illegal brushes cause clipping holes</b>: There is a specific case that I can guard against and throw a warning about when it happens: unique edges (when only 1 face in a brush has a particular edge). I may add an error message when this happens, since it invariably means that a set of planes was exported by Hammer that came from an illegal shape. Unfortunately, without the .rmf format I simply can't detect concave brush shapes--the only information that I have to work with is the set of planes that form each brush, and every concave brush will create a smaller convex brush when it's reassembled from its planes, causing loss of information and inability to even know where a problem is coming from at map compilation time (see attached image).
I won't ever fix this bug at the tool level because it is resulting from an invalid input state--I really want to be able to notify people when they have a bad brush (preferably with an entity and brush number), but don't have sufficient information to do so. I've emailed Valve regarding their stance on reverse-engineering the .rmf format several weeks ago and never recieved a reply, so I expect their official stance to forbid programs that would compromise their intellectual property. It's a shame, but it's also out of my hands.
I don't want to publish a road map right now since I don't want to make any promises I can't keep--I do intend to make some very cool improvements to the compile process including some completely new functionality that should make people even more excited than what I've done to date (how's that for a tease? <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->), and I also intend to continue supporting my projects by correcting reproducible errors.
While I'm addressing quality control issues, I'd like to publicly thank the following people for trusting me with their map sources so that I can track down reproducable errors (in alphabetical order): Cadaver, gaggle, Ollj, Relic25, and Token. They have my gratitude for their assistance in improving the tools.
EDIT: fixed image background color
EDIT (again) : unique edge meaning 1 face has the edge, not 1 plane
I.E. If one or more vertices for plane A are 'outside' plane B, and one or more vertices for plane B are 'outside' plane A on the same brush, assume concave brush at intersection of plane's A and B? Or have you tried that already?
And yes, I mean at the .MAP level for this test, not the .RMF level. At worst, it cuts up the brushwork a little too much, but those planes could/would get thrown out later in the chain anyways, right?
XP-Cagey, you are <b>the greatest</b>
<img src='http://www.imagemagician.org/images/kombot/ONOSOTY.gif' border='0' alt='user posted image'>
Very true, but I wouldn't use the information without their permission--file formats are less of an intellectual property issue than source code or commercial programs IMO, but if it's important in Valve's eyes I'll respect their wishes <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. Without wanting to start a debate, I'll just say that as a professional programmer I've made a personal decision to extend what I feel is professional courtesy to other programming teams even if I have the legal right to do otherwise. If someone on the forum feels differently, Valve wouldn't be able to restrict them, either--but I wouldn't advocate such a project.
<!--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-->Second, from what I've heard they store the vertices, with each plane pointing to three verts that forms it.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
The .MAP format is essentially stores [p1] [p2] [p3] [texinfo] for each face, where the three points chosen form the face's plane and are defined as integer triples. I'm not sure if the points chosen for each plane always lie within or on the bounds of the face they describe or not. The format would be more accurate if points could be chosen off of the actual face vertices, which wouldn't necessarily be at points on the integer grid. If I remember correctly, Hammer attempts to maintain geometry that is off of the grid, so this is probably the case.
<!--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-->If this is true, wouldn't it be possible to check for a concave brush by comparing the location of one of more 'vertice points' used to define each plane of a brush against the rest of the brush, and if vertices on two seperate planes are outside of each other, throw the warning and/or try to fix the error then?
I.E. If one or more vertices for plane A are 'outside' plane B, and one or more vertices for plane B are 'outside' plane A on the same brush, assume concave brush at intersection of plane's A and B? Or have you tried that already?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It would depend on how the map exporter is choosing the points for each plane -- I <i>can</i> warn the user if there are planes in the brush that don't contribute faces to the reconstructed shape. This is another case where bad geometry is currently resulting in a silent correction to the brush without a warning. The example of a bad reconstruction that I gave in my last post wouldn't be detected by this simple test, but might be using a point based test provided the points are in the faces.
<!--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-->And yes, I mean at the .MAP level for this test, not the .RMF level. At worst, it cuts up the brushwork a little too much, but those planes could/would get thrown out later in the chain anyways, right?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
If the planar points are always within the bounds of the face they describe, this is a great suggestion--I'm always up for a little brainstorming to solve a geometry problem. I'll probably write a subroutine for testing purposes that compares final brush shapes to initial point selection to see if legal brushes ever have off-face points for their plane descriptors. Unfortunately, my first inclination is to think that when choosing integer triples there wouldn't have been a motivation to look at points inside the brush face first--I doubt Valve thought about invalid brush detection at the .MAP level when they wrote their exporter.
The planes would get thrown out later--provided you're using opt_plns to strip out ones that aren't in use since the original tools don't do that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
Version 1.7p4 is no longer the latest version -- see the first post in the thread for updated links.