[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 )
|
