<!--QuoteBegin--rebel without a pause+Feb 14 2003, 05: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, 05: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--> Are you running in software? (sounds like that's what you said), if not, D3D or openGL???
That seems quite odd, since I SHOULD be seeing number tables and such for clipnodes and planes and what not come up....wth is wrong? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Worse when I call the above quoted batch...copied the exact same way as the original post... When I call your batch through expert mode like this: compile-HLNS.bat $path\$file $bspdir $file
I get this: <!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> ** Executing... ** Command: Change Directory ** Parameters: "C:\SIERRA\Half-Life"
* Could not execute the command: C:\Program Files\Valve Hammer Editor\tools\compile_HLNS.bat c:\PROGRA~1\VALVEH~1\tools\start C:\SIERRA\Half-Life\ns\maps start * Windows gave the error message: "Access is denied." <!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
<!--QuoteBegin--Grimm Spector+Mar 14 2003, 01:36 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Grimm Spector @ Mar 14 2003, 01:36 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Does this include the texture lights stuff from merl's versions?? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Yes, it's actually derived from the sourcecode of Merl's 1.7 build, so it has all of the features from Merl's last public release.
I've sent in the sourcecode from all of my changes to Merl for possible inclusion in future versions of his releases.
This may sound like an odd request, Cagey. If it's not feasable for some reason, that's cool. But looking over the 'reason the bugs happen' post, the core reason Bug #2 occurs is that all planes of every brush are expanded, not just the 'inner' brushes.
I.E. If the 'touching' faces weren't expanded, the problem wouldn't occur either, would it? And the 'correct clipping' would still nip off the too-large point off the end, unless I'm mis-understanding the mechanics?
Internally, this wouldn't be any different from simply making the two brushes intersect so the faces causing the 'bug' were co-planar with already-existing faces, which would still be clipped correctly.
So, I guess what I'm asking... would it be possible to make yet another compile-time option to, say, never expand a certain (possibly new) texture? Something akin to <span style='color:white'><b>NULL</b></span> but that also blocks the plane from being expanded to generate the clip-hull? Possibly <span style='color:white'><b>BEVEL</b></span> for a reason I'll explain.
Best way I can see to implement it, would be to simply copy the original plane, and as a last step before actually generating the clipping hull use the bevel-textured face to 'bevel' the brush it's attached to, as a sort of post-process. This way, touching faces like the one that causes the bug would automatically work correctly, resulting in the behavior pictured in the attached image.
<!--QuoteBegin--WolfWings+Mar 17 2003, 05:27 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Mar 17 2003, 05:27 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Best way I can see to implement it, would be to simply copy the original plane, and as a last step before actually generating the clipping hull use the bevel-textured face to 'bevel' the brush it's attached to, as a sort of post-process. This way, touching faces like the one that causes the bug would automatically work correctly, resulting in the behavior pictured in the attached image.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> It's probably simplest to initialize the face offset at zero on clip brush generation rather than use a post processing step, since the clip brushes are generated in a different program than the hulls--BSP doesn't read map brushes, so any referencing must be done in CSG.
No ETA on a BEVEL texture, but it seems like a viable improvement and I'll see what I can do--I'm currently working on another project to benefit mappers that is NS-specific and will hopefully reach completion this month.
------------------------------------------------
Removing the offset from touching faces is actually something that I thought about automating when I was brainstorming about possible ways to address bug #2... my thoughts on the technique follow:
The reason I chose denormalization instead of conditional offsetting is the case where faces touch but one extends farther than the other (see image) -- when this happens, multiple clip brushes must be created (one on each side of the face relative to each edge, for a minimum of N+2 clip brushes, where N is the number of edges on touching brush faces which would cut the other brush if extended), which was more complexity than I wanted to tackle in the initial update. The second part of the image shows the correction using multiple clip brushes in a simple case.
Even more complexity is added to the clip brush splitting when more than two brushes share a touching face or when two brushes don't truly share an edge but should have mutual clipping anyway (e.g. furnature or boxes 1 unit from the floor and 1 unit apart to prevent extra cuts in faces and drop r_speeds, or bushes that overlap but have a common exterior edge anyway). The extra faces also exist when multiple brush entities share a corner... since they aren't going to be part of the same entity hull, they won't be detected when processing (I could do cross-detection of brushes on immobile entities like func_walls, but that's yet another level of complexity added. Cross detection on mobile entities would be self-defeating since the common corners wouldn't always be common while one object is moving relative to another).
If a mapper can pick and choose which faces to use when ignoring clip offsets, I'm less worried about the consequences of the first image below, and the problems noted in the previous paragraph are no longer the tools' responsibility. I like the idea of using a texture to manually determine where to do this, and I'll think about implementing it. It would mean changes to CSG (new bevel behavior) and BSP (to remove the bevel texture if it's still exposed in the final visible hull, treating it like the NULL texture).
I chose denormalization as the original solution because it addresses all of the above cases (by making each face offset from vis edges uniform at clip edges regardless of face normal) without being computationally expensive (it actually skips a step, speeding up the overall process. Denormalization is a misnomer--I simply don't project the calculated offset onto the face normal in the first place) or requiring work by the mapper--the smaller clip hull widths are the penalty for the simplicity of the solution.
Keep the ideas coming <!--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+Mar 17 2003, 11:54 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Mar 17 2003, 11:54 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Keep the ideas coming <!--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><span class='postcolor'> <!--QuoteEEnd--> Well I'd mention the obvious one of removing the need for those two .DLL files, but that would require someone else compiling the code. :-) If that'd help any, I'm game since I've got a pretty good set of compilers on my system and I can probably get the code compiling with them. I'll dig through Merl's code and see about getting that compiling in the mean-time.
<!--QuoteBegin--A_W!seM4n_0nc3_Sa!d+Apr 3 2003, 10:12 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (A_W!seM4n_0nc3_Sa!d @ Apr 3 2003, 10:12 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Is there any way you could increase the number of brushes that can be added to a map? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Sure. It'll be up to 32K (from 8K) in the next release. That should be high enough that you'll hit other limits before running out of brushes. I just tested WC, and it appears to be OK (but slow) running with 24K brushes, so I don't see why the tools shouldn't support higher amounts as well.
This is a safe limit to increase, by the way, because only CSG actually uses brushes for processing, and there really isn't a logical limit on the total brushes that CSG can handle.
W00T! Thanks dude! I can't really decribe in words how thankful i am <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Oh yeah, i hope i'm not asking to much, but could you increase the limit on the number of planes again? It would be most appreciated <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Cagey is my Hero! <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
<!--QuoteBegin--A_W!seM4n_0nc3_Sa!d+Apr 4 2003, 12:52 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (A_W!seM4n_0nc3_Sa!d @ Apr 4 2003, 12:52 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Oh yeah, i hope i'm not asking to much, but could you increase the limit on the number of planes again? It would be most appreciated <!--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><span class='postcolor'><!--QuoteEEnd--> Unfortunately, I'll need to change the method HLBSP uses to write face information (and the way that VIS and RAD read it in) before I up the limit again. I originally thought I could up it an arbitrary amount, but the BSP version 30 file format (HL's version of BSP) stores the plane number used by each face as a 16 bit number, meaning the maximum range is 0-65535... I can't change the BSP format without breaking Half-Life compatibility.
It's definitely possible to store the faces outside the BSP until after the optimizer has lowered the total plane count to get around the problem, but it's not a simple change. I'll look into it, but I'm predicting it won't be in the next release. The optimizer would have to read the extended face list and put it back into the BSP file after the plane count was lowered.
I'd eventually like to have a toolset without any practical internal limits during processing -- memory management would need to change first to dynamically allocate space as needed, and the tools would have to abandon the BSP format and use a ToolFormat->BSP converter (which is what the optimizer would become) as the last step. Those are pretty major changes, and I'm currently looking at the pros and cons of that sort of approach before I commit to it.
Ok, no biggie, but, again, Thanks for taking the time to increase the brush limit... I hope i'm not pushing this, but do you know when you'll have the next release out with the higher brush limit in it?
<!--QuoteBegin--A_W!seM4n_0nc3_Sa!d+Apr 4 2003, 07:56 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (A_W!seM4n_0nc3_Sa!d @ Apr 4 2003, 07:56 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Ok, no biggie, but, again, Thanks for taking the time to increase the brush limit... I hope i'm not pushing this, but do you know when you'll have the next release out with the higher brush limit in it? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I'm shooting for Wednesday the 9th.
<!--QuoteBegin--Grimm Spector+Mar 14 2003, 12:11 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Grimm Spector @ Mar 14 2003, 12:11 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Are you running in software? (sounds like that's what you said), if not, D3D or openGL??? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Software, yes. Unfortunately laptops can't be upgraded with a nice video accelerator. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
I found that Direct3D <i>kind of</i> works as well, but the differences between water (Software vs Direct3D) is so radical that I'm wondering if my video card isn't maybe a bit sick.
<b>Feature addition: "zhlt_noclip"</b> - adding this key with a non-empty value to any brush entity will cause ALL clipping information for the brush entity to be stripped, making the entity non-solid in the game. Useful for nonsolid func_wall_toggles, func_buttons, etc. Suggested by Yamazaki. <b>Feature addition: "zhlt_invisible"</b> - adding this key with a non-empty value to any brush entity will cause the entity to be invisible in the game and not contribute to r_speeds (this is the same as using the null texture for the entire entity). In addition, there is a new command line option, -nullfile, that automatically reads a list of brush object types (specified by classname or targetname) from a file and turns them invisible without needing to specify the key in each entity. <b>Feature addition: BEVEL texture</b> - this texture acts like a NULL texture but also doesn't expand when generating clip hulls. Can be used to eliminate exterior corner clipping bugs without using -cliptype precise... -cliptype precise is still the recommended method for removing clipping errors, as this feature is <i>experimental</i>. Suggested by WolfWings -- see page 7 of this topic for discussion. <b>Compiler limit change: MAX_MAP_BRUSHES from 8K to 32K</b>. Suggested by A W!seM4n Onc3 Sa!d. <b>Compiler limit change: ripents.exe has been updated</b> to support the higher map limits of 1.7p5. <b>Optimization: several math functions have been simplified</b> in the code, providing a small boost to HLRAD speeds. Testing showed a ~5% improvement on compiles that weren't using virtual memory. Larger gains are probably possible in the future. <b>Optimization: enabled MSVC++ compiler optimizations for speed</b>. Your milage may vary.
Additional files in the new distribution: ripents.exe has been updated to support the 1.7p5 limits. zhlt.wad has been updated to include the BEVEL texture.
Grab the updated tools from this post and the next one. I'd recommend regrabbing all of the tools.
EDIT: bumped to version 1.7p6 - Bugfix (CSG): BEVEL texture code was causing improper clip offsets for normally textured axial faces.
EDIT: bumped to version 1.7p7 - Bugfix (RAD): texlight handling was removed from p5, p6 during debugging, it's back in now and I've fixed the spam of "too many direct lightstyles" on some maps -- the error now only is written on the first occurance (since it doesn't give the location, additional reports are redundant). This is a stable release, and I probably won't update again for several weeks.
EDIT: bumped to version 1.7p8 - Bugfix (RAD): added -oldmath switch to HLRAD for those who are having problems with versions of HLRAD after 1.7p4
EDIT: bumped to version 1.7p9 - Bugfix (RAD): fixed problem with newer math routines Feature Addition (patch by Nemo1024, CSG): added backward compatability with SDK 2.2 hull file format; change doesn't affect mods using the current format.
EDIT: bumped to version 1.7p10 - Bugfix (RAD): fixed remaining problems with newer math routines and opaque entity shadows.
Grr... packaged the wrong version in the download links for the latest version <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
If you see version 1.7p2 instead of 1.7p5 at the top when you try to run any of the tools, please grab the zip files again -- the 1.7p2 build is an old broken copy of the tools.
EDIT: and the correct version of 1.7p5 was still having a problem related to the new BEVEL texture code... updated to release 1.7p6, which fixes the bug.
EDIT: added texlight support back in and incremented to 1.7p7
<!--QuoteBegin--Ollj+Apr 13 2003, 03:08 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Ollj @ Apr 13 2003, 03:08 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> What does ripent do? deleting entities from he void (thoose with mots around them?). And how to use it correctly? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Ripent allows you to import and export entites from a BSP to a .map-like plain text format... it's part of zoner's original toolset, so if you google it you should get some instruction pages on its use. I hadn't included it before because the Merl's 1.7 sourcecode version doesn't compile without a few fixes.
Its a way to update entities without going through the process of CSG -onlyents, and it can allow you to see what settings people used on their entities (although Quark's BSP viewer is probably still the better tool for this).
The only difference between the version of ripent that's included here and the stock version is the updates to the compiler limits (higher planes allowed, etc).
Now I could need an .fgd that includes - ZHLT lightflags (blocks light ...) - ZHLT flickering and toggleable texture lihghts. - NS specific entities with as less bugs and "...has unused keyvalues" as possible. - XP-Cageys p7 compile tool Flags. - Sorted entities (NS specific on top of list)
----- END hlrad ----- <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Since I changed from 1.0p4 to 1.7p7 i get this strange light error making my map much more pitch black. In this hall are just 1-2 point light entities (used almost all over the map) but instead of making round lights they make it straight along konkarve corners most times or straight light stripes along a long hallway. In most other places the ceeling has 2 times as much light while the bottom is pitch black. If a few places the light is absolutely correct. Some texture lights seem not to cast light anywere.
Apart from leaf portal saw into leafes i got no errors in the compile log. I fixed a few leaf portal saw into leafes and recompiled, getting other leaf portal saw into leafes but still the same light errors.
<!--QuoteBegin--Ollj+Apr 17 2003, 08:59 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Ollj @ Apr 17 2003, 08:59 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> If a few places the light is absolutely correct. Some texture lights seem not to cast light anywere. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> It's probably the changes I made to optimize the math functions in HLRAD -- I'm going to add a command line switch to use the older, slower math functions for now while I try to get a sample case that exhibits the change. I'll have the new version of HLRAD with the switch available in an hour or so unless there's an unforseen delay.
My own full maps light correctly with the new code, so I'll need to find a bad case before I can do some troubleshooting. If you could PM me a single hallway that has the problem, it'd probably make the debug go much more quickly; I'd rather not have a full map to debug since lighting is such a time consuming process.
Sorry about the problem <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
EDIT: took a little longer than expected, I'm testing the update now.
I've posted the updated HLRAD which has a new command line switch, "-oldmath". If you use -oldmath with HLRAD, the older unoptimized math functions are used for BuildFaceLights, which should cause the lighting to appear like it did in 1.7p4. Once I get a sample case of a broken light, I'll work to mimic the old functions more closely. I haven't been able to find a point where the functional results differ by inspection, so I'll need a sample case to proceed. Once I have the new functions mimicking the old math accurately, I'll remove the -oldmath switch, speeding HLRAD back up a little.
If you've downloaded 1.7p7, you only really need to grab 1.7p8_B.zip from the two attachments above, since HLRAD is the only program that has changed between releases. If you haven't had any problems with the p7 RAD, you don't need to upgrade to p8.
I've decided that I'm going to work on getting a true support network for the tools in place with an update mailing list, formalized open beta testing periods for each release, public bug tracking, and a message board for discussion and suggestions. All of the above should be available from my homepage one item at a time as I complete the necessary work in the background--I'll also see about getting a unified tool download from my site so there won't be any more of this multiple zipfile nonsense. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Have you considered using sourceforge to handle the logistics of bugtracking/forums/releases etc? I'm not sure if you want to classify your stuff 'open source', but I imagine the source for somebody's version of these tools is available somewhere, so it's just a question of how you feel about <i>your</i> version of the source. IMHO, open source is always better if you're not trying to make money from it anyway. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Also, Ollj: looking at those screenshots, it looks to me like the light falloff value is too high - the corners right next to the lights are lit, but the light fades away to black too fast and the rest of the corridor (ceiling and floor) don't get any of it. I think there's a switch to specify the distance at which lights fade away.. maybe until Cagey figures out the algorithmic difference you could use that to work around the problem?
Comments
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-->
Are you running in software? (sounds like that's what you said), if not, D3D or openGL???
%'s are output from WorldCraft. to the bathfile. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Call the Bathfile instead of the tools. still setup the tools thou.
have these for Param's in Wolrdcraft/hammer
$path\$file $bspdir $file
%1 = $path\$file
%2 = $bspdir
%3 = $file
FileName : Compile-HLNS.Bat
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
When I compile my testmap, I get this:
<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
** Executing...
** Command: Change Directory
** Parameters: "C:\SIERRA\Half-Life"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\hlcsg.exe
** Parameters: "c:\program files\valve hammer editor\tools\start"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\hlbsp.exe
** Parameters: "c:\program files\valve hammer editor\tools\start"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\hlvis.exe
** Parameters: "c:\program files\valve hammer editor\tools\start"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\hlrad.exe
** Parameters: "c:\program files\valve hammer editor\tools\start"
<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
That seems quite odd, since I SHOULD be seeing number tables and such for clipnodes and planes and what not come up....wth is wrong? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Worse when I call the above quoted batch...copied the exact same way as the original post...
When I call your batch through expert mode like this: compile-HLNS.bat $path\$file $bspdir $file
I get this:
<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
** Executing...
** Command: Change Directory
** Parameters: "C:\SIERRA\Half-Life"
** Executing...
** Command: C:\Program Files\Valve Hammer Editor\tools\compile_HLNS.bat
** Parameters: c:\PROGRA~1\VALVEH~1\tools\start C:\SIERRA\Half-Life\ns\maps start
* Could not execute the command:
C:\Program Files\Valve Hammer Editor\tools\compile_HLNS.bat c:\PROGRA~1\VALVEH~1\tools\start C:\SIERRA\Half-Life\ns\maps start
* Windows gave the error message:
"Access is denied."
<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
ummm...help?? <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
EDIT: I messed up the code tags...
Yes, it's actually derived from the sourcecode of Merl's 1.7 build, so it has all of the features from Merl's last public release.
I've sent in the sourcecode from all of my changes to Merl for possible inclusion in future versions of his releases.
I.E. If the 'touching' faces weren't expanded, the problem wouldn't occur either, would it? And the 'correct clipping' would still nip off the too-large point off the end, unless I'm mis-understanding the mechanics?
Internally, this wouldn't be any different from simply making the two brushes intersect so the faces causing the 'bug' were co-planar with already-existing faces, which would still be clipped correctly.
So, I guess what I'm asking... would it be possible to make yet another compile-time option to, say, never expand a certain (possibly new) texture? Something akin to <span style='color:white'><b>NULL</b></span> but that also blocks the plane from being expanded to generate the clip-hull? Possibly <span style='color:white'><b>BEVEL</b></span> for a reason I'll explain.
Best way I can see to implement it, would be to simply copy the original plane, and as a last step before actually generating the clipping hull use the bevel-textured face to 'bevel' the brush it's attached to, as a sort of post-process. This way, touching faces like the one that causes the bug would automatically work correctly, resulting in the behavior pictured in the attached image.
It's probably simplest to initialize the face offset at zero on clip brush generation rather than use a post processing step, since the clip brushes are generated in a different program than the hulls--BSP doesn't read map brushes, so any referencing must be done in CSG.
No ETA on a BEVEL texture, but it seems like a viable improvement and I'll see what I can do--I'm currently working on another project to benefit mappers that is NS-specific and will hopefully reach completion this month.
------------------------------------------------
Removing the offset from touching faces is actually something that I thought about automating when I was brainstorming about possible ways to address bug #2... my thoughts on the technique follow:
The reason I chose denormalization instead of conditional offsetting is the case where faces touch but one extends farther than the other (see image) -- when this happens, multiple clip brushes must be created (one on each side of the face relative to each edge, for a minimum of N+2 clip brushes, where N is the number of edges on touching brush faces which would cut the other brush if extended), which was more complexity than I wanted to tackle in the initial update. The second part of the image shows the correction using multiple clip brushes in a simple case.
Even more complexity is added to the clip brush splitting when more than two brushes share a touching face or when two brushes don't truly share an edge but should have mutual clipping anyway (e.g. furnature or boxes 1 unit from the floor and 1 unit apart to prevent extra cuts in faces and drop r_speeds, or bushes that overlap but have a common exterior edge anyway). The extra faces also exist when multiple brush entities share a corner... since they aren't going to be part of the same entity hull, they won't be detected when processing (I could do cross-detection of brushes on immobile entities like func_walls, but that's yet another level of complexity added. Cross detection on mobile entities would be self-defeating since the common corners wouldn't always be common while one object is moving relative to another).
If a mapper can pick and choose which faces to use when ignoring clip offsets, I'm less worried about the consequences of the first image below, and the problems noted in the previous paragraph are no longer the tools' responsibility. I like the idea of using a texture to manually determine where to do this, and I'll think about implementing it. It would mean changes to CSG (new bevel behavior) and BSP (to remove the bevel texture if it's still exposed in the final visible hull, treating it like the NULL texture).
I chose denormalization as the original solution because it addresses all of the above cases (by making each face offset from vis edges uniform at clip edges regardless of face normal) without being computationally expensive (it actually skips a step, speeding up the overall process. Denormalization is a misnomer--I simply don't project the calculated offset onto the face normal in the first place) or requiring work by the mapper--the smaller clip hull widths are the penalty for the simplicity of the solution.
Keep the ideas coming <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Well I'd mention the obvious one of removing the need for those two .DLL files, but that would require someone else compiling the code. :-) If that'd help any, I'm game since I've got a pretty good set of compilers on my system and I can probably get the code compiling with them. I'll dig through Merl's code and see about getting that compiling in the mean-time.
Sure. It'll be up to 32K (from 8K) in the next release. That should be high enough that you'll hit other limits before running out of brushes. I just tested WC, and it appears to be OK (but slow) running with 24K brushes, so I don't see why the tools shouldn't support higher amounts as well.
This is a safe limit to increase, by the way, because only CSG actually uses brushes for processing, and there really isn't a logical limit on the total brushes that CSG can handle.
what exactally does one do with the opt_plns.exe?
(maybe a tutorial on what you do with it once you D/L could be on your site?)
XP-Kiljoy
Xtreme Prejudice
Unfortunately, I'll need to change the method HLBSP uses to write face information (and the way that VIS and RAD read it in) before I up the limit again. I originally thought I could up it an arbitrary amount, but the BSP version 30 file format (HL's version of BSP) stores the plane number used by each face as a 16 bit number, meaning the maximum range is 0-65535... I can't change the BSP format without breaking Half-Life compatibility.
It's definitely possible to store the faces outside the BSP until after the optimizer has lowered the total plane count to get around the problem, but it's not a simple change. I'll look into it, but I'm predicting it won't be in the next release. The optimizer would have to read the extended face list and put it back into the BSP file after the plane count was lowered.
I'd eventually like to have a toolset without any practical internal limits during processing -- memory management would need to change first to dynamically allocate space as needed, and the tools would have to abandon the BSP format and use a ToolFormat->BSP converter (which is what the optimizer would become) as the last step. Those are pretty major changes, and I'm currently looking at the pros and cons of that sort of approach before I commit to it.
I'm shooting for Wednesday the 9th.
Software, yes. Unfortunately laptops can't be upgraded with a nice video accelerator. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
I found that Direct3D <i>kind of</i> works as well, but the differences between water (Software vs Direct3D) is so radical that I'm wondering if my video card isn't maybe a bit sick.
<b>Feature addition: "zhlt_noclip"</b> - adding this key with a non-empty value to any brush entity will cause ALL clipping information for the brush entity to be stripped, making the entity non-solid in the game. Useful for nonsolid func_wall_toggles, func_buttons, etc. Suggested by Yamazaki.
<b>Feature addition: "zhlt_invisible"</b> - adding this key with a non-empty value to any brush entity will cause the entity to be invisible in the game and not contribute to r_speeds (this is the same as using the null texture for the entire entity). In addition, there is a new command line option, -nullfile, that automatically reads a list of brush object types (specified by classname or targetname) from a file and turns them invisible without needing to specify the key in each entity.
<b>Feature addition: BEVEL texture</b> - this texture acts like a NULL texture but also doesn't expand when generating clip hulls. Can be used to eliminate exterior corner clipping bugs without using -cliptype precise... -cliptype precise is still the recommended method for removing clipping errors, as this feature is <i>experimental</i>. Suggested by WolfWings -- see page 7 of this topic for discussion.
<b>Compiler limit change: MAX_MAP_BRUSHES from 8K to 32K</b>. Suggested by A W!seM4n Onc3 Sa!d.
<b>Compiler limit change: ripents.exe has been updated</b> to support the higher map limits of 1.7p5.
<b>Optimization: several math functions have been simplified</b> in the code, providing a small boost to HLRAD speeds. Testing showed a ~5% improvement on compiles that weren't using virtual memory. Larger gains are probably possible in the future.
<b>Optimization: enabled MSVC++ compiler optimizations for speed</b>. Your milage may vary.
Additional files in the new distribution:
ripents.exe has been updated to support the 1.7p5 limits.
zhlt.wad has been updated to include the BEVEL texture.
Grab the updated tools from this post and the next one. I'd recommend regrabbing all of the tools.
EDIT: dyslexic moment, sorry Yama <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->
EDIT: bumped to version 1.7p6 - Bugfix (CSG): BEVEL texture code was causing improper clip offsets for normally textured axial faces.
EDIT: bumped to version 1.7p7 - Bugfix (RAD): texlight handling was removed from p5, p6 during debugging, it's back in now and I've fixed the spam of "too many direct lightstyles" on some maps -- the error now only is written on the first occurance (since it doesn't give the location, additional reports are redundant). This is a stable release, and I probably won't update again for several weeks.
EDIT: bumped to version 1.7p8 - Bugfix (RAD): added -oldmath switch to HLRAD for those who are having problems with versions of HLRAD after 1.7p4
EDIT: bumped to version 1.7p9 -
Bugfix (RAD): fixed problem with newer math routines
Feature Addition (patch by Nemo1024, CSG): added backward compatability with SDK 2.2 hull file format; change doesn't affect mods using the current format.
EDIT: bumped to version 1.7p10 -
Bugfix (RAD): fixed remaining problems with newer math routines and opaque entity shadows.
If you see version 1.7p2 instead of 1.7p5 at the top when you try to run any of the tools, please grab the zip files again -- the 1.7p2 build is an old broken copy of the tools.
EDIT: and the correct version of 1.7p5 was still having a problem related to the new BEVEL texture code... updated to release 1.7p6, which fixes the bug.
EDIT: added texlight support back in and incremented to 1.7p7
deleting entities from he void (thoose with mots around them?).
And how to use it correctly?
deleting entities from he void (thoose with mots around them?).
And how to use it correctly? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Ripent allows you to import and export entites from a BSP to a .map-like plain text format... it's part of zoner's original toolset, so if you google it you should get some instruction pages on its use. I hadn't included it before because the Merl's 1.7 sourcecode version doesn't compile without a few fixes.
Its a way to update entities without going through the process of CSG -onlyents, and it can allow you to see what settings people used on their entities (although Quark's BSP viewer is probably still the better tool for this).
The only difference between the version of ripent that's included here and the stock version is the updates to the compiler limits (higher planes allowed, etc).
- ZHLT lightflags (blocks light ...)
- ZHLT flickering and toggleable texture lihghts.
- NS specific entities with as less bugs and "...has unused keyvalues" as possible.
- XP-Cageys p7 compile tool Flags.
- Sorted entities (NS specific on top of list)
......
hlrad v2.5.3 rel Custom Build 1.7p7 (Apr 13 2003)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (webmaster@xp-cagey.com)
----- BEGIN hlrad -----
Command line: C:\PROGRA~1\BATCHC~1\HLRAD.EXE -extra -sparse -bounce 4 -smooth 80 -chop 64 -texchop 32 -lights complexlig.rad -chart -estimate -noinfo -low "F:\mapedit\- Maps\selfmade\compile.map"
[Reading texlights from 'complexlig.rad']
[5 texlights parsed from 'complexlig.rad']
13247 faces
Create Patches : 68692 base patches
81 opaque faces
1350262 square feet [194437776.00 square inches]
1706 direct lights
BuildFacelights:
(7481.79 seconds)
BuildVisLeafs:
(2014.72 seconds)
visibility matrix : 7.8 megs
MakeScales:
(1596.85 seconds)
SwapTransfers:
(39.11 seconds)
Transfer Lists : 15524806 : 15.52M transfers
Indices : 12609460 : 12.03M bytes
Data : 62099224 : 59.22M bytes
GatherLight:
(30.70 seconds)
GatherLight:
(26.53 seconds)
GatherLight:
(27.36 seconds)
GatherLight:
(32.52 seconds)
FinalLightFace:
(20.65 seconds)
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 157/400 10048/25600 (39.3%)
planes 42616/65535 852320/1310700 (65.0%)
vertexes 16124/65535 193488/786420 (24.6%)
nodes 8909/32767 213816/786408 (27.2%)
texinfos 6902/32767 276080/1310680 (21.1%)
faces 13247/65535 264940/1310700 (20.2%)
clipnodes 30483/32767 243864/262136 (93.0%)
leaves 4745/8192 132860/229376 (57.9%)
marksurfaces 16669/65535 33338/131070 (25.4%)
surfedges 59343/512000 237372/2048000 (11.6%)
edges 30404/256000 121616/1024000 (11.9%)
texdata [variable] 5372/4194304 ( 0.1%)
lightdata [variable] 1505529/6291456 (23.9%)
visdata [variable] 220794/2097152 (10.5%)
entdata [variable] 37058/524288 ( 7.1%)
122 textures referenced
=== Total BSP file data space used: 4348495 bytes ===
11298.84 seconds elapsed [3h 8m 18s]
----- END hlrad -----
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Since I changed from 1.0p4 to 1.7p7 i get this strange light error making my map much more pitch black.
In this hall are just 1-2 point light entities (used almost all over the map) but instead of making round lights they make it straight along konkarve corners most times or straight light stripes along a long hallway.
In most other places the ceeling has 2 times as much light while the bottom is pitch black.
If a few places the light is absolutely correct.
Some texture lights seem not to cast light anywere.
Apart from leaf portal saw into leafes i got no errors in the compile log.
I fixed a few leaf portal saw into leafes and recompiled, getting other leaf portal saw into leafes but still the same light errors.
Some texture lights seem not to cast light anywere.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It's probably the changes I made to optimize the math functions in HLRAD -- I'm going to add a command line switch to use the older, slower math functions for now while I try to get a sample case that exhibits the change. I'll have the new version of HLRAD with the switch available in an hour or so unless there's an unforseen delay.
My own full maps light correctly with the new code, so I'll need to find a bad case before I can do some troubleshooting. If you could PM me a single hallway that has the problem, it'd probably make the debug go much more quickly; I'd rather not have a full map to debug since lighting is such a time consuming process.
Sorry about the problem <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
EDIT: took a little longer than expected, I'm testing the update now.
If you've downloaded 1.7p7, you only really need to grab 1.7p8_B.zip from the two attachments above, since HLRAD is the only program that has changed between releases. If you haven't had any problems with the p7 RAD, you don't need to upgrade to p8.
I've decided that I'm going to work on getting a true support network for the tools in place with an update mailing list, formalized open beta testing periods for each release, public bug tracking, and a message board for discussion and suggestions. All of the above should be available from my homepage one item at a time as I complete the necessary work in the background--I'll also see about getting a unified tool download from my site so there won't be any more of this multiple zipfile nonsense. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Backwards compartibility and disabling toggles of new features are essential.