<!--QuoteBegin--taleden+Apr 18 2003, 11:42 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ Apr 18 2003, 11:42 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->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--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Yeah -- I've looked at sourceforge as a solution, but I'm still hoping that Merl can adopt the patches I've sent him so we don't end up with two different and competing branches of development on the same programs. I suppose opening up my own version of the source won't hurt anything, but I'd prefer to keep the maintanence of the public source centralized. I really do need to formalize bug tracking though... I am currently leaning toward using <a href='http://www.mozilla.org/bugs/' target='_blank'>bugzilla</a>.
I actually got started with the tools by downloading the source of Merl's latest public build, which is available on the collective. If and when my changes are incorporated into his branch of development, they'll be available there. I may talk to him about a separate repository, but if I were in his shoes I wouldn't like the idea, especially, since my (XP-Cagey's) versions aren't going through the long closed betas that Merl uses before he releases his source.
Tru, tru - definitely good to avoid a confusiong mess of competing codebases, I can understand that. Are you in contact with Merl/Zoner? Are either of them still actively working on the tools?
<!--QuoteBegin--taleden+Apr 19 2003, 06:09 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ Apr 19 2003, 06:09 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Tru, tru - definitely good to avoid a confusiong mess of competing codebases, I can understand that. Are you in contact with Merl/Zoner? Are either of them still actively working on the tools? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Yeah, I've been sending updates to Merl, who is still active--he's just releasing material at a slower pace than I am. I know that Zipster, another contributer to Merl's build, is still working on some HLRAD enhancements as well.
<!--QuoteBegin--mazemaster+Apr 20 2003, 11:17 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (mazemaster @ Apr 20 2003, 11:17 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I get the same hlrad error on several of my maps. Basically it looks like the lights only emit light horizontally outward in a thin strip. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Download the latest build (1.7p8), and add "-oldmath" to your HLRAD command line.
EDIT: the links in the first post of this thread will always point to the latest version of the tools.
<!--QuoteBegin--XP-Cagey+Apr 19 2003, 07:15 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Apr 19 2003, 07:15 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> [QUOTE=taleden,Apr 19 2003, 06:09 PM] Yeah, I've been sending updates to Merl, who is still active--he's just releasing material at a slower pace than I am. I know that Zipster, another contributer to Merl's build, is still working on some HLRAD enhancements as well. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
do you know if they are going to work on that light styles thing you found in the RAD code?
i don't know C++, but to me it looks like an easy enough sort to remove light styles from buttons and other entitys where it does not apply to the count.
also, is there a variable called max_engine_entity? if so, can it be added to the CSG chart report? IIRC, Merle mentioned that max_engine_entity was the limit of how many switichable lights were in the map - light, light_spot and light_environment entities that have either a targetname or a style attached to them....i think that might be useful in the -chart report.
<!--QuoteBegin--tommy14+Apr 24 2003, 06:20 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (tommy14 @ Apr 24 2003, 06:20 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin--XP-Cagey+Apr 19 2003, 07:15 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Apr 19 2003, 07:15 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Yeah, I've been sending updates to Merl, who is still active--he's just releasing material at a slower pace than I am. I know that Zipster, another contributer to Merl's build, is still working on some HLRAD enhancements as well. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
do you know if they are going to work on that light styles thing you found in the RAD code?
i don't know C++, but to me it looks like an easy enough sort to remove light styles from buttons and other entitys where it does not apply to the count. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'm not sure what Merl's up to with that code -- I had a peek at a beta readme a while back that said he'd disabled the texlight code to prevent the problem. I'm not sure if Merl's aware of the solution since Laurie wrote the code--I'm going to be patching it myself and will let both Merl & Laurie know about it / provide source when it's done.
EDIT: I think one reason why any brush entity can be assigned a style is any brush entity potentially has textures that give off light. IMO the correct solution would be to ignore the style of the entity until HLRAD is ready to run and then only assign the light style to individual faces that are actually giving off light. Since most textures won't be emitting light or won't have an explicit style set, this should curb 99% of the problem, and will probably be the method I use.
I actually think the best solution would be moving the responsibility for setting the light style to a removable point entity near the face (Yamazaki and I talked this over IIRC), which would make it possible for worldspawn texlights to have light styles (for styled texlights that don't add to the final entity count).
As always, this stuff doesn't have a release date... NS has a "when it's done" policy... consider this strictly "if it's done" for the time being. <!--emo&:)--><img src='http://www.natural-selection.org/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<!--QuoteBegin--tommy14+Apr 24 2003, 06:20 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (tommy14 @ Apr 24 2003, 06:20 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> also, is there a variable called max_engine_entity? if so, can it be added to the CSG chart report? IIRC, Merle mentioned that max_engine_entity was the limit of how many switichable lights were in the map - light, light_spot and light_environment entities that have either a targetname or a style attached to them....i think that might be useful in the -chart report.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
From bspfile.h: <!--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-->#define MAX_ENGINE_ENTITIES 1024 #define MAX_MAP_ENTITIES 2048 // hard limit, in actuallity it is too much, as temporary entities in the game plus static map entities can overflow<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
I'll look into adding this to the chart. I'm not sure what the difference is between a map entity and an engine entity ATM, so I'll need to track that down before I implement the change.
EDIT: "engine entities" is simply every entity minus static light, light_environment, and light_spot entities. I think that this definition has the potential to be extended with the items that 1.1 doesn't load as entities during runtime; if that is the case I'll probably end up making a mod-specific list of entities to disregard. While "engine entities" does limit the number of dynamic lights in a map, it also appears to include other entity types, so it isn't entirely accurate to say it's a hard cap on dynamic lighting -- removing, say, an info_target appears to allow another light_spot for instance (moral of the story: use the angles key rather than info_target for spot positioning, but you probably already knew that).
As time goes on, I'm seeing more opportunities for specialization of entity handling (NULL texturing by classname, removing clip by classname and flags as currently hardcoded into HLCSG's clipeconomy mode, engine entity counting, etc). I may end up creating a new XML based file format for encapsulating all of this information in a clean and consistant matter... I'll probably begin working on a DTD for tool settings that can be used for specifying specialized additional per texture and/or per entity information sometime in the next month or so.
I've fixed the lighting bug in the new math routines -- turns out that the CrossProduct macro used in the code can't accept the same variable as an input and a return (oops). The fix means that the -oldmath switch is no longer necessary and everybody can get the benefit of the optimized code without any artifacts. Thanks to Ollj for posting screens of the problem and taleden for providing a sample case of the problem for me to investigate.
I've bumped the version to p9.
The new version also includes a patch by Nemo1024 that adds backward compatability with the older SDK 2.2 hull file format. The change doesn't affect anybody using the new format--you can ignore it unless you've wanted to use the old format.
While I'm posting, I'd like to plug another tool being developed by a forum member here: <a href='http://extension.ws/hlfix/' target='_blank'>HLFix</a> is an independant .rmf to .map converter that is currently being developed by Jedediah. There is a thread <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=30612' target='_blank'>here</a> about the program and its development.
ok, call me dumb, but i can't seem to get these tools to work...after downloading these, i unzipped them to 'zhlt_alt' dir (the original 'zhlt' are in zhlt dir). both of these dirs are in the VHE tools dir. when i F9 to compile, the only output i get is:
and nothing else...when hl/ns starts up, its the map i had before i set it up to use these new tools. if i switch it back to the regular zhlt tools, everything works fine. i get all the normal compile output i usually get and the game starts up with my changes..
<!--QuoteBegin--auslander+May 4 2003, 07:21 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (auslander @ May 4 2003, 07:21 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> ok, call me dumb, but i can't seem to get these tools to work...after downloading these, i unzipped them to 'zhlt_alt' dir (the original 'zhlt' are in zhlt dir). both of these dirs are in the VHE tools dir. when i F9 to compile, the only output i get is:
and nothing else...when hl/ns starts up, its the map i had before i set it up to use these new tools. if i switch it back to the regular zhlt tools, everything works fine. i get all the normal compile output i usually get and the game starts up with my changes..
am i doing something wrong? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Double check that you have the dlls mentioned in the first post -- if you don't the tools will fail to run (the dlls are for all MSVC++ programs using .Net, which is basically MS Visual Studio 7.0... Other releases of the tools use an intel compiler that doesn't require the dlls but builds larger executables).
If that doesn't work, PM me and I'll help you troubleshoot.
The order of operations looks unusual.. I think general procedure is to leave the .map file in your VHE maps directory, compile it from there, and then copy the compiled .bsp and .pts to your ns/maps directory - copying the .map to ns/maps isn't going to really do you any good.
<!--QuoteBegin--taleden+May 4 2003, 08:33 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ May 4 2003, 08:33 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> The order of operations looks unusual.. I think general procedure is to leave the .map file in your VHE maps directory, compile it from there, and then copy the compiled .bsp and .pts to your ns/maps directory - copying the .map to ns/maps isn't going to really do you any good. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Theoretically, moving the map and compiling it in the game directory should still result in a valid bsp; the drawback is the extra clutter in the game directory instead of your mapping directory.
EDIT: I've added prominent links to the dlls in the first post in case anybody misses them further down in the release comments.
<!--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--> Double check that you have the dlls mentioned in the first post -- if you don't the tools will fail to run (the dlls are for all MSVC++ programs using .Net, which is basically MS Visual Studio 7.0... Other releases of the tools use an intel compiler that doesn't require the dlls but builds larger executables). <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I don't know why I didn't get those before posting. I saw that in the thread.
Call me dumb, like I said. <!--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--> The order of operations looks unusual.. I think general procedure is to leave the .map file in your VHE maps directory, compile it from there, and then copy the compiled .bsp and .pts to your ns/maps directory - copying the .map to ns/maps isn't going to really do you any good. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Apparently that is how the 'normal' run command is setup in VHE. i've since moved to use the 'expert', which does just what you say.
XP-Cagey, thanks for implementing my small patch. I must say that the new radiosity code <i>is</i> fast - my 1GHz PIII used about 18 hours to RAD one map, now - only 6,5!
I have a little doubt, are the zhlt_lightflags (to make the entities block light) not working or is it just me?
No, I'm not using -nopaque, and yes, I've set the proper settings in the entities (it works with the earlier versions of HLRAD)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Looks like I have another maintenance release to make <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
I've built a test case to work with for this one. The opacity code does rely heavily on identifying face/ray intersections to identify when a light is blocked by an entity, so it makes sense that tugging on the strands of that code (the optimization work I did) would affect the final lighting.
I'm torn between fixing the old naive check (testing every ray between two patches against every opaque face vertex until a collision is found or there aren't any more verticies) and re-implementing it--if the problem is happening where I believe it is, I could probably gain another (even larger) speed boost by changing the way light/object intersections are calculated. I'll probably begin fixing this tomorrow, and if there aren't any other developments (read: confirmed bug reports), I'll try to get an updated version posted by next Monday.
EDIT: I'll fix the old algorithm first before I open secondary cans of worms in a clearly identified early adopter release--time to increase confidence in the reliablity of what I'm offering. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
EDIT (2): Well, I tried using 1.7p9 and sure enough the opaque entities appeared to be ignored. I then tried using 1.7 with the same map to compare results, and in my simple test case there wasn't any difference in the final lighting--the entities still didn't cast any shadows. Time to find a case that looks different between 1.7 and 1.7p9 (calling all mappers).
If opaque entities didn't cast shadows in the base 1.7, pre-Cagey HLRAD, is it possible they've been shadowless all along and we just never noticed it? How often do mappers have opaque entities whose shadows they specifically verify? Do you have a test case in which an opaque entity /does/ cast a shadow? I'll poke around in some of the finished parts of my map.. do you want test cases in which shadows are cast in both versions (to compare the opaque entity itself to opaque entities which are not casting shadows in either), or are you more interested in cases where there is a difference between 1.7 and 1.7p9?
<!--QuoteBegin--taleden+May 7 2003, 04:18 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ May 7 2003, 04:18 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> If opaque entities didn't cast shadows in the base 1.7, pre-Cagey HLRAD, is it possible they've been shadowless all along and we just never noticed it? How often do mappers have opaque entities whose shadows they specifically verify? Do you have a test case in which an opaque entity /does/ cast a shadow? I'll poke around in some of the finished parts of my map.. do you want test cases in which shadows are cast in both versions (to compare the opaque entity itself to opaque entities which are not casting shadows in either), or are you more interested in cases where there is a difference between 1.7 and 1.7p9? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> At the moment I'm looking for a case where the lighting is different between the two builds -- I have a no shadow case that's the same for both builds that I can use to test against the pre-optimization code.
I actually just tried compiling my marine start with Merl's base 1.7, and there is a definite difference. I recorded a demo of how the lighting changes while opening the door under that build, and am now compiling with your 1.7p9 again to record a comparable demo. The room I'm testing this in is the same one I sent you a few days ago to demonstrate my light-bleeding-through-opaque-entities problem, so try compiling that with both and see if you find the same difference; if not, its possible this is due to some change I've made to the room since I sent you that copy, so I can send a new one.
Anyway, short answer is, yes, there's definitely a difference in how 1.7 and 1.7p9 handle opaque entities - let me know if you need me to send you anything beyond what you have.
Edit: Odd... I just finished compiling with 1.7p9 and ran the 1.7 demo again to make sure to record the same sequence, and realized that after recompiling the map, the old demo starts exhibiting the same bleed-through problems the new tools use. I never realized demos were that map-dependant. *shrug* Anyway, if you aren't able to reproduce the same difference with the last rmf I sent you, I'll send you the new one.
Hey Cagey, I just read your message, I've attached to this post the comparison pic I told you.
Hope it helps, it's just a little test room I did, but it shows clearly the problem.
Obviously, the crate is a entity <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
OK, I've fixed the opaque entity code so that the output matches that of the regular 1.7 build -- personally, I'd like to make it so that the shadow from an opaque entity is identical to the shadow from a world brush in the same size, shape, and position, but getting back to square one so people can continue using the tools ASAP is my first priority.
Thanks to taleden (again!) and Mendasp for providing test cases for me to work with while tracking this down. The links in the first post point to the updated copy of the files.
I think the flurry of updates should be done for at least a month now as I work on the next round of features (if someone needs another bugfix, however, I will provide it as soon as possible). When I introduce the next round of the tools, I will be tagging a stable release (1.7p10) and a beta release (1.7p# beta#). At that point people can choose if they would rather play with new features or wait for any issues to be resolved before grabbing the latest code.
Just now your tools have gone platin Cagey, Merl, Zoner! They are perfect. No... not yet... bouncing colored shadows are still missing! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Ok, call me stupid, but I read in the readme that Cagey had removed the limits on lightdata, but I can't find the switch that enables this. My map is currently 100.8 % over the limit and crashes HL (regardless of mod) when I load it up and my efforts to reduce it have been in vain. Any help much appreciated.
<!--QuoteBegin--Schmung+May 13 2003, 03:19 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Schmung @ May 13 2003, 03:19 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Ok, call me stupid, but I read in the readme that Cagey had removed the limits on lightdata, but I can't find the switch that enables this. My map is currently 100.8 % over the limit and crashes HL (regardless of mod) when I load it up and my efforts to reduce it have been in vain. Any help much appreciated.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I completely removed the lightdata limit from opt_plns, the BSP Plane Optimizer--in the other tools, I've only shifted it from 4MB to 6MB, and the change is automatic (no need for a command line switch) because HLRAD will use the minimum space necessary. "opt_plns_readme.txt" lists changes to opt_plns only -- changes to the other tools are documented in "1.7p10 readme.txt".
At this point you're probably wondering why I don't just remove the limit in HLRAD, too...
In the case of the optimizer, there really isn't any reason why it should know or care how much light data a map has since it doesn't do any processing on that data--HLRAD, however, is controlling how large the map grows in memory and therefore how much memory must be used to play the map. I don't want to increase the MAX_MAP_LIGHTING in HLRAD to an unlimited value because I don't know where the potential HL ceiling for that data is before bugs start to appear on low-end machines.
It could be that that you're over the new limit of 6MB-- could you run HLRAD with -chart in the command line and post the console output here? If the number of bytes (next to the percentage) is over 6291456, you're hitting the new limit. If the limit is lower, make sure you're using the latest build (1.7p10) of HLRAD.
If you'd like to try increasing the limit again (at the risk of some undefined behavior that you will definately need to test for before publicly releasing your map), PM me and I'll build a beta version with an 8MB cap for you--I think that 6MB ought to be plenty, but if maps have a lot of surface area and some dynamic lights they can hit the limit pretty quick.
For more information on how light data is stored and how to reduce the total amount in your map, you should see these threads: <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=21930' target='_blank'>125% Of Light Maximum. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->, how to decrease?</a> <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=22914' target='_blank'>Lightdata Maxed Out., with just basic lightning.</a>
I can't download the tools from the first post. I get an error from the forum software along the lines of "file has been moved".
Cagey, you should really put up at least a small site for these tools since they are currently the best available. If you like I can integrate it with the hlfix site and take care of the hosting.
I'm getting an error when I try to upload the file to the forums as well -- I'm temporarily hosting the files from my website until I can find a better spot; the links that are currently up will not be permanent, but will give you a source until I figure out what's going on.
Sorry about the problem.
Edit: I'm currently working on getting a site up for the tools on my webspace, but don't have an ETA. If you'd like to provide a mirror for the tools on the hlfix site, that'd be great <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->.
Suggestion: add in support for the clip tools and other command line options into info_compile_parameters <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
info_compile_parameters is defined in the fgd file. There are so many fgds right now that you're better off just writing in the extra parameters in your fgd.
Comments
Yeah -- I've looked at sourceforge as a solution, but I'm still hoping that Merl can adopt the patches I've sent him so we don't end up with two different and competing branches of development on the same programs. I suppose opening up my own version of the source won't hurt anything, but I'd prefer to keep the maintanence of the public source centralized. I really do need to formalize bug tracking though... I am currently leaning toward using <a href='http://www.mozilla.org/bugs/' target='_blank'>bugzilla</a>.
I actually got started with the tools by downloading the source of Merl's latest public build, which is available on the collective. If and when my changes are incorporated into his branch of development, they'll be available there. I may talk to him about a separate repository, but if I were in his shoes I wouldn't like the idea, especially, since my (XP-Cagey's) versions aren't going through the long closed betas that Merl uses before he releases his source.
Yeah, I've been sending updates to Merl, who is still active--he's just releasing material at a slower pace than I am. I know that Zipster, another contributer to Merl's build, is still working on some HLRAD enhancements as well.
Download the latest build (1.7p8), and add "-oldmath" to your HLRAD command line.
EDIT: the links in the first post of this thread will always point to the latest version of the tools.
do you know if they are going to work on that light styles thing you found in the RAD code?
i don't know C++, but to me it looks like an easy enough sort to remove light styles from buttons and other entitys where it does not apply to the count.
also, is there a variable called max_engine_entity? if so, can it be added to the CSG chart report? IIRC, Merle mentioned that max_engine_entity was the limit of how many switichable lights were in the map - light, light_spot and light_environment entities that have either a targetname or a style attached to them....i think that might be useful in the -chart report.
do you know if they are going to work on that light styles thing you found in the RAD code?
i don't know C++, but to me it looks like an easy enough sort to remove light styles from buttons and other entitys where it does not apply to the count. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'm not sure what Merl's up to with that code -- I had a peek at a beta readme a while back that said he'd disabled the texlight code to prevent the problem. I'm not sure if Merl's aware of the solution since Laurie wrote the code--I'm going to be patching it myself and will let both Merl & Laurie know about it / provide source when it's done.
EDIT: I think one reason why any brush entity can be assigned a style is any brush entity potentially has textures that give off light. IMO the correct solution would be to ignore the style of the entity until HLRAD is ready to run and then only assign the light style to individual faces that are actually giving off light. Since most textures won't be emitting light or won't have an explicit style set, this should curb 99% of the problem, and will probably be the method I use.
I actually think the best solution would be moving the responsibility for setting the light style to a removable point entity near the face (Yamazaki and I talked this over IIRC), which would make it possible for worldspawn texlights to have light styles (for styled texlights that don't add to the final entity count).
As always, this stuff doesn't have a release date... NS has a "when it's done" policy... consider this strictly "if it's done" for the time being. <!--emo&:)--><img src='http://www.natural-selection.org/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<!--QuoteBegin--tommy14+Apr 24 2003, 06:20 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (tommy14 @ Apr 24 2003, 06:20 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> also, is there a variable called max_engine_entity? if so, can it be added to the CSG chart report? IIRC, Merle mentioned that max_engine_entity was the limit of how many switichable lights were in the map - light, light_spot and light_environment entities that have either a targetname or a style attached to them....i think that might be useful in the -chart report.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
From bspfile.h:
<!--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-->#define MAX_ENGINE_ENTITIES 1024
#define MAX_MAP_ENTITIES 2048
// hard limit, in actuallity it is too much, as temporary entities in the game plus static map entities can overflow<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
I'll look into adding this to the chart. I'm not sure what the difference is between a map entity and an engine entity ATM, so I'll need to track that down before I implement the change.
EDIT: "engine entities" is simply every entity minus static light, light_environment, and light_spot entities. I think that this definition has the potential to be extended with the items that 1.1 doesn't load as entities during runtime; if that is the case I'll probably end up making a mod-specific list of entities to disregard. While "engine entities" does limit the number of dynamic lights in a map, it also appears to include other entity types, so it isn't entirely accurate to say it's a hard cap on dynamic lighting -- removing, say, an info_target appears to allow another light_spot for instance (moral of the story: use the angles key rather than info_target for spot positioning, but you probably already knew that).
As time goes on, I'm seeing more opportunities for specialization of entity handling (NULL texturing by classname, removing clip by classname and flags as currently hardcoded into HLCSG's clipeconomy mode, engine entity counting, etc). I may end up creating a new XML based file format for encapsulating all of this information in a clean and consistant matter... I'll probably begin working on a DTD for tool settings that can be used for specifying specialized additional per texture and/or per entity information sometime in the next month or so.
I've bumped the version to p9.
The new version also includes a patch by Nemo1024 that adds backward compatability with the older SDK 2.2 hull file format. The change doesn't affect anybody using the new format--you can ignore it unless you've wanted to use the old format.
While I'm posting, I'd like to plug another tool being developed by a forum member here: <a href='http://extension.ws/hlfix/' target='_blank'>HLFix</a> is an independant .rmf to .map converter that is currently being developed by Jedediah. There is a thread <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=30612' target='_blank'>here</a> about the program and its development.
** Executing...
** Command: Change Directory
** Parameters: C:\SIERRA\Half-Life
** Executing...
** Command: Copy File
** Parameters: "C:\Program Files\Valve Hammer Editor\maps\readyroom.map" "C:\SIERRA\Half-Life\ns\maps\readyroom.map"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\zhlt_alt\hlcsg.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\readyroom"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\zhlt_alt\hlbsp.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\readyroom"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\zhlt_alt\hlvis.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\readyroom"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\zhlt_alt\hlrad.exe
** Parameters: -extra "C:\SIERRA\Half-Life\ns\maps\readyroom"
and nothing else...when hl/ns starts up, its the map i had before i set it up to use these new tools. if i switch it back to the regular zhlt tools, everything works fine. i get all the normal compile output i usually get and the game starts up with my changes..
am i doing something wrong?
** Executing...
** Command: Change Directory
** Parameters: C:\SIERRA\Half-Life
** Executing...
** Command: Copy File
** Parameters: "C:\Program Files\Valve Hammer Editor\maps\readyroom.map" "C:\SIERRA\Half-Life\ns\maps\readyroom.map"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\zhlt_alt\hlcsg.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\readyroom"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\zhlt_alt\hlbsp.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\readyroom"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\zhlt_alt\hlvis.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\readyroom"
** Executing...
** Command: C:\PROGRA~1\VALVEH~1\tools\zhlt_alt\hlrad.exe
** Parameters: -extra "C:\SIERRA\Half-Life\ns\maps\readyroom"
and nothing else...when hl/ns starts up, its the map i had before i set it up to use these new tools. if i switch it back to the regular zhlt tools, everything works fine. i get all the normal compile output i usually get and the game starts up with my changes..
am i doing something wrong? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Double check that you have the dlls mentioned in the first post -- if you don't the tools will fail to run (the dlls are for all MSVC++ programs using .Net, which is basically MS Visual Studio 7.0... Other releases of the tools use an intel compiler that doesn't require the dlls but builds larger executables).
If that doesn't work, PM me and I'll help you troubleshoot.
Theoretically, moving the map and compiling it in the game directory should still result in a valid bsp; the drawback is the extra clutter in the game directory instead of your mapping directory.
EDIT: I've added prominent links to the dlls in the first post in case anybody misses them further down in the release comments.
Double check that you have the dlls mentioned in the first post -- if you don't the tools will fail to run (the dlls are for all MSVC++ programs using .Net, which is basically MS Visual Studio 7.0... Other releases of the tools use an intel compiler that doesn't require the dlls but builds larger executables).
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I don't know why I didn't get those before posting. I saw that in the thread.
Call me dumb, like I said. <!--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-->
The order of operations looks unusual.. I think general procedure is to leave the .map file in your VHE maps directory, compile it from there, and then copy the compiled .bsp and .pts to your ns/maps directory - copying the .map to ns/maps isn't going to really do you any good.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Apparently that is how the 'normal' run command is setup in VHE. i've since moved to use the 'expert', which does just what you say.
Thanks for the input.
Very greatful,
Nemo1024.
I have a little doubt, are the zhlt_lightflags (to make the entities block light) not working or is it just me?
No, I'm not using -nopaque, and yes, I've set the proper settings in the entities (it works with the earlier versions of HLRAD)
I have a little doubt, are the zhlt_lightflags (to make the entities block light) not working or is it just me?
No, I'm not using -nopaque, and yes, I've set the proper settings in the entities (it works with the earlier versions of HLRAD)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Looks like I have another maintenance release to make <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
I've built a test case to work with for this one. The opacity code does rely heavily on identifying face/ray intersections to identify when a light is blocked by an entity, so it makes sense that tugging on the strands of that code (the optimization work I did) would affect the final lighting.
I'm torn between fixing the old naive check (testing every ray between two patches against every opaque face vertex until a collision is found or there aren't any more verticies) and re-implementing it--if the problem is happening where I believe it is, I could probably gain another (even larger) speed boost by changing the way light/object intersections are calculated. I'll probably begin fixing this tomorrow, and if there aren't any other developments (read: confirmed bug reports), I'll try to get an updated version posted by next Monday.
EDIT: I'll fix the old algorithm first before I open secondary cans of worms in a clearly identified early adopter release--time to increase confidence in the reliablity of what I'm offering. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
EDIT (2): Well, I tried using 1.7p9 and sure enough the opaque entities appeared to be ignored. I then tried using 1.7 with the same map to compare results, and in my simple test case there wasn't any difference in the final lighting--the entities still didn't cast any shadows. Time to find a case that looks different between 1.7 and 1.7p9 (calling all mappers).
At the moment I'm looking for a case where the lighting is different between the two builds -- I have a no shadow case that's the same for both builds that I can use to test against the pre-optimization code.
Anyway, short answer is, yes, there's definitely a difference in how 1.7 and 1.7p9 handle opaque entities - let me know if you need me to send you anything beyond what you have.
Edit: Odd... I just finished compiling with 1.7p9 and ran the 1.7 demo again to make sure to record the same sequence, and realized that after recompiling the map, the old demo starts exhibiting the same bleed-through problems the new tools use. I never realized demos were that map-dependant. *shrug* Anyway, if you aren't able to reproduce the same difference with the last rmf I sent you, I'll send you the new one.
Hope it helps, it's just a little test room I did, but it shows clearly the problem.
Obviously, the crate is a entity <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Thanks to taleden (again!) and Mendasp for providing test cases for me to work with while tracking this down. The links in the first post point to the updated copy of the files.
I think the flurry of updates should be done for at least a month now as I work on the next round of features (if someone needs another bugfix, however, I will provide it as soon as possible). When I introduce the next round of the tools, I will be tagging a stable release (1.7p10) and a beta release (1.7p# beta#). At that point people can choose if they would rather play with new features or wait for any issues to be resolved before grabbing the latest code.
I completely removed the lightdata limit from opt_plns, the BSP Plane Optimizer--in the other tools, I've only shifted it from 4MB to 6MB, and the change is automatic (no need for a command line switch) because HLRAD will use the minimum space necessary. "opt_plns_readme.txt" lists changes to opt_plns only -- changes to the other tools are documented in "1.7p10 readme.txt".
At this point you're probably wondering why I don't just remove the limit in HLRAD, too...
In the case of the optimizer, there really isn't any reason why it should know or care how much light data a map has since it doesn't do any processing on that data--HLRAD, however, is controlling how large the map grows in memory and therefore how much memory must be used to play the map. I don't want to increase the MAX_MAP_LIGHTING in HLRAD to an unlimited value because I don't know where the potential HL ceiling for that data is before bugs start to appear on low-end machines.
It could be that that you're over the new limit of 6MB-- could you run HLRAD with -chart in the command line and post the console output here? If the number of bytes (next to the percentage) is over 6291456, you're hitting the new limit. If the limit is lower, make sure you're using the latest build (1.7p10) of HLRAD.
If you'd like to try increasing the limit again (at the risk of some undefined behavior that you will definately need to test for before publicly releasing your map), PM me and I'll build a beta version with an 8MB cap for you--I think that 6MB ought to be plenty, but if maps have a lot of surface area and some dynamic lights they can hit the limit pretty quick.
For more information on how light data is stored and how to reduce the total amount in your map, you should see these threads:
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=21930' target='_blank'>125% Of Light Maximum. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->, how to decrease?</a>
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=22914' target='_blank'>Lightdata Maxed Out., with just basic lightning.</a>
Cagey, you should really put up at least a small site for these tools since they are currently the best available. If you like I can integrate it with the hlfix site and take care of the hosting.
Sorry about the problem.
Edit: I'm currently working on getting a site up for the tools on my webspace, but don't have an ETA. If you'd like to provide a mirror for the tools on the hlfix site, that'd be great <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->.