Horde3D

Over the last time I did some restructuring and refactorizing of the light code in the community repository. I moved all the light code (well, not all yet, still some work to do*) out of Renderer and into the Light class. Light is now an abstract base class for the different light types like SpotLight and PointLight, other light types can now be more easily created via plugins.

I also implemented a simple PointLightNode using a simple depth cube map.

Anybody can test these things, review them and tell me whether this would work and is acceptable to go into trunk one day?
URL (SVN): http://mm-werkstatt.informatik.uni-augs ... xperiments

* What is left is basically the debug rendering which also has to be done by the light classes itselves

Hey Phoenix, I had a few minutes to look at your changes.

From what I could see you have two major new features: point light shadow maps and occlusion culling for lights. This is awesome and I'm sure it can be very useful for some projects. But I don't see the advantage of your restructuring yet. With the Point- and SpotLight classes you have a fair amount of code duplication now. Of course it is not so bad since it is not hundreds of extra lines but nevertheless it is a bit against the minimalism and unification/generalisation philosophy of Horde. Another thing is the relocation of the rendering code to the light nodes. I was also thinking of that some time ago but found it a better idea to keep all rendering code at a single location. This requires more abstraction but I think that way it is much easier to write a different rendering backend (e.g. D3D) since you just need to replace the Renderer class. So I really like your new features but personally I would rather try to integrate them to the current structure if that is possible in a clean way (I think so).

The current structure from what I see has some disadvantages:

- Imho it is quite a bit unflexible, adding more lights always involves putting more and more code into Renderer which gets much more complex than needed. It's impossible to "generalize" lights as each one has a different way of rendering the shadow maps.

- With one or two more changes, lights can be realized as extensions now. This is again impossible with the current solution, just because all the code is in Renderer.

If you really want that abstraction layer for different backends, imho one should implement the lights themselves twice, once for OpenGL, once for Direct3D. This does not have to happen in the Spot/PointLightNode class but can also happen in another class which sits behind these, like SpotLightRenderer which then contains the minimal amount of code necessary to draw the light, or alternatively classes like OGLSpotLightNode or D3DSpotLightNode.


And about code duplication: You are right, there is still quite some code which is duplicated, but that code is really valid for all lights and can be put into the LightNode class with all nodes being able to access it.

I'll think about whether it's possible to integrate the lights into Renderer, but I really think it's ugly.

EDIT: I found a way how to integrate all into the Renderer class I think. Still it's ugly as hell to stuff all into that class imho. Btw, how will you handle extensions when writing a different renderer backend? The terrain uses 100% direct OpenGL calls.

Your arguments are right. There is no perfect solution, as usual all have their pros and cons.

Another argument for keeping the code in the Renderer is support for different shadowing techniques, e.g. shadow maps and stencil volumes (although this will quite certainly not happen). I think the light nodes should give a requirements specification and the Renderer should take care of fulfilling it with an appropriate technique. I don't think that this is ugly. I also think that it is to some degree possible to generalize the shadowing. For example point light shadows can also be realized with unwrapped cube maps which would be quite similar to the texture atlas used for the cascaded shadow maps. The current solution for point lights is to to have six spot lights. This is also a valid solution that is used in several high-profile engines, especially in combination with deferred shading (see http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html). But this six spots solution could still be optimized a lot in Horde.