Dodgy Lighting In Am

ChromeAngel · September 2003

<div class="IPBDescription">RAD/OptPlns bug?</div> I've been postponing the release of a new version of AtomicMass becuase I haven't been able to fix a lighting bug that shows up in the airlock.

<img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'>

On the umpteenth time through the compile process I noticed that OptPlns was reporting 126.5% of the maximum lightdata was being used (but RAD reports only 84% used), I guess this is what's causing my blotchy airlock.

Can anyone suggest a fix?

Here's a sample from the compile log, starting with RAD's chart :

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'>
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 184/400 11776/25600 (46.0)
planes 30140/65535 602800/1310700 (46.0)
vertexes 20097/65535 241164/786420 (30.7)
nodes 8918/32767 214032/786408 (27.2)
texinfos 9699/32767 387960/1310680 (29.6)
faces 16026/65535 320520/1310700 (24.5)
clipnodes 25290/32767 202320/262136 (77.2)
leaves 4916/8192 137648/229376 (60.0)
marksurfaces 20215/65535 40430/131070 (30.8)
surfedges 71568/512000 286272/2048000 (14.0)
edges 36921/256000 147684/1024000 (14.4)
texdata [variable] 1139592/4194304 (27.2)
lightdata [variable] 5307222/6291456 (84.4)
visdata [variable] 131442/2097152 ( 6.3)
entdata [variable] 50170/524288 ( 9.6)
134 textures referenced
=== Total BSP file data space used: 9221032 bytes ===
2410.05 seconds elapsed [40m 10s]

----- END hlrad -----

** Executing...
** Command: F:\FPS\HL\Hammer\tools\opt_plns.exe
** Parameters: -nopause f:\fps\hl\WORLDC~1\maps\ns_am

BSP Optimizer by XP-Cagey, v1.4
Based on code by Valve Software

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 184/400 11776/25600 (46.0)
planes 30140/32767 602800/655340 (92.0)VERY FULL!
vertexes 20097/65535 241164/786420 (30.7)
nodes 8918/32767 214032/786408 (27.2)
texinfos 9699/32767 387960/1310680 (29.6)
faces 16026/131071 320520/2621420 (12.2)
clipnodes 25290/32767 202320/262136 (77.2)
leaves 4916/8192 137648/229376 (60.0)
marksurfaces 20215/65535 40430/131070 (30.8)
surfedges 71568/512000 286272/2048000 (14.0)
edges 36921/256000 147684/1024000 (14.4)
texdata [variable] 1139592/4194304 (27.2)
lightdata [variable] 5307222/4194304 (126.5)VERY FULL!
visdata [variable] 131442/2097152 ( 6.3)
entdata [variable] 50170/524288 ( 9.6)
=== Total BSP file data space used: 9221032 bytes ===

Planes in map: 30140
Planes actually used: 9596
</td></tr></table><span class='postcolor'>

taleden · September 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ChromeAngel @ Sep 9 2003, 01:57 PM)</td></tr><tr><td id='QUOTE'>
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
lightdata [variable] 5307222/6291456 (84.4)

----- END hlrad -----

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
lightdata [variable] 5307222/4194304 (126.5)ctually used: 9596
</td></tr></table><span class='postcolor'>
If you look at those log files closer, you'll notice that hlrad allows up to 6.2gb of lightdata, while the bsp_optimizer allows only 4.1gb - hence the same amount of light data fits in hlrad's limits but not in opt's. I believe Cagey increased limits across the board in the base four tools in order to give mappers more breathing room during the compile process, figuring that the optimizer would remove unnecessary data and hopefully bring everything down inside the actual limits imposed by HL/NS.

It's also possible Cagey just made a typo somewhere and either 6.2 or 4.1 is the actual limit at all times. <img src='http://www.natural-selection.org/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

Anyway, I'd say try compiling the airlock separate from the rest of the map (so you can see how it compiles when you don't overrun the limits) and see if it looks correct then - if so, then the problem probably is, in fact, overrunning the light data limit, in which case you'll just have to simplify your map's lighting - remove some lights, remove some dynamic lights, etc.

Ollj · September 2003

Got any leaf portals saw into leafes?
You're one of the most experienced with RAD errors, I feel unworhty making more suggestions.

Sometimes RAD does really werid stuff.
Nodes at 150.000%

NerdIII · September 2003

I've devided 126.5% by 84.4% and the result is 50% so it is improbable that it is a typo. Though Ollj made a typo, because the '.' and the ',' are the other way round in the English language.
Yes... I'm sooo nit-picky...

ChromeAngel · September 2003

I think Ollj might be on to something, so i'm working on tracking down my leaf portal saw into leaf problem. I'll update you if it fixes it.

KungFuSquirrel · September 2003

You're using the updated HLRad executable which has support for 6 megs of lightdata instead of 4. The Planes Optimizer hasn't been updated with this limit, from what I see here.

However, I will remind you that the lightdata expansion Cagey attempted in that version did not work - it massively increased bsp file size and caused major performance issues on ns_nothing during my tests with it, and unless those issues can be resolved, I do not recommend trying to sidestep that lightdata limit.

I'd work on getting rid of dynamic appearance lights. Maybe all of them. Even 1 of them jacked Eclipse over the lightdata limit by about 15% a few versions back.

ChromeAngel · September 2003

I've fixed the leaf portal saw into leaf error, but i'm still getting the same %age of lightdata.

Dynamic appearance lights eh? I'll have a go at that tomorrow.

[edit]
I'm using the p10 version of RAD.
[/edit]

Cagey · September 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ChromeAngel @ Sep 9 2003, 03:43 PM)</td></tr><tr><td id='QUOTE'>I've fixed the leaf portal saw into leaf error, but i'm still getting the same %age of lightdata.

Dynamic appearance lights eh? I'll have a go at that tomorrow.</td></tr></table><span class='postcolor'>
There is a known bug in RAD p11 reported by Kage that caused me to pull the distribution -- if you are using p11 and don't still have p10 on your drive, I'd download it again from the webbed thread.

Opt_plns lists the old max lightdata from Merl's build in the chart, but it dynamically allocates exactly the space needed to load the lightdata from the map as of v1.4, so that's not where the error is being introduced. If you gave it a bsp with 50 megs of lightdata (or texdata, or entdata), it would theoretically operate without a complaint.

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'>However, I will remind you that the lightdata expansion Cagey attempted in that version did not work - it massively increased bsp file size and caused major performance issues on ns_nothing during my tests with it, and unless those issues can be resolved, I do not recommend trying to sidestep that lightdata limit.</td></tr></table><span class='postcolor'>

Adding 9MB of lightdata has a tendancy to add 9MB to the overall map size--not much I can do about that <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>. I don't expect the performance issues to be resolvable either, but there is a (not yet exactly determined) sweet spot over 4MB and under 9MB where the game will still run well with maximum flexibility. Unlike the planes limit, the effect of lightdata on performance appears to be related to hardware (video card memory?).

The "p" series has used 6MB as its RAD limit since p3 (released over six months ago) and people have come very close to that mark without reporting problems, so 6MB appears to be OK. p12 will use 6MB as the default cap and allow people to experiment with more--I'm including a disclaimer in the p12 readme that adding lightdata over the default cap can ruin performance.

The new tools will partially optimize the lightdata by using overlapping start indices for common light patterns -- light patterns will be more likely to match once people have fine control over when and where light spreads, which will also be introduced with the new toolset. The situation is analogous to where the MAX_PLANES limit was in December -- upping the limit by brute force failed (badly), so optimization needs to be performed to raise the practical limit.

Interestingly (to me anyway <img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'> ), lightdata issues were extremely rare until recently because dynamic lights never bounced before the dynamic texlight code was added -- many more faces are now seeing dynamic light data as a result of bounces, which is why this limit suddenly matters after not coming into play for many years. Yes, bounce control is also going into the new toolset.

amckern · September 2003

consider useing MHLT and see if it is XP-Cagey's that have an issue with them

amckern

ChromeAngel · September 2003

amckern, I can't do that because of the planes limit in those tools.

Giving all the dynamic lights (except 2 special cases) normal appearance has reduced AM's light data to 95% of OptPLns maximum, BUT i'm still getting the error in the airlock. <img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'>

Here's a picture of the offending area in-case it helps.

taleden · September 2003

Weird. I dunno what to tell you.. the only times I've gotten faces being bizarrely illuminated like that were either bugs in Cagey's new rad code (since fixed) or because I had transparent textures on an entity brush and accidentally set the render mode to texture instead of solid - texture/255 is always fullbright, but it also removes blue areas like solid does, so it took some poking to notice it. <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

Anyway, I'm assuming that wall isn't an entity, so.. I dunno, what happens if you put a spotlight pointed right at it? Does the spotlight get added to the sourceless brightness, or replace it? I believe I've heard of rad doing strange things to a side if that side is actually receiving ZERO light.

*shrug* If I think of anything else I'll post. <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

Confused · September 2003

i had a similar problem the whole one box on the level that didnt light right, in my case it was rendered with zerop light the flash light didnt even work inside as i recall it ended up being the over all volume of teh level i think as it would run right ther if i big blocked the other side

ChromeAngel · September 2003

taleden, it is actualy an entity, most of what you see in that shot is part of a func_doorrotating. If the rendermode was dodgy it'd be effecting all the faces of the entity.

taleden · September 2003

Hm.. have you tried turning them back into world brushes and compiling again? That'd tell you if the lighting is due to its being an entity or due to its position.. if the former, have you tried playing with all of the flags, like blocks light and embedded fix? If it's all part of one entity it does seem like the same thing should happen to the whole thing, but you never know.

ChromeAngel · September 2003

Cordening of the airlock and compiling it on it's own duplicated <i>part</i> of the error. I've just got a copy of hlrad version p11 from KaiserRoll, compiling the cordened section with that lights fine, so it migh be something in the p10 hlrad. I'll do a full compile with p11 tomorrow and see if that fixes it.

taleden · September 2003

Cool.

Sort of off-topic, but.. are KaiserRoll and Cagey working together on tools now? I haven't been on the boards much over the summer, last I heard the tools were Cagey's baby. Anyway, new versions are always nice.. I've got some odd light effects in my map too, especially on beta compiles (lower rad settings), maybe p11 will clean all that up. <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

ChromeAngel · September 2003

KaiserRoll is just a mapper who happened to have a copy of p11 (as far as I know). p11 is apparently so bugy Cagey wants us to stick with p10 until he can release p12. Their is a whole thread about this webbed at the top of the forum.

Cagey · September 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ChromeAngel @ Sep 10 2003, 02:00 PM)</td></tr><tr><td id='QUOTE'> p11 is apparently so bugy Cagey wants us to stick with p10 until he can release p12. Their is a whole thread about this webbed at the top of the forum. </td></tr></table><span class='postcolor'>
I accidentally compiled the public version of p11 with a #define that included some beta optimization code, so yeah, it's really not a good idea to use it. AFAIK p10 is stable with the exception of the known buffer overflow when you exceed the preset lightdata or specify too little texdata in VIS / RAD.

p12 is sitting on my drive now awaiting testing. The main difference between p12 and p10 will be the new buffer overflow protection (fatal error saying that you've exceeded a limit instead of random wierdness/crashing without an error). Extra lightdata is still an option (introduced in p11) but there are known problems at 9MB, so you'll have to test if you go over the 6MB that I've set as default since p3. I'm going to compile without the second wave of RAD optimizations for now because I probably won't get around to testing them with my focus on the new tools.

EDIT: as stated above, the 4MB listed in the chart for opt_plns doesn't indicate the actual amount of memory that opt_plns allocates -- if there is a bug in the tools causing the problem, it'd be in RAD p10; I'm almost positive that I've made the optimized version of RAD in p10 behave identically to Merl's build.

ChromeAngel · September 2003

WOOOHOOO!!!

p11 does it for me <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'>

I'm sorry Cagey I didn't mean to make it sound like p11 was buggy.

New AtomicMass will be released tomorrow <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

Cagey · September 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (ChromeAngel @ Sep 11 2003, 09:46 AM)</td></tr><tr><td id='QUOTE'>I'm sorry Cagey I didn't mean to make it sound like p11 was buggy.</td></tr></table><span class='postcolor'>
No offense taken Chrome, especially since Kage <i>is</i> having a problem with p11 RAD as noted in the webbed thread <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>--I haven't tried to diagnose it yet and it didn't appear on my test maps, but I figured I'd rather pull p11 than have another situation like the problems that led to the "-oldmath" swtich in the older versions.

I've learned that it takes a thick skin to develop tools for the Half-Life community (see amckern's response on the first page <img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'>). The p series has been blamed for everything up to and including Half-Life no longer running after someone tries to compile a map; people tend to see a new program as the most obvious culprit for new problems.

Geez, I need to stop whining and get back to coding <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'>.

NerdIII · September 2003

People tend to think that only Microsoft's coders make programs crash.
I remember the day our math teacher handed us some programmable calculators. (It must have been some PR thing of the company selling them). Two days later I came back and I was pretty proud of what I had coded (without a manual). When I showed the class my 'snake' program in development I found a bug and went to correcting it. After the first few pages of code I heard some class mates' gasp of unbelieve that this little program takes so much code... yes, every program is an essay for itself. And it is for a reason that the compile tools are split in four. It is a lot of work to keep the thing together and to remember what every function exactly does, what errors are already caught in which parts of the program and what can still make it crash on another line of code. Respect! I guess only few people have the brain to write complex mathematical algorithms on highly optimized data structures. And in the end you don't even have anything visible as a result of all the work. Just a little .exe program without an icon <img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'>
I wonder where you get your motivation Cagey. Respect! Respect! Respect!

Dodgy Lighting In Am

Comments