Horde3D

What is the threading model of Horde? Suppose I have a game with a render thread using horde and a separate game logic thread. What happens if the game logic thread tries to update the scene graph while the render thread is reading from the scene graph to make opengl calls to render? Does Horde support this and if so how does it implement it?

Horde is not thread safe.

Hi chare,

Perhaps a possible approach if you don't plan on doing callbacks or things from the Horde scene graph and you manage all transform-related interactions in your game logic thread, you could perhaps double-buffer all your transforms into a list, then wrap that list into a mutex lock and feed Horde's scene graph on the Horde thread. Reading back transforms from Horde itself might be tricky then without additional expensive mutex locks, so best to manage that stuff in the game-logic thread only (and probably the smart approach if you do things in future like a client/server-separated game and you want the server headless and not relying on an OpenGL-interacting library, depends on your engine).

There is a plan to remove the scene graph in future so Horde is purely submission-based rendering, which might mean more threading options as well (but you'd be responsible for your own scene representation).

_________________
-Alex
Website

This is kind of what I'm planning. I'm using my Go implementation, and Go has some nice concurrency primatives. I plan on queuing up all of transformations ( or probably easier all of my calls into the horde3d api) from different threads, and just apply them on one thread when all of my Go channels return.

So all of my horde3d interfactions will be single threaded, but everything else will be multi-threaded. So I could be calculating my A* path for my AI in one thread, and the Bullet physics call in another thread, and when they complete both transformations will be applied in order to the horde3d API call.

That's the idea at least. We'll see.