History: SceneManagersFAQ

Source of version: 42 (current)

{DIV(class="Layout_box1")}{SPLIT(colsize=15%|86%)}{img fileId="1616" alt="scenemanager.jpg" width="87" imalign="left" link="SceneManagersFAQ"}---
__((SceneManagersFAQ|SceneManagers FAQ))__
Overview of the various SceneManagers available for Ogre.{SPLIT}{DIV}
{maketoc}



!Introduction
A ''((-scene|scene))'' is an abstract representation of what is shown in a virtual world. Scenes may consist of ''static geometry'' such as terrain or building interiors, ''models'' such as trees, chairs or monsters, ''((-light|light)) sources'' that illuminate the scene and ''((-camera|cameras))'' that view the scene.

Scenes can have quite different types. An interior scene might be made up of hallways and rooms populated by furniture and artwork on the walls. An exterior scene might consist of a terrain of rolling hills, trees, grass waving in the breeze and a blue sky with gently moving clouds.

Ogre provides a set of different scene managers, each of which is customized to best support different kinds of scenes. Ogre experts may even wish to develop their own scene manager, customized to best the type of scene used in their application.

This document lists the various scene managers provided by Ogre and discusses their strengths and weaknesses.


!Selecting a Scene Manager
You can select a scene manager via the ''createSceneManager()'' method defined in your root node, replacing ''ST_GENERIC'' with your scene manager of choice:

{CODE(wrap="1", colors="c++")}mRoot->createSceneManager(ST_GENERIC);
{CODE}
The argument to ''createSceneManager'' specifies the type of scene manager to use, based on the following values:
* ST_GENERIC - Generic scene manager {TAG(tag="sub")}(Octree if you load Plugin_OctreeSceneManager, ((DotScene)) if you load Plugin_DotSceneManager){TAG}
* ST_EXTERIOR_CLOSE - ((Terrain Scene Manager|old Terrain Scene Manager))
* ST_EXTERIOR_FAR - Nature scene manager {TAG(tag="sub")}(this mode is not present anymore in Ogre 1.0. Use "Terrain", or "Paging Landscape" instead){TAG}
* ST_EXTERIOR_REAL_FAR - ((Paging Scene Manager)) 
* ST_INTERIOR - BSP scene manager

Each SceneManager can register any combination of those flags for itself, since they are simple bit masks. So the default manager registers itself as ''ST_GENERIC'', the octree manager and PCZ manager register themselves as all types, the BSP manager registers itself as ''ST_INTERIOR''.

When you request a scene manager by type instead of name, Ogre picks the last manager to register a matching type.
The order depends on the order you load plugins in the ''plugins.cfg'' file. If you load the BSP, PCZ and Octree managers in that order, the Octree manager will grab all scene requests (when requested by type).

That's is also the order in the default Ogre plugins.cfg, so most people are probably using the octree manager if they use the type flags (even if they request ''ST_INTERIOR'' and have the BSP manager loaded, if the BSP plugin is loaded before the Octree plugin!).

Instead of requesting a scene manager via type, you can also do it via the name. The text names to find the scene managers explicitly are (case sensitive): 
* DefaultSceneManager  
* OctreeSceneManager
* BspSceneManager
* PCZSceneManager 

Only those above listed four are official Ogre scene managers in the sense of being provided by the Ogre team. However, there are quite some community developed alternatives which are partially listed on this page as well. The ((Ogre Terrain System)) is also developed by the Ogre team and is the new standard approach for terrain rending. It is however not technically an own scene manager, but rather a scene manager independent component.


!!Generic Scene Manager (default)
{QUOTE(replyto="Kojack")}The default generic manager (the one that's built in) isn't that good. It can do hierarchical frustum culling, but relies on you to build the hierarchy. If you add 1000 nodes with entities to the root scene node, each has to be tested for culling every frame. Raycasting is even worse, it always tests every bounding box for a ray intersect, it doesn't use the hierarchy (if a parent node isn't hit, it still checks all children even though they could never be hit). In other words, never use it.{QUOTE}


!!Octree Scene Manager
Uses an [https://en.wikipedia.org/wiki/Octree|Octree] to split the scene and performs well for most scenes, except those which are reliant on heavy occlusion.
{QUOTE(replyto="Kojack")}The octree manager uses an octree (obviously) to subdivide the world. This means it should be able to quickly cull entire regions of the world (if the parent region isn't visible to the camera, no child needs to be checked). Raycasting used the octree too, so it can quickly find potentially colliding bounding boxes. Unlike some octrees, meshes aren't split. It puts entire meshes into leaf nodes (it's a loose octree). Note: If you use the octree scene manager, you won't be working with SceneNode objects, they are really a hidden class called OctreeNode (this is why you can't inherit from SceneNode and inject them into an existing scene, unless the SM is the default one).{QUOTE}

__Pros:__
* A simple and generic solution, works well for most scenes
* Can use the [http://www.ogre3d.org/docs/api/html/classOgre_1_1StaticGeometry.html|StaticGeometry] class to accelerate large chunks of immovable geometry
__Cons:__
* No specific acceleration for particular scene structures
* Heavily occluded scenes will need a more specialised solution


!!BSP Scene Manager
This scene manager is intended for use in interior scenes. Particularly, it is optimized for the sort of geometry that results from intersecting walls and corridors.

The normal process for creating levels in a format usable by the BSP scene manager is:
* Use one of the ((DCC Tools|#Level design|numerous level editing tools)) to create your level, saving the level in ''.map'' format.
* Compile the ''.map'' file to a Quake 3-style ''.bsp'' file, which can be read in by the BSP scene manager. You can use id Software BSP compiler (q3map2) for this task, since it's no longer proprietary (released under the GNU GPL).
{QUOTE(replyto="Kojack")}The BSP manager loads quake3 levels. BSP (Binary Space Partition) is an old technique. It has a some visibility and region division uses, but for rendering it's actually a poor technique. It was good for software rendering because it could order all faces for back to front rendering without needing a z buffer, but it causes bloated tri counts, potential flaws where it cuts geometry, etc. Brute force rendering is quicker these days, and we have a real z buffer. Ogre's bsp is pretty neglected, it's kept compatible with ogre but isn't really much use these days.{QUOTE}


!!Portal Connected Zone Scene Manager (PCZSM)
See the ((Portal Connected Zone Scene Manager)) page for information on this scenemanager.

{QUOTE(replyto="Kojack")}The Portal Connected Zone manager (and the octreezone plugin which goes with it) allow you to define zones in the world and portals which connect them. You can only see the contents of a zone if you are in the zone or can see the portal into a zone. It's harder to set up because this isn't automatic, you need to place zones and portals, but it can occlude things which are within the frustum but behind other objects.{QUOTE}

__Pros:__
* Optimized for interior scenes.
* Compatible with numerous level editing tools.
__Cons:__
* Quake 3-style ''.bsp'' format may not be that efficient with modern GPUs in any case.
* Some people recommend instead creating levels in a general purpose modeling tool such as ((Tools: Blender|Blender)), exporting the level in ''.scene'' format.
Here is a link to a Blender BSP importer which works great: [http://blenderartists.org/forum/showthread?t=41306]


!!Ogre Terrain System

The ((Ogre Terrain System)) is the __default terrain system__ since Ogre 1.8.

__Pros:__
* SceneManager independent, separate optional component
* Long term support (because it's no add-on, it's part of the Ogre core)
* Many improvements in comparison to older/other terrain managers
* Integrates with (optional) Ogre::Paging component 
* Inherently editable - a lot like ((ETM))
* In-built support for ((-Terrain Splatting|splatting layers)), configurable sampler inputs and pluggable ((-material|material)) generators
__Cons:__
* Maybe there are still some performance optimizations needed
__See also:__ ((Ogre Terrain System)) for a lot of additional information and links regarding the new component.


!!Terrain Scene Manager
The ((Terrain Scene Manager|terrain scene manager)) (TSM) is intended for relatively small scenes involving static terrain. This scene manager makes it easy to generate terrain from a heightmap. Heightmaps can be created from a ((DCC Tools|#Terrain generation|variety of tools)).
The TSM is an extended version of the OctreeSceneManager (with added terrain chunks). 

__Note:__ In Ogre 1.8 the TSM was ''__removed__'', in favor of the new and more powerful ((SceneManagersFAQ|#Ogre Terrain System|Terrain Component)). So it's only available up to Ogre 1.7.

__Pros:__
* Fast rendering of high-resolution terrain (due to efficient level of detail and culling algorithms)
* Easy to generate terrain via heightmaps and terrain textures
* Vertex program based morphing between ((-LOD|LOD)) levels
* Customisable material so you can use shaders if you want
__Cons:__
* No paging out of the box - the interface hooks are there but you need to add it
* No splatting out of the box, but can be done with a custom material
Detailed documentation on the terrain scene manager can be found ((Terrain Scene Manager|here)).


!!Paging Scene Manager (ogreaddons)
The ((Paging Scene Manager)) allows scenes to be split into a set of ''pages''. Only those pages that are being used need be loaded at any given time, allowing arbitrarily large scenes. Each page has its own heightmap, to which several textures can be applied by height. This allows snowy-peaked mountains within a green landscape, for example.

__Pros:__
* Handles larger scenes than both the terrain and nature scene managers
* Allows Real-time Terrain deformation and saves to files.
* Allows multiple heightmaps and multiple textures per heightmap 
{CODE(wrap="1")}     Image + detail (fading on distance)
     Texture coloring based on user height (4 colors)
     Splatting.
     Real-time Splatting using Shaders.
     Real-time Texture coloring based on user height (4 colors){CODE}
* Special Video Card Memory Savings that divides at least per 3 Memory consumption:
{CODE(wrap="1")} - Texture Coordinates sharing accross pages (one texture coordinates set for any number of pages.)
 - Displacment Mapping using shaders (use only one float for a vertices instead of 3.){CODE}
* Map Tool (called "Mapsplitter") that split Big Map and Textures in pages, can compute lightmaps, normal maps, splatting maps. 
* Support Raw Heightmap up to 16 bits per height (instead of 8 bits jpg,png files)
* Real-time Map change, Texturing Change
* Binary demo here: [http://tuan.kuranes.free.fr/Ogre.html]
* Vertex Morphing using shaders
* Horizon Occlusion Visibility Real-time determination: nothing behind a mountain will be sent to the video card
* Octree support
__Cons:__
* Requires installation of the paging scene manager plug-in
* Needs use of The Map Tool to generate pages
* More options means more complexity


!!DotSceneOctree SceneManager (ogreaddons)
The DotSceneOctree SceneManager allows the geometry and meshes of a scene to be stored in a single file. 
It's a kind of a hybrid of static geometry and the octree. It has an external tool which merges all geometry into octree nodes based on material type and maximum triangle count. It registers all scene types. 

__Pros:__
* Contains scene in a single file
* Allows meshes to be classified as static or dynamic
* Octree support
__Cons:__
* Needs use of a processing tool to build a binary octree (.bin) file.
* Does not support 32 bit indices, so bigger meshes needs to be split up before being fed to the processing tool.

!!Myrddins Paging Landscape Plugin
A project with many features and great looking terrains. 

The terrain is editable (only by Mogre projects).

For more details look to ((Myrddin Landscape Plugin)).

__Pros:__
* It works with Ogre and ((MOGRE|Mogre))
* ...
__Cons:__
* ...

!!Editable Terrain Manager
A project which offers an API to edit height and texture of a terrain. 
For more details look to ((ETM|Editable Terrain Manager)).

The powerful landscape/scene editor ((Artifex Terra)) uses the API of the Editable Terrain Manager. Created scenes can be loaded to Ogre applications by an additional loader.

__Pros:__
* It works with Ogre and ((MOGRE|Mogre))
* ...
__Cons:__
* ...

!!Overhang Terrain Scene Manager
Can display terrain with overhangs and tunnels. 
It's a modified version of the Terrain Scene Manager, which adds modifications/additions to height map based terrain. A modify tool is integrated. 

It was created for Ogre 1.4 and is open source. 
For details look to page ((Overhang Terrain Scene Manager)).


!!Planet Rendering Engine
The aim of this terrain manager is to render a planet. So it's possible to fly from far away to the planet, plunge to the atmosphere and move plane to the planet surface. A ((-LOD|LOD)) system is integrated for seamless gradation.

More details are in this [http://www.ogre3d.org/forums/viewtopic.php?f=11&t=39254|forum thread].

__Pros:__
* ...
__Cons:__
* ...

!!Tunnel Scene Manager
For Ogre it's __not available__. But it's listed here for information and inspiration.

Most (high performance) racing games use a "tunnel" scene manager. It's all about he spatial structure of the game: A game like Mario Kart needs to be more than a tunnel in spacial terms but a F1 or WipeOut-like game would benefit from it.
A "tunnel" scene manager would part space in chunks that are following a way.


!See also
* ((OogstsHowTo2|#How to choose your SceneManager|How to choose your SceneManager))
* ((Terrain Howto))
History: SceneManagersFAQ

Source of version: 42 (current)

Search by Tags

Latest Changes

Search

Online Users
