Horde3D

@philippec:
It is only now that I noticed and checked your second patch (with the renderable children). It's quite clever what you are doing there. We would definitely integrate your patch but since the system is probably about to change (spatial graph) the problem has to be solved in a different way. Anyway, thanks a lot for your efforts! Also thanks for the idea with the animation updates. I think the cleanest solution would be to expose an API function which checks if an object is visible (or was visible in the previous frame) so that the user can just not call the animation update functions.


Honestly, I hope you will still have some time to contribute ideas since they seem to be quite good

For everyone who is GPU-limited and wants to do some scene graph profiling (e.g. in Chicago): Comment out the glDrawRangeElements in Renderer::drawModels. This will stop the GPU from drawing the mesh polygons. Please note that this trick is not appropriate if you want to profile the GPU state changes of Horde since the actual hardware/driver state changes happen usually when a drawing function is called.

In 2-3 weeks, I should be solidly CPU bound! Just budgeting for an Athalon X2 desktop with a Radeon 4830 HD

_________________
Tristam MacDonald - [swiftcoding]

We have a new function checkNodeVisibility which returns if a node is visible (or its computed LOD level if requested). This seems to work all fine and I tried to optimize the Chicago sample to only update model animations if a character is visible.

Unfortunately the performance was worse compared to simply animating all characters. I found the reason for this quite quickly. A character is moved, after that the checkNodeVisibility function is called. Since the character model is dirty, a scene node update needs to be done which transforms the model and all its children (the skeleton). If the character is visible, the animation is applied and a second scene node update needs to be done. This second scene node update is slower than just applying the animation. Since there is just a single animation in Chicgao, the engine uses the fast animation path. I guess the results would be better for more complex animations, where the time spent for animation is higher than the time required for the scene graph update.

This phenomenon is a general problem of the scene graph (I would say of scene graphs in general, not just ours). The question is if it can be overcome in some non-hackish way. We would need a way to determine if a scene branch update is really required. I did not yet do any deeper reflection about that issue but if anyone has a clever idea it would be very helpful.