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

GearGOD 17 years, 7 months ago

I've been shat up the walls with both those bugs. Especially the one about a surface not being reduced to 0. I can't track down it's exact origin so I never reported it.

Blooms look okay for blooms but consider that no one is actually going to have a nutsy white light that consumes half the screen in pure white so when you're tweaking that stuff try to do it with a realistic scenario.

I'll tell you what I've done with l2s if you're interested in making any of those additions to l3s.

I added a spec highlight pass where one of the free surfaces is reused to render a bunch of objects which represent spec maps, and then use the 2nd free surface to render a complete set which comes additive on top of everything.The set is basically..

draw completed light surface

additive draw spec-only lights (HAVE this if you're going to deal with spec highlights, these things look very pretty if used right)

multiply with surface containing spec maps

normal draw all caster sprites/outlines and if they have an emmissive map, draw that instead (this does the double task of drawing the ever-pretty emmissive glows, and blacking out the parts of spec-only lights that are over casters)

Adventus 17 years, 7 months ago

Quote:
Blooms look okay for blooms but consider that no one is actually going to have a nutsy white light that consumes half the screen in pure white so when you're tweaking that stuff try to do it with a realistic scenario.
Yea i was trying to get the same effect you had in that bloom.exe you released awhile ago. It can be toned down really easily.

Quote:
I added a spec highlight pass where one of the free surfaces is reused to render a bunch of objects which represent spec maps, and then use the 2nd free surface to render a complete set which comes additive on top of everything.The set is basically..

draw completed light surface

additive draw spec-only lights (HAVE this if you're going to deal with spec highlights, these things look very pretty if used right)

multiply with surface containing spec maps

normal draw all caster sprites/outlines and if they have an emmissive map, draw that instead (this does the double task of drawing the ever-pretty emmissive glows, and blacking out the parts of spec-only lights that are over casters)
Those sound like great ideas, i've been toying around with some ideas on using those 2 surfaces, these will (hopefully) do nicely. Also its (kind of….) good to hear that the zero-ing bug isnt my imagination, but it is extremely annoying since i was using a clipping method to determing what points on the surface where above the threshold.

Juju 17 years, 7 months ago

I think these bugs should be reported to Mark, it seems like they're a big problem for more advanced usage.

GearGOD 17 years, 7 months ago

Quote:
Those sound like great ideas, i've been toying around with some ideas on using those 2 surfaces, these will (hopefully) do nicely.
By the end everything is done, it will still leave 1 out of the 3 surfaces available for other messing around.

Quote:
I think these bugs should be reported to Mark, it seems like they're a big problem for more advanced usage.
One of them has been, and to the best of my knowledge was ignored. The other one is a bit too vague to report, I don't think anyone actually narrowed it down to an atomic cause. In my case I came across it when fading a surface to black by drawing a mostly seethrough black rectangle over it. Objects drawn on that surface would leave 'trails' would never quite hit black. I dealt with it by clearing the surface at the start to white so it's covered in whatever caused the trails in the first place. Of course that's not a solution, because it meant it will never reach pure black.

Adventus 17 years, 7 months ago

Quote:
I dealt with it by clearing the surface at the start to white so it's covered in whatever caused the trails in the first place. Of course that's not a solution, because it meant it will never reach pure black.
I wonder if it only occurs when clipping to 0, because i <i>may</i> be able to clip to 1 instead and get the same effect. By the way I've followed your directions and implemented spec-only lights and spec and emissive maps, im guessing you just add the resulting surface to the scene.

Quote:

By the end everything is done, it will still leave 1 out of the 3 surfaces available for other messing around.
Yea… now i have to think of something to do with that surface…..

Adventus 17 years, 7 months ago

Quote:
im guessing you just add the resulting surface to the scene.
woops didnt even realise you did say to add to the scene….

OL 17 years, 7 months ago

*agrees and nods*

Adventus 17 years, 7 months ago

Quote:
*agrees and nods*
Haha yea, i seemed have to scare off everyone else….

Acid 17 years, 7 months ago

Wow… I feel so… inferior…

Juju 17 years, 7 months ago

Quote:
In my case I came across it when fading a surface to black by drawing a mostly seethrough black rectangle over it. Objects drawn on that surface would leave 'trails' would never quite hit black.
I've had exactly the same problem - in the end I just hard coded it to draw pure black when it reached almost pitch black. It's not the way I like to do things, but it was the only way I could see at the time.

Quote:
Wow… I feel so… inferior…
Nah, it's just fancy terms for relatively straight-forward techniques.