Horde3D

I looked at the documentation and in the forum but did not found a way to create an update callback when doing the update traverse of the scenegraph ( SceneNode::update() ).

Are you planning for future versions to add this mechanism or a similar one ?

Thanks!

_________________
r3D^rgba

Does the h3dCheckNodeTransFlag help you? Or what exactly are you planing to do?

I meant a callback mechanism similar to the one Openscenegraph has.
I think callbacks provide an interface easier than changing things directly in a main update loop

I saw SceneNode has an onPostUpdate and onPreUpdate. Wouldn't be nice to have access to those without having to inherit?

Thanks!

_________________
r3D^rgba

I think the reason for not offering callback methods is that it is less portable to other languages than C/C++. On the other side, one could just ignore this functionality on language bindings that do not support function pointers. But I guess that's something marciano has to decide. In principal I agree, that callbacks could become handy in some cases (especially in case of physics).
But marciano told me a couple of times, that he wish to outsource the scenegraph from Horde3d anyway (although I haven't fully understood yet how the animation system then should work without making it far more complicated).

With Horde exporting a C API, we wouldn't be able to offer support for C++ functors, which rules out using member functions as callbacks - pretty much essential for this sort of functionality.
It works in principle, but once you move to a more robust architecture (i.e. independent time-steps for physics and rendering), your callbacks need to carry around a lot of state, and the advantages of callbacks pretty much go down the drain.

_________________
Tristam MacDonald - [swiftcoding]

As long as the call-backs take a user-supplied void* you can always implement C++ pointer-to-member callbacks yourself, though


@r3d - what would you like to use these hypothetical update callbacks for?

For example to allow a client - that doesn't have access to the update loop - to implement a custom animation controller ( like a lookat) or a custom deformation.

_________________
r3D^rgba

You can implement this sort of callbacks from your own main loop - no need for the scene graph to provide this.

_________________
Tristam MacDonald - [swiftcoding]

I was gonna say, I would think that an update callback would be implimented based on what is needed. IE: if entity is moving forward, then play walk animation. Other instances would include blending between strafing and walking based on what direction the player is heading and what direction he's facing. That's all in the entities hands with the type of API Horde provides.

I'd really recommend steering clear of the "callback" concept for the scenegraph.

Ogre has listeners which are essentially callback mechanisms. It also has classes you can derive from where you get certain member calls at certain times during the render setup.

The problem is that in a game, you really dont want your rendering to be "in charge" of anything. Rendering should be "throw some data at the card and forget it". Implementing things like update loops via a renderer callback can lead to all sorts of isssues (which is why I encourage my students to use Ogre's "RenderOneFrame" method to do the rendering when THEY want it to render.

In general, its usually physics that is "in charge" of things, mainly because then your AI can handle updates after the physics simulation has been run. In my past games, we've had the ability to literally switch off rendering entirely (and its something I still do in my own engine) so that we can test game logic and AI etc without having the renderer draw anything, we add the ability to speed up time and run the whole simulation at a faster rate looking for bugs.

zoombapup, these are good points. I'm a big fan, of layering, pipelining and especially orthogonality, so I see that similar to you. Also, callbacks do not work well with asynchronous (multi-threaded) game loops.