Final Thoughts on Scene Grap

Final Thoughts on Scene Graphs

Scene graphs are meant to be fairly automatic. After the graph is created and any other render parameters are set, the graph and renderer should update and render on its own. But that doesn’t mean it will do anything interesting! User-defined behaviors and game logic are just as important as ever to make this automatic rendering system into a game. Hooking into and controlling the graph is the main way game logic makes a scene graph into an actual game.

Updates and Interaction

Because scene graphs can get fairly large in terms of nodes in the graph, traversing and searching in the graph for every game update frame is prohibitively expensive. What most games do is build their scene graphs at startup and also build a secondary layer to the graphs that enables easier and direct manipulation of scene graph nodes from outside of the graphs themselves. Often this secondary layer is more of what the game developer thinks of as the game engine. It is the data structures that are relevant to the actual game design, with objects that make sense in the game. For example, in a race game, the game design may wish to have a Car class that contains all the data and methods a player’s car needs in the game, including a reference to the car’s 3D model.

Creating this game-oriented access layer can be done in many ways, and sometimes is even embedded in derived-scene graph nodes. Only the specific game’s needs can determine the best design for this, and often this mapping of game-level objects to the scene graph representation can be quite challenging.

Content Loaders

The value of content loaders for a scene graph and even simpler geometry hierarchy renderers cannot be underestimated. A scene graph’s ability to import specific content formats has been known to be the deciding factor for choosing one graph over another. This is one of the more tedious parts of building a custom scene graph system because marrying a scene graph’s tree structures with file IO can be error prone. In addition to getting data loaded and mapped to scene graph nodes correctly, often the loader must do additional processing to optimize the scene graph it outputs because the data format it is loading is rarely in a runtime-optimized organization.

The subject of content loaders also leads to content creation, that is, creating the content that will be loaded into a scene graph. Content creation is the realm of the 3D artist and beyond this text but incredibly important nonetheless. Without the initial content, loaders have no meaning. Because of this, developers and artists have to work hand-in-hand to complete the 3D content production pipeline for quality 3D games.

Scene Graphs and Games

As was stated earlier, scene graphs are high-level graphics tools that hide the procedural realities of the low-level graphics API such as OpenGL. Because full-featured scene graphs such as those used in the simulation industry and VR are usually concerned with data management and not graphical special effects, sometimes they are not suitable for certain games. The problem is that this high-level layer often makes it difficult (or impossible) to create low-level graphics special effects that are possible and desired in games. What is desirable is a well-defined retained-mode renderer that has several of the useful features of scene graphs, such as a geometry hierarchy with inherit transforms, bounds support, and view culling, but that doesn’t hide the underlying rendering process or exclude direct access. The following example attempts to satisfy this, although it is incomplete in terms of supporting the numerous possible geometric and rendering state data possible in OpenGL. Instead, it focuses on the immediately useful and practical, while being ready for extension through a number of programming options.

Scene graphs are often intended to heavily abstract away the complex and particular details of the underlying rendering software and hardware. Depending on the actual game requirements, a scene management system that is meant to give more object-oriented organization to rendering and not obstructing its fundamental functional nature, is optimal. It is a difficult balance to create a rendering system that is a higher level than OpenGL and generally enabling, but that isn’t overly restrictive at the same time. One way to stay on course is to always choose the most straightforward technique or method when committing to a solution for a significant issue. When using or developing scene graphs, remember the mantra: Keep It Simple, Stupid (K.I.S.S)!