I ve been orienting my rendering pipeline toward glsl for a while now, after reading 2 years old posts in hereâ€¦ I can easily say that I m behind! But I ll like to catch up on the rendering architecture!
My main concern is how is lighting/shadow are handle!
Well, I m one of those that thinks that laziness is the foundation of affectivityâ€¦ that saidâ€¦ multipasses is not considered as an alternative so farâ€¦ until further arguments is brought to the tableâ€¦ I think itâ€™s a workaround for bad designâ€¦ first thing I hear on this isâ€¦ “vertex are cheap bla blaâ€¦” maybe, but my brain wont allocate a memory bloc for this pointer and will eventualy crash!
The first question mark would be:
I heard that professional engines rendered one pass per light and blend each pass in the frame buffer? Is that correct?
If yes, I still cant figure whyâ€¦ but I should be pretty close to get my answerâ€¦ so far I calculate lighting in one pass… lights are accumulate in the shaderâ€¦ and I donâ€™t see why it should be done other wiseâ€¦ 8 lights maxâ€¦ because im using gl_ states in shaders temporarily, I hopeâ€¦
this lead to a another question:
how hard it is to raise up the number of maximum lights to 128 for instance in opengl?.. why 8 maximum lights? And please, I donâ€™t want a hearâ€¦ you shouldnâ€™t need more then 8 lights at the timeâ€¦ or use any hocus pocus hack not to have toâ€¦. I want the truth!
now, to answer the first thing that comes to your mind atmâ€¦ I know I can use any number of light using shadersâ€¦ butâ€¦ lights have lots of parameters to deal withâ€¦ even though you have to set opengl light states anyways, sending them through shader parameters is more expensive (you may get me wrong on this but I doubt it)â€¦ and I choose not to for the momentâ€¦ I m aware that using gl_ states is in contradiction with my master plan of using infinite number of lights eventuallyâ€¦. but I ve choose to reject this idea so far for simplicity sakeâ€¦ till further development arise on the subject.
In my research so far of using one pass rendering pipeline, it all comes to the same bottle neckâ€¦ opengl/hardware failed to fullfilled my needs (welcome to the club you ll say)â€¦ first, the maximum of lightsâ€¦ second, the max texture matrix stack which is 10 on my gf 7800 and 8 texture unitsâ€¦ why clamping those values so low? What is the problem with those? Still want the cruel truth here! How can Opengl developers not doing anything for this aberrationâ€¦ what s going on, who s in charge here? < — Mad golgoth!
Casting shadowsâ€¦. Still in the idea of using One single pass in the rendering pipelineâ€¦ I manage to make an ugly compromiseâ€¦ and again, because of the low number of texture matrices and texture units available in opengl FFP which I use in the shaderâ€¦ the first 4 matrices/tex Units are used by color, gloss, environment and bump mapsâ€¦ and the next 4 units are used by shadow mapsâ€¦ which leads to a maximum of 4 shadow maps per primitivesâ€¦ and to answer the fire glowing in your eyesâ€¦ yes, I want a be able to use 4 shadow maps per light and I which I can use moreâ€¦ it may sound heretic for most of you, and Im aware of that too.
What would be the smart thing to do:
1- Do One pass per light. â€“ easier shader wise but does it worth multipasses?
2- Do One pass for all the lights + One pass for texturing.
3- One pass does it all.
If One pass does it all:
1- Wait till Opengl 3.0 and hope for max Units upgrade â€“ bye bye backward compatibilityâ€¦
2- Send Light paramaters through shader directly and suffer a penalty cost via data sharing client/shader.
3- Donâ€™t bother and do as everyone elseâ€¦ forget about it.
Some say that we can store data and functions in texture handler in a shader… I m not sure what is it and how it is done… can anyone help me clear this up?
Hope this is not to heavyâ€¦ thx for reading this!