Does one provide for each supported BRDF, a separate shader for each type of light sources (i.e. directional, point, lightmap, etc.)? Or is it somehow possible to use a single shader for all types of light sources?

Why not loop through a list of point lights first, then a list of spot lights, then... All from one shader?

Why not loop through a list of point lights first, then a list of spot lights, then... All from one shader?

That would work of course. From a software design point of view, it seems very bad design. In general, I have the feeling that if one wants to support a new type of light for instance, changes to the code are far from local and affect huge parts of the CPU and GPU codebase?

In general, I have the feeling that if one wants to support a new type of light for instance, changes to the code are far from local and affect huge parts of the CPU and GPU codebase?

I don't know what you mean. Adding a new light type would be pretty modular in my eyes. Besides rendering geometry over again with a different shader would be expensive (slow). Besides you'd want to keep all lights of the same type in an array/structuredbuffer anyway so why not just loop through it?

Besides you'd want to keep all lights of the same type in an array/structuredbuffer anyway so why not just loop through it?

True

But if rendering was cheap, I want to have inheritance to encapsulate all of this. Now I need to add some container support for every type of light in my world representation, at the shader binding site and in the shader itself.

if you search online, you'll find shaders that implement the entire fixed function lighting system. as i recall, they use lists of lights. i may have a link handy...

well, i have 40 links handy! <g> i've been learning shader code recently.

let me see if i can find it...

found it

http://www2.ati.com/misc/samples/dx9/FixedFuncShader.pdf

if you search online, you'll find shaders that implement the entire fixed function lighting system. as i recall, they use lists of lights. i may have a link handy...

well, i have 40 links handy! <g> i've been learning shader code recently.

let me see if i can find it...

found it

http://www2.ati.com/misc/samples/dx9/FixedFuncShader.pdf

Thanks, will take a look at it

But if rendering was cheap

What? please complete your thought.

Besides how were you planning on accomplishing this before?

But if rendering was cheap

What? please complete your thought.

Besides how were you planning on accomplishing this before?

If rendering was cheap, I used ray tracing :D. I said that I want inheritance to encapsulate everything. But since HLSL is more looking like procedurally C than OO C++, this is not going to work. Unless one goes one level up and uses CUDA. And then we could even skip the pipeline all together and go ray tracing. In a ray tracer you could provide these clean interfaces: if you want to add a new light, you only need to implement a new interface. In a rasterizer, you would need support everywhere. That is my concern.

Originally, I would provide for every effect and every light type one separate shader which all involve one light source and a separate shader for ambient (to avoid multiple contributions) and combine all of them additively.

for every model: for every model part: for every light type: for every light: bind and draw

But this is going to be really expensive and I definitively don't like the "for every light type" part.

Unless one goes one level up and uses CUDA. And then we could even skip the pipeline all together and go ray tracing.

Raytracing is still relatively slow on GPU's, although PowerVR came out with a mobile chip with a raytracing accelerator to speed up ray-traced shadows and reflections.

for every model: for every model part: for every light type: for every light: bind and draw

That would be incredibly slow...

edit- it would be slow if you use a different shader per light type.

(to avoid multiple contributions)

Why are you trying to avoid multiple contributions?