Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
109 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

Introduction

A graphics engine is not complete without some sort of way to manage its data.  For some engine's needs a simple list of objects in the world with frustum culling is enough.  But for modern game engines this will just not suffice in most cases.   This is why a scene graph is needed.  Through this article I will explain the theory behind a scene graph then dig deep into the workings of this device.  Although this technique can be used in any language you like, I chose to write this article with C++; because I like C++.   Even though there is not much code in this article I'd still suggest that you have a firm knowledge of C++ including inheritance, virtual functions, and on the theory side of things have a basic knowledge of trees.

What is a Scene Graph?

The most popular question I get while explaining what a scene graph is - is: what is a scene graph?  Well a scene graph is a way of ordering your data into a hierarchy where parent nodes affect child nodes. You might be saying "isn't that what a tree is?" and you're exactly right; a scene graph is an n-tree.  Meaning it can have as many children as it wants. But scene graphs are a little bit more involved than a simple tree.  They represent some action to take place before proceeding to the children objects.  If this doesn't make sense now then don't worry it will all be explained in due time.

How is a Scene Graph Useful?

Well if you've yet to discover why scene graphs are so cool then let me explain some of the finer sides of the scene graph. Let's say you have to model a solar system in your game.  This system has a star in the middle, with two satellite bodies (planets).   And each of the planets also has two moons.  There are two ways to solve this.  We can create a complex behavior function for each body in our solar system, but if the designer wants to change a planet position then there is a lot of work to do by changing all the other objects that should be rotating around it.  The other choice would be to create a scene graph and make our lives simple.  The following diagram shows how we would create a scene graph to represent the objects:

Now the code becomes trivial.  Let's assume that the rotation node saves the current world matrix, and multiplies it with a rotation.  That would affect all other objects rendered after it.  So with this scene graph let's see the logical flow of this scene graph would be.

  • Draw the star
  • Save the current matrix
    • Apply a rotation
    • Draw Planet One
    • Save the current matrix
      • Apply a second rotation
      • Draw Moon A
      • Draw Moon B
    • Reset the matrix we saved
    • Draw Planet two
    • Save the current matrix
      • Apply a rotation
      • Draw Moon C
      • Draw Moon D
    • Reset the matrix we saved
  • Reset the matrix we saved

Now this is a very simple example of a scene graph, and you should start seeing why a scene graph is a good thing to have.  But you might be saying to yourself that this is very easy to do, I'll just hard code it. The beauty about scene graphs is they're not hard coded, specific things such as rotations, rendering, and any type of node you can think of are, but the way the scene is displayed is not.  With our new found knowledge we can make this scene a lot more complex, so let's do it!  Let's add some life into our solar system and make Planet 1 wobble a little.  Yes planet 1 was hit by a large asteroid and is now rotating slightly off its axis.  No need to worry all we need to do is create a wobble node and set it before we draw Planet 1.

But planet 1 wobbling is just not enough realism for me, let's go further with this and make the two planets rotate at different speeds.

Now this scene graph is a lot more complex than what was originally presented, so let's go over the logical flow of the program now.

  • Draw the Star
  • Save the current matrix
    • Apply a rotation
      • Save the current matrix
        • Apply a wobble
        • Draw Planet 1
          • Save the current matrix
            • Apply a rotation
              • Draw Moon A
              • Draw Moon B
          • Reset the Matrix
      • Reset the matrix
    • Reset the matrix
  • Reset the matrix
  • Save the current matrix
    • Apply a rotation
      • Draw Planet 2
      • Save the current matrix
        • Apply a rotation
        • Draw Moon C
        • Draw Moon D
      • Reset the current matrix
    • Reset the current matrix
  • Reset the current matrix

Wow! Now that is to model just a simple solar system!  Just imagine what would happen if we modeled the rest of the level.





Implementing

Contents
  Understanding
  Implementing

  Printable version
  Discuss this article