Lighting shader design question

[Seven]

Sorry for the noobiness of the questions, but we all started somewhere........

I started with a shader that simply passes through the pixel in question. I then added material attributes and can modify the UV coordinates, and then I added a single light using shader variables called ambient, diffuse, etc... which get passed to the shader in the setconstants() function. I would now like to add multiple lights to the rendering but do not know the design philosophy for this.

1) When using shaders, do I need to add light calculations to each individual shader or do I create a single light shader and pass the results of the individual shaders to that? I have added a dynamic light to the terrain shader for example, but am hard coding a single light.
2) How would I go about being able to pass a variable number of lights to the shader or should I pass the terrain (after shader determines pixel colors) to a different shader that only does lighting?
2) Also, do I cull lights (the distance calculation from the pixel to the light(s)) in the shader, or do I calculate the distance in c++ and pass only valid lights to the shader? ( my thought here is that some lights will not be within range of the pixel and therefor the lighting should not be added to it) This question goes in part with the first question.

any help or ideas is appreciated. I cannot create the next generation game engine on my own lol!

[Seven]

16 views so far. Hoping for an answer. I don't need code, just a philosophy. So far I have 3 lights being passed to the shader working fine, (ILightSceneNodes) but it seems odd to have to pass all lights to every shader. Is it better to defer the lights until last?

[Mel]

Shaders need a fixed amount of resources, so, if your shader renders n lights, you provide it n lights in a single pass. It is posible to create multiple pass pipelines, but at the cost of rendering the stuff twice, duplicating the drawcalls and we really don't want that.

In fact, the simplest approach for a variable amount of lights is a deferred renderer. It is incredible how simple the shaders become, for the results they provide. Give it a shot

[Mikhail9]

It's too bad you didn't get more answers to this. I was hoping for some Irrlicht-centric insight.

Mel's answer helps, of course, and I took the opportunity to learn more about deferred rendering, so that's good. How to make that work with the Irrlicht rendering pipeline isn't so obvious to me, but I'm guessing you use more than one scene manager and take advantage of the fact that the lightmanager isn't really a lightmanager and use it to make sure you draw things at the right times.

However, some small description of how you might take a shader that can compute n lights and use it in an Irrlicht scene with many more lights would be welcome. I'm guessing the lighting manager helps you with this, so you can enable/disable lights before rendering each node, passing just the 6 closest to the shader. Does that have performance implications?

Or I could be wrong... that's why I was hoping for more answers. Where are our other experts this week?

And thanks again for the pointer to deferred rendering, Mel.

[hendu]

You really don't want to do normal forward rendering with a big amount of lights. It's O(n*m).

[Mel]

Believe me, even a shader with 2 lights and shadowmapping and normals is huge (158 instructions Pixel shader 3 level) compared to a deferred rendering approach (26 instructions, Pixel Shader 2 level).

When the people at crytek designed the engine for crysis they faced the same problem, a variable amount of lights require an approach that can provide you any amount of lights AND that the problem keeps being simple. The solution? deferred rendering. It not only allows you to solve the problem of lighting, but also enables you to create almost all the effects that currently you can see in now a days graphics.

[Seven]

my latest investigation has led me to XEffects. As I study the code that it provides, I get more and more understanding. At the moment, I have my system setup to create different scene nodes based upon the detail level selected by the user. Example, the generic terrain scenenode for low end, a 3 texture splattering shader for medium level and the recently shown triplaner shader for high end. I then select the proper lighting / shadow modes the same way, using lightscenenode for lower end, lightscenenode and shadows for medium level and deferred lighting with shadows (XEffects style) for high detail level. Setting this up was fairly easy and I added a small function to the base object class to handle runtime reloading based on it.

I don't know if this is the proper way of doing this, but it seems to work and I always follow the old adage that whatever works is the best way to do it

Since the lighting calculations are obviously time intensive, I will next add a lighting manager to enable only the lights that are visible. Once complete, I will post my code for others to look at. Hopefully we can get a good methodology for all of this.