Horde3D

I'm not yet happy with the way ambient lighting is done at the moment, especially when you want to apply more complex methods like using ambient cube maps.

Currently the standard way is making a DrawGeometry pipeline call with a special context, e.g. "AMBIENT". The problem is that the materials of each object need to include the ambient cube map. This makes it hard to change the lighting by replacing the cubemap since all the materials would have to be updated.

One idea to solve this is using a light source as ambient light. The light source could have a material which defines the ambient cube map and just gets a fov of 360 degrees and a very large radius. This could work in some cases.

It would work when you have some sort of early z pass in the pipeline that writes to the depth buffer. So the ambient light is simply additive and treated as all other light sources. But if you don't want to use this z pass you have a problem. The ambient light should not use any blending (since the framebuffer is still empty). You can specify the blend mode in the shader but the problem is that it is not guaranteed that the ambient light source is drawn before other light sources which could lead to wrong results.

My proposal to solve this dilemma is to add a new flag "DrawFirst" to the light nodes. Lights with this flag are rendered before any other lights and consequently the first render pass is not an additive one.

If anyone has a better idea or any comments please post them!

It would be nice to have the option to skip the ambient pass if it's not needed. Perhaps this could be generalized to a similar system to the geometry "classes"? Each light can have a class assigned, and then <DoForwardLightLoop> can specify class(es) of lights to include, as well as geometry.

Another option would be to add texture references which can be linked at load time or even changed dynamically by the program. A set of shaders could refer to the "AmbientCubeMap" which can be set as a renderer/pipeline parameter. I think this could be a very useful feature in the long term.

This is a great idea! Actually it is already possible for textures. You can use a generic name for the map and create a resource for it in the app code. The only thing needed on application/UtilLib side is a mapping from the generic name to a real filename.

To extend the idea I think it would be useful if a material could link to another material. The linked material could overwrite or define additional texture stages and maybe also uniforms. No special functions would be necessary for such a system since everything works with the material resource API functions.




This is also good. Would make it possible to implement some level of detail in the pipeline. A reflection texture for example could omit smaller light sources for better performance.