The purpose of the render manager system is to gather rendering commands submitted from game code and sort them to get proper effects, draw order, and optimal performance from GFX.


RenderInst is a base structure for more task-specific render managers. The current version of RenderInst only contains information on sorting, translucency, and rendering type overrides.


ObjectRenderInst is a derived from RenderInst. It does not actually contain any information about meshes, materials, transforms, etc. However, it makes use of a very important feature: Delegate callbacks.


Derived from RenderInst, a MeshRenderInst object contains the critical data needed for rendering. It is declared directly below ObjectRenderInst. Within this structure is an object's geometry(mesh), lighting information, textures, transforms, and base material.

Some of the most basic classes are used in MeshRenderInst:

  • GFXVertexBufferHandleBase and GFXPrimitiveBufferHandle handle the vertex buffer and primitive buffer (respectively)
  • World transforms and object-to-world transforms are handled by MatrixF pointers
  • LightInfo pointers retain information for primary and secondary lighting
  • GFXTextureObject pointers also aid in lighting, as well as texturing the object


RenderBinManager manages and signals a main list of RenderInst objects.

RenderBinManager contains the variables and functions necessary for adding, processing, sorting, and clearing RenderInst objects. To get a closer look at RenderBinManager, open engine/source/renderInstance/renderBinManager.h and renderBinManager.cpp.

Most of the important management functionality is defined in the class, but you should notice a very important chunk of functionality missing: rendering code. RenderBinManager does have a rendering function:

virtual void render( SceneState *state ) {}

But as you can see, we are not going to be directly using a RenderBinManager for rendering. It's important to know how the class's base functionality works, but we will get to the actual rendering code when we look at RenderBinManager's children.

This class lays the ground work, but the tangible rendering sub-managers derive from RenderBinManager: RenderMeshMgr, RenderObjectMgr, RenderTranslucentMgr, and so on. These are detailed further down in the sub-managers section.


The RenderPassManager could be considered the "top manager" when it comes to the rendering system. The responsibilities of this manager include:

  • Declaring and organizing the various RIT: "R"ender "I"nstance "T"ypes
  • Allocating a render instance for MeshRenderInst, ObjectRenderInst, and so on
  • Adding, sorting, and rendering a list of RenderInst's per bin
  • Memory allocation and deallocation for the RenderBinManagers
  • Adding, sorting, and managing the various RenderBinManagers. The importance of this task is best shown in code

CLICK HERE to see the code initializing the rendering managers.

The premise behind this chunk of code is simple. Calling DiffuseRenderPassManager "the manager of managers" seems appropriate. As the client is being initialized, initRenderManager() is called to create the rendering managers.

Using the .addManager(...) function, the RenderPassManager stores an internal list of RenderBinManagers. We have managers for Sky, Interiors, Lighting, Shadows, and so on.


As mentioned previously, the actual rendering managers are children of RenderBinManager. We are calling them sub-managers, since the RenderPassManager manages and maintains them. Each of these rendering sub-managers contains rendering code unique to its purpose, though multiple instantiations do occur to handle our various renderable Torque objects.

Let's go down a simplified list of these classes and their main purpose:

  • RenderObjectMgr - This class is used for rendering more than any of the other sub-managers. This manager is responsible for rendering common objects that do not have a standard mesh.
    • Sky
    • Shadows
    • Water
    • Foliage
    • Shapebase
  • RenderMeshMgr - This class is used for rendering mesh based objects such as interiors, TSMesh, and decals.
  • RenderTerrainMgr - This class is used for rendering the terrain.
  • RenderRefractMgr - Stock Torque 3D uses only one RenderRefractMgr. The name of the manager describes it well. This manager takes in RenderInst elements and checks to see if they have a refraction custom material. If this check succeeds, the element is maintained by the manager and makes use of the refraction rendering code.
  • RenderImposterMgr - This is a special render manager for processing single billboard imposters typically generated by the tsLastDetail class.
  • RenderOcclusionMgr - Used for performing occlusion queries on the scene.
  • RenderTranslucentMgr - Stock Torque 3D uses only one RenderTranslucentMgr. This manager is a bit more complex than the previous ones described. A RenderInst element must meet a strict set of requirements to be managed by this class. If you look at RenderTranslucentMgr::addElement(...), you can see there are 3 main if(...) statements checking for translucent properties and appropriate render instance type. The actual render function is quite clean, and you can gain more insight about the class by reading through it.
  • RenderGlowMgr - Just like the previous two managers, there is only one instance of RenderGlowMgr in stock Torque 3D. The name is pretty self-descriptive. This manager is responsible for accepting RenderInst elements that require rendering with a properly set up glow buffer.


The purpose of this document is to provide you with a basic understanding of the rendering management system used by Torque 3D. There is still much to be explained in the way of rendering flow, extending the system, and specific examples.

We've covered the basic renderable object instances, base class render managers, specialized rendering manager classes, and touched on some new subjects such as the RenderDelegate.