Be Warned.... A Rant on L3S.....

Posted by Adventus on Oct. 1, 2006, 2:12 a.m.

Since i've never had a real rant before and this lighting engine is consuming my life, heres a rant about L3S which i doubt most of you guys (no offense) will understand…. except maybe GearGOD:

I've read all i can find on light blooms, but i would just like to double check if you guys reckon this looks like a decent bloom?

<img src='http://img216.imageshack.us/img216/7160/pheonixl3s4lu0.th.jpg'></img><img src='http://img223.imageshack.us/img223/6061/pheonixl3s5jb5.th.jpg'></img>

You may (unlikely….) have noticed that im not redrawing the room to a surface to achieve this effect (as all the tutorials seem to imply you need to)…. But it seems to make little difference, which is fairly logical since its only the light that blooms, not the objects. I also had alot of trouble with that stupid alpha bug when getting this up and running, several times i've had to additively render a black square just to reset the alphas. Also i may have run into yet another undocumented bug (which is quite annoyingly lives up to its name)…. surfaces arent being clipped to zero properly. For instance if i have a random surface filled full of junk then subtractively draw an rgb(254,254,254) square over it, things which should be clipped to zero (aka anything thats not pure white) will instead be set to rgb(1,1,1)….. which totally screws me over. Its seems to occur pretty randomly though, maybe its my fault in some way or possibly bm_subtract is a smooth subtract or something wacky.

Anyway I was a bit worried about the extra overhead im adding by inserting all these conditions into the main cycle (like checking if a light casts soft shadows, etc), but I just recently thought of a great optimisation which i should of thought of earlier. Im setting d3d_transform_set_translation(-view_xview,-view_yview,1) so i dont need to subtract the views position each time i render to a surface. It also helps in the general quantity of code that GM has to interpret since, with this adjustment, i can further optimise the normal bbox caster down to setting just 5 variables each loop.

I've also tested and ironed out the mesh static caster system, but im a bit disappointed with the speed gains it gives, only around 10% per light, although it maybe because my GPU not CPU is the bottleneck in my system. I've also added the option of using a surface as a static caster & nearly completed a mesh based culling system which only updates the required meshs, although i've a sneaking suspicion that all this testing per step to detect changes will undermine the speed gains i get.

Cheers and if that aint rant worthy i dont know what is.

Comments

Adventus 18 years, 1 month ago

Quote:
Nah, it's just fancy terms for relatively straight-forward techniques.
Exactly.