Horde3D

In the current system models with their joints and meshes are represented as scene graph branches. This is a quite elegant and flexible design since the joints and meshes are not a special case on client side and they can easily be controlled with the common scene graph API. But this elegance and flexibility comes at a relatively high performance price.

Since every joint is a scene node, you can easily get huge scene graphs, especially when rendering many characters. The problem is that scene nodes have no memory locality which results in a lot of cache misses (cache misses are one of the worst performance penalties on modern platforms). All joint updates need to take the generice scene node update path which means recursive calls and invocation of virtual functions. Another serious issue are the dirty flags required for the lazy update mechanism: profiling has shown that a lot of time is spent just for marking all the nodes dirty.

It is not that the current system is unacceptably slow: in fact we can animate several hundred characters. But it is far from the optimum. Since Horde is supposed to be suitable for crowd simluation, it is quite clear that we should try to get the best performance for that. Another point is that Volker plans to port Horde to mobile devices. Their processors are less forgiving than desktop CPUs that are out-of-order CPUs and optimized to hide the latency of cache misses. So I think it is quite clear that we need to do some refactoring.

The idea is to introduce model resources. Model scene nodes will still exist but they just reference a Model resource instead of having child nodes for their data. Since the model resources will solely contain meshes and joints, it is a lot easier to optimize them. I assume that we will be able to get a much better data locaility and less function calls. We will need some more special API functions to control the models (manually setting joint transformations etc.) and lose some flexibility (you can't just add meshes and joints as you could with the scene graph approach) but in the end I don't see a serious disadvantage for practical usage.

Another related change is that the scene graph resources should be moved from the core to the utility library since they will no longer be required for loading models. A scene (level/map/world) definition is something that is quite application specific and usually includes more than graphics data (entities, gameplay data), so it does not make much sense to have a "sample implementation" in the engine core.

I don't disagree with your new approach (it makes sense), but as an alternative you could think about optimising the locality of joint nodes by manually placing their memory inside their parent model node.

I don't think that the current flexibility of joint hierarchy is really needed. Even the modification and reconfiguration of joint hierarchy is a seldom used feature I think. I couldn't think of a situation where non-joint "real inner" nodes are needed. The only thing that could be needed is to attach a node to a joint, like in the knight example.

AFAIK the current collada converter writes model data only, so real scene resources could be only created with hand or a custom editor.


I agree with this, too. While I quite like your editor, we chose to create a game entity centric level editor.

Thanks, that is a good idea. I guess we would find even more tricks but I'm quite sure they will never make things as fast as with the model resource.


This would still be possible. You can attach the object to the model node where the attach function would get an additional subobject parameter.

Any progress on this? I'm really looking forward this change.