Lightdata Maxed Out.
Ollj
our themepark-stalking nightmare Fade Join Date: 2002-12-12 Member: 10696Members
our themepark-stalking nightmare Fade Join Date: 2002-12-12 Member: 10696Members
<div class="IPBDescription">with just basic lightning.</div> after BSP:
models 137/400 8768/25600 (34.3%)
planes 24710/65535 494200/1310700 (37.7%)
vertexes 12700/65535 152400/786420 (19.4%)
nodes 5441/32767 130584/786408 (16.6%)
texinfos 6126/32767 245040/1310680 (18.7%)
faces 10029/65535 200580/1310700 (15.3%)
clipnodes 28152/32767 225216/262136 (85.9%)
leaves 3019/8192 84532/229376 (36.9%)
marksurfaces 12304/65535 24608/131070 (18.8%)
surfedges 46232/512000 184928/2048000 ( 9.0%)
edges 23351/256000 93404/1024000 ( 9.1%)
texdata [variable] 4540/4194304 ( 0.1%)
lightdata [variable] 0/4194304 ( 0.0%)
visdata [variable] 0/2097152 ( 0.0%)
entdata [variable] 18543/524288 ( 3.5%)
why is my lightning (after full vis and basic rad) always at 110% even if its minimalistic and non dynamic lightning?
Tried it with point lights and texture lights.
so what does lightdata mostly depend on?
Do 2 (same) small lights in one room need as much lightdata as one big light?
Do 2 different kind of lights in 2 rooms need more lightdata than 2 same lights in 2 rooms?
Does a blocky wide room needs more lightdata than a complex small room (with same hull surface sizes, just a different volume) ?
Does a small skybox need less lightdata than a large skybox - making skybox rght behind the window or let a free space behind with stuff in it.
Does -Bounce 4 need more lightdata than -bounce 2?
What settings do deccrease lightdata?
models 137/400 8768/25600 (34.3%)
planes 24710/65535 494200/1310700 (37.7%)
vertexes 12700/65535 152400/786420 (19.4%)
nodes 5441/32767 130584/786408 (16.6%)
texinfos 6126/32767 245040/1310680 (18.7%)
faces 10029/65535 200580/1310700 (15.3%)
clipnodes 28152/32767 225216/262136 (85.9%)
leaves 3019/8192 84532/229376 (36.9%)
marksurfaces 12304/65535 24608/131070 (18.8%)
surfedges 46232/512000 184928/2048000 ( 9.0%)
edges 23351/256000 93404/1024000 ( 9.1%)
texdata [variable] 4540/4194304 ( 0.1%)
lightdata [variable] 0/4194304 ( 0.0%)
visdata [variable] 0/2097152 ( 0.0%)
entdata [variable] 18543/524288 ( 3.5%)
why is my lightning (after full vis and basic rad) always at 110% even if its minimalistic and non dynamic lightning?
Tried it with point lights and texture lights.
so what does lightdata mostly depend on?
Do 2 (same) small lights in one room need as much lightdata as one big light?
Do 2 different kind of lights in 2 rooms need more lightdata than 2 same lights in 2 rooms?
Does a blocky wide room needs more lightdata than a complex small room (with same hull surface sizes, just a different volume) ?
Does a small skybox need less lightdata than a large skybox - making skybox rght behind the window or let a free space behind with stuff in it.
Does -Bounce 4 need more lightdata than -bounce 2?
What settings do deccrease lightdata?
Comments
Do 2 different kind of lights in 2 rooms need more lightdata than 2 same lights in 2 rooms?
Does a blocky wide room needs more lightdata than a complex small room (with same hull surface sizes, just a different volume) ?
Does a small skybox need less lightdata than a large skybox - making skybox rght behind the window or let a free space behind with stuff in it.
Does -Bounce 4 need more lightdata than -bounce 2?
What settings do deccrease lightdata? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
<!--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-->so what does lightdata mostly depend on?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
The light data is proportional to the amount of wall/floor/ceiling that needs to be "painted" with light. The map stores the precalculated amount of light on each surface instead of figuring out how the map should be lit in realtime, so the more surface you have the more storage the map requires. In addition, each type of light (normal, flicker A, slow strobe) is painted on a different layer. Layers other than normal light are only added to the map file if that type of light is hitting the individual spot being painted (each "spot" is actually much larger than a pixel... the size is determined by the -chop parameter). To get the amount of data required to light a single spot, multiply the number of light types hitting that spot by 3 bytes (which hold the amount of red, blue, and green light for each layer).
<!--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-->Do 2 (same) small lights in one room need as much lightdata as one big light?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Yes, possibly more if the lights have different styles (e.g. one is flicker A and one is flicker B) and overlap.
<!--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-->Does a blocky wide room needs more lightdata than a complex small room (with same hull surface sizes, just a different volume) ?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Depends on the total surface area of the rooms--if you have many nooks and crannies instead of a simple box, it can increase the data size because there's more surface to light.
<!--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-->Does a small skybox need less lightdata than a large skybox - making skybox rght behind the window or let a free space behind with stuff in it.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
If you have a free space with stuff in it, the stuff will have additional lightdata even if it's not visible to the player--the engine will still want to know how bright to make those surfaces.
<!--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-->Does -Bounce 4 need more lightdata than -bounce 2?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Potentially, if you're using a flickering light that reaches more surfaces using -bounce 4. In most cases, however, you shouldn't see a difference.
The color of the light for each style is stored at each sample point -- if the same light style bounces off a surface a few times, it brightens the total light by changing the color in that layer instead of adding a second set of color information. If a new style of dynamic light hits a surface that it didn't using -bounce 2, a new layer of color information will be added to the surface.
<!--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-->What settings do deccrease lightdata?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Setting -chop higher might help. Unfortunately, it will reduce the number of lighting spots ("radiosity patches") on your map, giving you blockier lighting.
<!--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-->its maxed with sparse. thats the confusing.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
According to the hlrad program useage, -sparse uses a reduced memory vismatrix algorithm... I don't see why the vismatrix method would greatly affect the final amount of lightdata--it might change the colors significantly, but not the need to store them as 24 bit samples.
For the record, I didn't touch the lighting code when I made the 1.7p distribution (letter on the end of the version number is important). 1.7p2 upped the lightdata limit to 6MB, but still doesn't contain anything that would affect the amount of lightdata being generated.
Of the three problems with 1.7p I've seen, two were configuration (and have been worked through) and one was this lightdata limit being hit by gaggle and Ollj. There have been 2 crash bug fixes with opt_plns, but that doesn't have anything to do with Ollj's problem.
Of course, Ollj doesn't have to take my word for it if he's willing to spend the time compiling with a different build (since he's under the 32K planes limit, he doesn't need to use 1.7p)... it's his time <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
Edit: spelling
<!--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-->
+-
| \
\ \
\ \
\ \
\ \
\ |
-+
<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
may be covered with a rectangular lightmap like 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-->
+-------+
| |
| |
| |
| |
| |
| |
+-------+
<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
thus creating much more lightmap area than actual surface area in your map.
the size of a patch is default face size or (64 x the texture scale), whichever is smaller, unless you -chop, -texchop, -extra, or -notexscale.
so if you have a lot of brushes with texture scaled smaller than 1, you will get more patches = more light data.
to divorce the patch size from the texture scale, use RAD -notexscale. then only the face size, or 64x64, or the -chop/-texchop/-extra you specify count, which ever is smallest.
the other thing to affect lightdata is how many styles of light shine on that patch. you can have a max of 4 - 3 dynamic/changing/switchable, and 1 lightmap for fixed/static lights. the lightmap can be made up of up to 8 light types - type by color, brightness, name, kind. example: one env_light, one spotlight, 3 different texture lights, and 3 different brightness light enties = 8 light types for the lightmap.
so each patch gets recorded the lightmap data and the data of how it looks in 3 different dynamic lights, this gives a possible 8 different light combos to be recorded for that patch in lightdata.
<b> conclusion: the main ways to reduce lightdata is 2.
first make sure to miminize the number of patches, keep them larger.
second try to minimize the number of dynamic lights that shine on an area.</b>
the size of a patch is default face size or (64 x the texture scale), whichever is smaller, unless you -chop, -texchop, -extra, or -notexscale.
so if you have a lot of brushes with texture scaled smaller than 1, you will get more patches = more light data.
to divorce the patch size from the texture scale, use RAD -notexscale. then only the face size, or 64x64, or the -chop/-texchop/-extra you specify count, which ever is smallest.
the other thing to affect lightdata is how many styles of light shine on that patch. you can have a max of 4 - 3 dynamic/changing/switchable, and 1 lightmap for fixed/static lights. the lightmap can be made up of up to 8 light types - type by color, brightness, name, kind. example: one env_light, one spotlight, 3 different texture lights, and 3 different brightness light enties = 8 light types for the lightmap.
so each patch gets recorded the lightmap data and the data of how it looks in 3 different dynamic lights, this gives a possible 8 different light combos to be recorded for that patch in lightdata.
<b> conclusion: the main ways to reduce lightdata is 2.
first make sure to miminize the number of patches, keep them larger.
second try to minimize the number of dynamic lights that shine on an area.</b> <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Basically right (your conclusion is right on), but with a few clarifications:
-extra doesn't actually chop up the surface any finer than a normal compile -- it tests the surface at more points and uses an average value to fake a smoother edge (a process called oversampling). I discuss oversampling in minimap generation with some pictures <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=5&t=20485&hl=oversample' target='_blank'>here</a>.
If the one env_light, one spotlight, three different texture lights, and 3 different brightness light entities in your example are all static lights, the engine sums the color contributions of all eight since their brightness factors won't vary independantly (explanation in next paragraph), so it only counts as a single light "style".
Referring to my previous post above, all static light is painted on the same layer. If you made the env_light and light entities switchable/dynamic, it would need to be on a different layer for each independantly variable type of light -- since strobe goes dark at a different time than a swithable light, it requires a different layer. The game uses the formula "sum[(layer color)*(brightness factor at time T)]" to get the light color for a given time and location, which it then multiplies by the texture color at that location to get a final pixel color for that spot. Because the game sums the light from each source each frame, if two lights have the same style they can be summed ahead of time during the rad process because the brightness factor will always be the same for a given style and A*B + C*B == (A+C)*B. The static layer always has a brightness factor of 1, other layers vary with time according to the desired effect.
<!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
thanks for the clarification about -extra & oversampling. over the years i have heard so often that oversampling is just dividing the -texchop in 1/2 again, that never made much sense to me....
btw, Cagey, the old zoner's tools seemed to have a limit of 8 for the static "lightmap" style, would you know if Merle's tools have increased that limit? nm, maybe i should ask him.....
Didn't know about that limit -- /me dives into the source code again to see why that would be...
It could be that there is a step where the lights that affect each face are accumulated before the actual lighting numbers are calculated (best guess I can come up with off the cuff <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ), but I'm not sure why that limit would be necessary in general.
I didn't see anything in the source that would limit the number of static lights shining on a single spot... Attached a test map that has 24 static lights in close proximity... doesn't seem to cause a problem, so the limit appears to be gone. There is a cap on the number of texture lights on a map, and I think there may be a cap on total light entities, but not on a per-patch basis.
btw, this is also my clip hull generation bug test map--to see bug #1, walk into the center of one of the diagonal sides of the trianglar platform and try to jump on it. To see bug #2, strafe-walk along and into the angled outer wall (both directions at once). I have solutions to both problems at the tool level I'm currently finishing up <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
when i said 8 lights, i meant 8 light types. 24 static of the same type = 1 type. (at least the 4 i checked had the same color & brightness, same no name, same light entity.
AFAIK, you can combine only 8 light types into the "Static" lightmap style....at least we used to have that limit. i was told it was an arbitrary decsion, because "the line had to be drawn somewhere" to keep RAD compiling time reasonable. i was just wondering if Merle's tools had that limit, or had changed it.
<!--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-->[Reading texlights from 'C:\PROGRAMME\VALVE HAMMER EDITOR\TOOLS\MERL 1.7\lights.rad']
[9 texlights parsed from 'C:\PROGRAMME\VALVE HAMMER EDITOR\TOOLS\MERL 1.7\lights.rad']
10139 faces
Create Patches : 10894 base patches
91 opaque faces
1182556 square feet [170288080.00 square inches]
61 direct lights
BuildFacelights:
(612.20 seconds)
BuildVisLeafs:
(42.73 seconds)
visibility matrix : 0.6 megs
MakeScales:
(40.32 seconds)
SwapTransfers:
(5.76 seconds)
Transfer Lists : 770232 : 770.23k transfers
Indices : 1264328 : 1.21M bytes
Data : 3080928 : 2.94M bytes
GatherLight:
...
<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
470040 square feet [67685896.00 square inches], 60% finished
tommy14:
Ah, think I understand you better now.... variance in brightness and color shouldn't matter to the cap, variance in name does matter because independantly named lights are indepentantly switchable (even if they're not actively targeted) and therefore have potentially independant brightness factors and can't be summed. I'm pretty sure that static unnamed point light ents (light, light_spot) always sum with tex lights, but I haven't tested to make sure.