Lightdata
bERt0r
Join Date: 2005-03-23 Member: 46181Members
Join Date: 2005-03-23 Member: 46181Members
I have long reached the limit Max lightdata limit and have been avoiding it by scaling down textures.
But now i found out, that by simply giving rad the paramieter "-lightdata 10000" i can increase the value without any drawbacks, or am i wrong here? Im sure that todays pcs can handle memory dimensions of like 6 or 10 mb but the HL engine is a different thing...
If it would be no problem i could only concentrate on r_speeds when it comes to details!
But now i found out, that by simply giving rad the paramieter "-lightdata 10000" i can increase the value without any drawbacks, or am i wrong here? Im sure that todays pcs can handle memory dimensions of like 6 or 10 mb but the HL engine is a different thing...
If it would be no problem i could only concentrate on r_speeds when it comes to details!
Comments
There is a better way to decrease lightdata. use lots of point based lights to light screens like I did on my map. And then use -nodynbounce. I managed to get down from arround 90% to 39%.
This way you have 4 points lights lighting the screen it looks pretty good (if ya ask me better then textlight) Plus the added benefit you safe a lot of point lights this way. If you would use a textlight for that same surface you will get a lot more lights, which have to be calcuated and stored.
This method is more work, but you get better performance overall and I personally think it looks better. This way you also don't have to use an overlay (func_illusionary) to light just the light area. Overall saving runtime entities.
There is no limitation of lightdata described in the mapping guidelines - and maps could be sooo much prettier with a higher value.
Another point is, that i think this is only a client side related issue... The problem with the entities is only because of the servers having too much work <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Maybe it won't impact the performance much. But it will increase the filesize, so I think it would also impact the engine it's performance. Maybe someone with knowledge of the compiling tools and engines internal working can enlighten us, I dunno. Cagey aint arround anymore <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" />
The runtime entities I was talking about has nothing really to do with lightdata. I just implied that using my method you can light the light emitting area of the texture and make it look good (IMHO better). This without the use of the runtime entities func_illusionaries eating away at the maximum runtime entity count...
Hmm you know any Hl-Engine expert? <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
The only thing that affects the lightdata used by each polygon is:<ul><li>The texture used: The following textures don't have lightmaps generated at all and don't contribute to lightdata:<ul><li>SKY</li><li>NULL</li><li>Water (begins with '*' or '!')</li><li>Possibly trans (begins with '@' or 'TRANS')</li></ul></li><li>The size of the polygon: The Half-Life engine has a hard limit on lightmap size of 16x16 with each lightmap value covering 8 texels. Polygons larger than 256x256 are split to prevent this limit being exceeded.</li><li>The polygon's texture scale: Decreasing the texture scale means the polygon's lightmap will cover less area (in world units) and the polygon will have to be split sooner.</li></ul>Also, faces hit by more than one switchable/flickering light will have one lightmap generated for <i>each unique light style</i> that affect them, up to a maximum of four lightmaps. You can increase the threshold at which a face is considered to be affected by dynamic lights by setting the "-coring" parameter of hlrad to a value >= 1. This may result in harsher edges at light boundaries, though.
Texture lights and point lights are identical as far as lightdata/performance goes; they are both transformed into the same internal representation when hlrad begins (this is the direct lights/BuildFaceLights in the compile log).
Given the above, you can decrease the size of your lightdata by covering unseen polygons in NULL (those on the outside of the map will be removed by hlbsp, so don't bother with those); increasing the texture scale where possible; reducing the use of multiple lightstyle; and increasing the coring value. I'm not aware of any actual limit to the lightdata size; the "-lightdata" switch is really just because it's easier for hlrad to allocate all the lightdata up front rather than continually reallocate every time it finds out it needs more.