We added a line which prints the type and name of the SceneManager. In this case, the scene manager's name is ExampleSMInstance, which is a straightforward name for a scene manger used in the example application. SM stands for Scene Manager, if you haven't guessed it. The more interesting part is the type, which in this case is OctreeSceneManager. Before we go into detail on what an OctreeSceneManager is, let's discuss what a scene manager in general does for Ogre 3D.

A scene manager does a lot of things, which will be obvious when we take a look at the documentation. There are lots of functions which start with create, destroy, get, set, and has. We already used some of these functions, like createEntity(), createLight(), or getRootSceneNode(). One important task the scene manager fulfills is the management of objects. This can be scene nodes, entities, lights, or a lot of other object types that Ogre 3D has. The scene manager acts as a factory for these objects and also destroys them. Ogre 3D works with the principle he who creates an object, also destroys it. Every time we want an entity or scene node deleted, we must use the scene manager; otherwise, Ogre 3D might try to free the same memory later, which might result in an ugly application crash.

Besides object management, it manages a scene, like its name suggests. This can include optimizing the scene and calculating positions of each object in the scene for rendering. It also implements efficient culling algorithms. Each time we move a scene node, it gets flagged as moved. When the scene is rendered, only the position of nodes that have been moved and all their children are calculated. For the rest, we use the positions from the last frame. This saves a lot of computation time and is an important task of the scene manager.

For culling purposes, we need a quick way to discard all nodes that aren't visible from the camera we are using for rendering. This means we need an easy way to traverse the scene graph and test the nodes visibility. There are different algorithms for this and Ogre 3D comes with a different scene manager that implements different algorithms, each specialized for different scene types.

The scene manager we used all the time was the OctreeSceneManager. This scene manager uses an Octree for storing the scene, thus the name. So what exactly is an Octree?

As the name suggests, an Octree is a kind of tree. Just like every tree, it has a root and each node has a parent. What makes it special is that each node has a maximum of eight children, hence the name Octree. The following is a diagram showing an Octree:

Source: http://commons.wikimedia.org/wiki/File:Octree2.svg

So why does Ogre 3D use an Octree for storing 3D scenes? An Octree has some properties that are extremely useful for storing 3D scenes. One of them is the fact that it can have up to eight children. For example, if we have a 3D scene with two objects in it, we can enclose this scene with a cube.

If we divide this cube at half of its width, height, and depth, we get eight new cubes, each enclosing an eighth of the scene. These eight cubes can be thought of as the eight children of the original cube.

Now the two objects of the scene are in the right upper-front cube. The seven other cubes are empty and are therefore leaves. We will divide the cube that contains the two objects again.

Now each cube has either one or no object enclosed and is a leaf. This property of an Octree makes culling easy and fast. While rendering a scene, we have a camera with its view frustum inside the scene. To determine which objects have to be rendered, we start with the root node of the Octree. If the view frustum intersects the cube, we continue. This should always be the case, because the Octree on level 0 encloses the complete scene with the camera. We then continue with level one of the Octree, meaning the root node's children. We test the view frustum against each child, and if they intersect, we continue with the children of this cube. Also, if the cube is completely inside the frustum, we don't need to go any deeper because we know all children of the cube are in the frustum as well. We do this till we have reached a leaf, and then continue with the next child till we only have leaves left.

With this algorithm, we discard most of a scene with each step, and after only a few steps, we will have either empty leaves or a leaf with an object. We then know which objects are visible and can render them. The beauty of this algorithm is that we can discard a lot of the scene in the first few steps. If, in our example, our complete view frustum would be in the same level 1 cube as the two objects, we could discard seven-eighths of the scene with the first step.

This approach is similar to a binary search tree. The only difference is that it uses eight children instead of two.