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.
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 surfaceadditive 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 mapsnormal 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)I think these bugs should be reported to Mark, it seems like they're a big problem for more advanced usage.
*agrees and nods*
Wow… I feel so… inferior…