I develop my own game engine for fun (but not profit). I have rendering in one thread and my scene graph updates (velocity, etc.) in another. When it's time to render, the render thread adds the visible nodes to a new linear buffer and traverses them.
In more detail, my scene graph is triple-buffered. Each node in my scene graph has three copies of its relative and absolute transformation matrices (4x4). At any given time, one copy is written to by the scene graph thread, one copy is read by the renderer, and a third exists so that the reader or writer can move on to the next without waiting on the other. This prevents writing to something while it's being rendered and from rendering a half-updated scene graph. Somehow I've also got a fourth copy of each matrix for the user to work with so as to not conflict with the update thread. This seems to perform well by avoiding having to synchronize all the time.
However, this is a mess.
These are my ultimate goals for the system:
- Rendering and scene graph updating stay in separate threads.
- Minimize how much these threads have to wait on one another.
- Don't render a scene that's been halfway updated by the update thread. This is particularly noticeable if the camera is moving fast and sometimes it's rendered before or after an update.
- Reduced memory usage. I have way too many matrices per Node. I'm also considering moving to vectors for position/rotation/scale due to increased floating point drift with matrices.
- Ability to handle tens of thousands of Nodes. The current system does this reasonably well.
I also hope to incorporate Bullet (the physics engine) and networking in the future, neither of which I've given much thought.
What are some approaches for accomplishing a better scene graph?
