Why I Don't Need a Scene Graph

(And Why You Might Not Either)

A couple of months ago I completed the switch from OGRE to BGFX as Blackshift's
rendering library. While OGRE is a full-featured graphics engine, BGFX is more
of a thin layer over OpenGL and DirectX. So why the switch?

Well, it really comes down to scene graphs.

When you use a general-purpose engine — and here I include full game engines
like Unity as well as graphics-only engines like OGRE — you're usually required
to encode your scene as a “Scene Graph” — a tree-like data structure which
describes each object's position, orientation, 3D model, etc.

Each node is transformed relative to its parent

Scene graphs are versatile, and are used in 3D tools as well as in game engines. There's basically no scene you can't describe with a scene graph.

But you pay for that.

Because the scene graph is such a general structure, it won't be optimized for your particular game. And Blackshift is a very particular sort of game.

When Blackshift was using OGRE, the naive approach was to create one scene node for each game object, including all floor tiles, wall segments, blocks, items, enemies, etc.

This was a performance nightmare, so I ended up having to merge all “static” objects into 16x16 “chunks”, with a mesh for each chunk of walls. But, nothing is really static in Blackshift, because most tiles can change and get blown up, and even the walls need to change quickly in the editor. So the chunks needed to be recomputed all the time. And, because each chunk needed its own unique mesh, instancing was out the window.

Scene graph in Unity

Adding to that, scene-nodes needed to be updated when their associated game objects moved, or performed any action needing an animation, leading to a complex system of events and messages to keep everything updated.

Finally it got to the point where I noticed I was expending a ton of effort just to keep OGRE's scene graph happy, and I wasn't even reaping any of the benefits of using one:

• Scene graphs help with culling complex scenes, but Blackshift has a fixed camera position and all objects are on a grid, so culling is incredibly easy.

• Scene graphs work well when each scene-node “is” its object, but Blackshift follows a MVC design where the game logic runs totally separately from the renderer. This means extra overhead was required to keep the scene-nodes in sync with the game objects.

Blackshift's new renderer is much faster and much easier to work with. The main render loop now looks something like this:

To render a frame:
  For every grid cell within the view-range of the camera:
    For every object in that cell:
      Draw that object

To decide how to draw an object, every object type has a “graphic”, which is a compiled native-code routine that sends the appropriate draw commands to BGFX. This is super-fast. At runtime, all commands to draw that kind of object are in a pre-optimized routine that's just a pointer lookup away.

Drawing a given object is a simple matter of

object->type->graphic();

The animation code is mostly stateless. For example, the moving parts of the customs door (the one that closes when you have an item) are simply drawn with an orientation which is a function of the time since you last picked up or dropped an item. This is orders of magnitude faster than updating a scene node every frame for every moving part of the door (which would then trigger cascading bounding box updates, all to be thrown away when the culler can't make use of the BBs.)

If a scene-graph is declarative in style, Blackshift's new renderer is less so. The renderer no longer knows or remembers object positions. It simply reaches into the game's own state each frame and fires off rendering commands to BGFX.

I was amazed how much faster this is. For example, the “morpher”, the bit of code that decides which wall shape to draw for a certain wall tile by looking at its neighbours, doesn't even need to be precomputed. It simply runs every frame for every tile on screen, and it doesn't even register in the performance graph. This is something that took a lot of effort to implement efficiently before.

So, advice to my fellow game devs:

When thinking about how to implement your renderer, think about a typical scene from your game and what API calls you'd make to render it. Then, if you can, design a renderer that does that and nothing more.

I've written all these words but all I'm really doing is restating the First Law of Optimization:

To make your code run fast, have the computer do as little as possible.