Horde3D

[edit]BTW v0.9 is looking great. I can't wait to try out the new animation system![/edit]

Here's a few wishes that I have for horde in the future:

1) Rotations should be able to be supplied to the engine in formats other than Euler angles (i.e. quaternions or 3x3 matrices).

Euler angles are great for humans, like when placing objects in a level editor or something, but they are not good for physics engines.

To be able to properly integrate Horde3D with physics engines we either need:
a) A setNodeTransformMatrix function that takes a 4x4 matrix
OR
b) A setNodeTransform function that takes a quaternion instead of Euler angles


2) I know the engine is unoptimised, and that optimisation will come later, but, I would like to see the light code optimised to use volume meshes instead of full-screen quads. I believe this should be done sooner rather than later because it will require more parameters to be added to the light node, and therefore isn't just an optimisation.

At the moment, each light in Horde3D is rendered over the whole screen, which makes having multiple lights exponentially slower as you increase the screen resolution.
One of the main advantages of deferred lighting is that the speed of rendering a light is proportional to the number of pixels is covers. Obviously Horde3D is currently not making use of this advantage, because full-screen quads cover all pixels.

To take advantage of this, instead of rendering lights as full-screen quads, point lights would be rendered as spheres, and spot-lights would be rendered as cones - this way only the pixels that the light actually shines on will be processed. The only problem with this approach is that you need to determine if the camera is inside a sphere or a cone, and in that case you need to fall back to using a full-screen quad.

Implementing this will mean that 50 tiny spot lights may actually render faster than one full-screen light!

I recommended that a new parameter be added to light nodes - as well as lights having a "shader", "radius", etc... they will also have a "shape".
shape could be set to "fullscreen", "sphere" or "cone".

Also, spot-lights should have an "angle" parameter describing the size of the cone.

The light drawing code can then use the shape, radius and angle to determine if another kind of mesh should be drawn instead of a full-screen quad.


3)Custom variables passed to shaders.
Shaders can currently specify if they need the skinning data, etc... but I would like to be able to pass my own uniform variables to my shaders.

For example, I have an object that I want to fade between its normal colour and a different colour from time to time. To do this I would like to be able to give the shader an "alpha" variable, that I can change from my code.

I think this could be done flexibly, for example each mesh node could maintain an array of custom variables, which could be set through an engine call.
e.g. setMeshParam( node, MeshNodeParam::ShaderVariable, "alpha", 0.5f )

Thanks for your suggestions. I'm always happy about feedback

1) The rotation formats are easy to add. I will probably give the possibility to specify a transformation matrix as you suggested since that is more general than quaternions. If you need that immediately there is a simple workaround: in the utMath.h file is a matrix decomposition function that returns Euler angles in the required rotation order.
BTW, I would be really interested to hear if the physics engine integration works wihtout further problems.

2) Yes that's definately important. I will look what is the best way to implement this, maybe using a scissor rectangle or as you mentioned using volumes. A long time ago I implemented shadow volumes so I still recall the annoying problems with the camera being inside the volume. Another possible optimization are so called social stages where less important lights build a union with more dominant lights.

[EDIT: An angle for the light cone is already available with the FOV parameter.]

3) I am currently thinking about a much more flexible rendering pipeline and more powerful/general material system. User defined uniforms will certainly be a part of that system.