12
\$\begingroup\$

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?

\$\endgroup\$

1 Answer 1

4
\$\begingroup\$

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.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – EricP
    Sep 23, 2010 at 20:48
  • 1
    \$\begingroup\$ 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/… \$\endgroup\$
    – Zach
    Sep 24, 2010 at 1:14
  • 1
    \$\begingroup\$ Looks like Game Engine Gems 1 is available free online: books.google.com/… \$\endgroup\$
    – EricP
    Sep 24, 2010 at 1:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .