Lightdata

Some_tall_guy1

<div class="IPBDescription">is there a way to reduce it?</div> I'm getting a little worried about the lightdata on my map as its already 50% full. I was wondering if there was a way to reduce this number?

NerdIII

I only know of one obvious way: Make the light patches bigger.

Ollj

bigger light patches.
less textures scaled <1 .
less different KINDS OF light sources.
less dynamic light.
usage of NULL and BLACK texture.
lower reflection count, better vis-blocking.

NerdIII

You wanna say the BLACK texture is not only black but recognized by the compile tools as not to be lit?!?
I learn new things every day on this forum <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->

Cagey

<!--QuoteBegin--NerdIII+Aug 20 2003, 06:55 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (NerdIII @ Aug 20 2003, 06:55 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> You wanna say the BLACK texture is not only black but recognized by the compile tools as not to be lit?!?
I learn new things every day on this forum  <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
actually, it's not--but that would be a good optimization to make--removing dynamic lightdata from both BLACK and any objects that aren't lit by the engine do to their renderproperties would probably knock down lightdata quite a bit <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->

The new tools will allow this sort of per-texture or per-entity control over lighting.

If you're using 1.7p11, however, you can up the lightdata at any time by giving the new amount in the command line.

EDIT: used to say the following, which is apparently not true: <span style='color:gray'>The 2.0 version of NS_nothing uses about 9MB of lightdata without any problem.</span>

KungFuSquirrel

Thing is, it doesn't. Like I mentioned in the other thread, I had to remove the extra light appearances to drop it back down to fix numerous performance (and file size) complaints.

Cagey

<!--QuoteBegin--KungFuSquirrel+Aug 20 2003, 09:38 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (KungFuSquirrel @ Aug 20 2003, 09:38 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Thing is, it doesn't. Like I mentioned in the other thread, I had to remove the extra light appearances to drop it back down to fix numerous performance (and file size) complaints. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->

(EDIT: moved over from the other thread)

I should have asked about it instead of assuming you were good to go when I didn't get another response after I suggested testing . It's not every day I stick my foot in my mouth, but when I do I usually go all out.

The tools in the public release are newer (variable lightdata is now available from the command line instead of just allocating that massive 20MB hunk), but if there are performance issues with extra lightdata, any version without the cap is going to have identical problems; there haven't been any changes to how anything was calculated in either the version I gave you or the latest public release, just the amount stored.

Out of curiosity, how much lightdata did you end up with on the release version of Nothing? I'd like to get a feel for where the limit should be in practice.

HL and Op-Force use a 2MB cap, and Merl upped that to 4MB. I later upped it again to 6MB after getting some requests from NS mappers--evidently things are still OK at that point. So the performance problems are apparently occurring somewhere between the 6MB and 9MB mark; the problem could also be related to the amount of memory being used for other things, e.g. more texdata might mean less space for lightdata before older systems end up swapping data every frame and killing performance.