Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer

Have you read Johannes Spohr's thesis on "Pace" and its renderer? It describes a so-called "submission engine"* parallel renderer, and may give you some ideas.

Here is the summary page (in German), and here is a direct link to the PDF which is in English.

(*: this link also goes to the article where I originally heard about the thesis.)

EDIT: I'd only skimmed this previously, and I just looked at it again... and realized it really glosses over scene graph details. I guess I didn't realize how orthogonal his design was. Sorry if it's not particularly helpful.

share|improve this answer
1  
One piece of this paper still stuck out to me: "Ideally, the application would not even know there is a scene graph at all, it should only be aware of a view component it has to inform of changes to the data model". This inspired in me a new way of thinking about it: I don't need to triple buffer the entire scene, only what's visible through the current camera. I can move culling from the render thread to the scene graph thread (when it encounters a camera), and at any given time, one of these three buffers can be written to by it, and another read by the renderer. –  JoeCoder Sep 23 '10 at 20:48
1  
You might also check out the article "Camera-Centric Engine Design for Multithreaded Rendering" in Game Engine Gems 1, and the related "Practical Parallel Rendering with DirectX 9 and DirectX 10" - microsoft.com/downloads/en/… –  Neverender Sep 24 '10 at 1:14
1  
Looks like Game Engine Gems 1 is available free online: books.google.com/… –  JoeCoder Sep 24 '10 at 1:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.