id Tech 4 Classes (neo/renderer)

Descriptions of files in the neo/renderer folder.

  • The name of each section refers to the C++ files (.h and .cpp) with the same name. For example, Cinematic indicates the files Cinematic.h and Cinematic.cpp.
  • Some sections will show a file extension to mark a single file with no companion, such as glext.h.
  • A "+ description" note means that the file contains a detailed description of one or several classes.
  • A class name between parentheses signifies that it is inherited: SubClass (BaseClass).
  • Some hypotheses are shared in this page. They are probable, but unconfirmed.

Files in this folder are part of the "DoomDLL" project.


idCinematic and idCinematicLocal are used to display RoQ videos. RoQ is Doom 3's main video file format.

=draw_arb.cpp, draw_arb2.cpp, draw_common.cpp, draw_nv10.cpp, draw_nv20.cpp, draw_r200.cpp

These files are the backends for all video card architectures supported by Doom 3, which (according to idDevNet) are:

  • NV20 (Nvidia)
  • R300 (Radeon)
  • ARB
  • ARB2
  • CG (Nvidia)

However, there seems to also be support for the NV10 and the R200, and there are no files for the R300 and CG. I would expect the R300 to be backward compatible with the R200, but it is unclear how CG is managed.

ARB is probably the OpenGL Architecture Review Board's assembly language.

All these files define global functions, some of which are implementations of prototypes in neo/renderer/tr_local.h.

draw_common.cpp is almost certainly used just to group commonly used functions.


An OpenGL file that defines macros, function prototypes, etc. for various extensions (GLext == GL extensions).


Gui management. This class does not hold many methods:

  • idGuiModel::EmitToCurrentView() displays a gui on a screen.
  • idGuiModel::EmitFullScreen() manages fullscreen guis (menus, hud).
  • idGuiModel::SetColor() determines the colour of every pixel in a gui.
  • The first version of idGuiModel::DrawStretchPic() displays the console and guis appearing on screens.
  • The second version appears to only affect the in-game console.
  • idGuiModel::DrawStretchTri() is called by idRenderSystemLocal::DrawStretchTri(), which itself is only called in the "d3xp" project.

=Image (+ description)

Texture management. The idImageManager class is defined here.

A comment from Image.h: idImages have a one to one correspondance with OpenGL textures.


Image file type management (jpeg, bmp, pcx, tga). All functions are global.

  • R_LoadCubeImages() is used to render skyboxes.


Image initialisation (see idImageManager::Init()).

  • The global function R_BlackImage() creates a black image for fade-ins and fade-outs.


Many of idImage's methods (presumably those dealing with image loading) are defined here.

These low-level functions communicate heavily with OpenGL.


Image-related operations (x/y reflection, rotation, mipmapping, etc.) are grouped in these files. All functions are global.

  • R_HorizontalFlip() reflects an image on the horizontal axis (so it is upside-down).


Other image manipulation actions, such as creating normal maps, inverting color or alpha channels and scaling.


Interactions between surfaces (idRenderEntityLocal) and lights (idRenderLightLocal).

  • idInteraction::CreateInteraction() allows light to hit surfaces on walls and objects.


An idMaterial object is an individual material, to be applied on the surface of a brush or object; it is defined with an .mtr file.

  • idMaterial::AddImplicitStages() is used to create implicit (generic) bumpmaps or specular maps for materials who have none.

    If there is no diffuse texture (basic image) or bumpmap, the object with the material will simply be black. Depending on available textures, some generic ones will be added for light interactions.

  • idMaterial::CheckForConstantRegisters() (void function) ends immediately if the material definition contains a known variable (see idMaterial::ParseTerm()).

    If none is found, it creates an array of floats (shaderParms[]) and calls EvaluateRegisters(), passing it idMaterial::constantRegisters[].

  • idMaterial::EvaluateRegisters(): idMaterial contains an array of floats named constantRegisters. The array is allocated in CheckForConstantRegisters(), but its values are assigned here.

    This function makes it possible for the C++ code to change properties whose values are variables, as opposed to fixed constants; a necessary step, because materials accessed through idDeclManagerLocal::FindMaterial() are constant.

  • idMaterial::GetDescription() returns the description property of a material.
  • idMateriall::GetNumStages() returns the number of stages (i.e. { } blocks) in a material definition.
  • idMaterial::HasGui() returns true if the material contains a graphic user interface.
  • idMaterial::IsDrawn() "returns true if the material will draw anything at all. Triggers, portals, etc, will not have anything to draw." (Comment just above the function in the code).
  • idMaterial::ImageName() returns the name of the image referenced by the material, as it is written in the material file (without the extension).


id Software's first try at megatexture management is not used in Doom 3 (though apparently it was improved significantly for later id Tech 4 titles such as Enemy Territory: Quake Wars). Therefore, the usefulness and reliability of the idMegaTexture class is dubious.

I've also noticed these files aren't present in Doom 3: BFG Edition's source code.

=Model / Model_local.h

Importing and exporting for Maya models.

idRenderModel (abstract, defined in Model.h) is inherited by a number of specialised classes: idRenderModelStatic, idRenderModelMD5, idRenderModelMd3, idRenderModelLiquid, etc.

These subclasses are all defined in Model_local.h and implemented either in Model.cpp or in their own file (Model_md5.cpp, Model_md3.cpp, Model_liquid.cpp).

The idRenderModelStatic class loads static (immobile) models from files of several types: .ase (Doom 3 static model), .lwo (LightWave Object), .flt (OpenFlight) and .ma (Maya ASCII).

  • idRenderModelStatic::TouchData() seems useful mainly to reference the model's material, without using or modifying it, to prevent its memory from being automatically freed after some time.

struct srfTriangles_s

Hypothesis: this structure may represent static geometry. It contains:

  • an axis-aligned bounding box (AABB) (idBounds bounds)
  • the number of vertices in the model and an array of the vertices (idDrawVert * verts)

The following files are all related to model formats used by Doom 3. The classes mentioned are defined in Model_local.h and implemented in the specified files.


ASE (ASCII Scene Export) models are static models with no animation. There is no idRenderModelASE class; the two functions defined here are global.


Implementation for idRenderModelBeam, the basis for the func_beam entity.


Doom 3 makes no use of any kind of liquid, so the idRenderModelLiquid class was probably an unsuccessful attempt at water physics. The class appears incomplete, and not very useful.


LWO2 (LightWave Object) models. Global functions, no specialised classes.


MA (Maya ASCII) models. Global functions, no specialised classes.


Quake 3's MD3 (animated) models. The header defines structures used by idRenderModelMD3; the .cpp implements its methods.


MD5 (animated) models, likely created for Doom 3. Implementation of methods from idMD5Mesh and idRenderModelMD5.


For particle definitions (.prt files). Implementation of methods from idRenderModelPrt.


A simple sprite model that always faces the view axis. (From a comment in the code.)

Sprites are images that always face the player. Games often use this technique for prerendered effects like fire.

Many materials have the attribute deform with the value sprite. This indicates the texture must always face the player.


Decals are small textures that are applied over other textures, such as the bullet hole that appears in a wall when it is shot.

For example:

  • idRenderModelDecal::CreateProjectionInfo() displays the decal.
  • idRenderModelDecal::RemoveFadedDecals() rids the scene of decals that are no longer visible.


idRenderModelManager (abstract) is inherited by idRenderModelManagerLocal, which takes care of loading, maintaining and freeing memory for models.


idRenderModelOverlay is similar to idRenderModelDecal, but displays decals on dynamic models, like monsters.

  • idRenderModelOverlay::CreateOverlay() displays the decals.


Implementations for idRenderEntityLocal (idRenderEntity) and idRenderLightLocal (idRenderLight).

Nearly all function implementations are empty; the base classes, idRenderEntity et idRenderLight, are both abstract, and their pure virtual methods need to be defined by their subclasses.

(Though I wonder why these methods even exist, since they have no effective definition anywhere.)


idRenderSystem (abstract) is inherited by idRenderSystemLocal in neo/renderer/tr_local.h.

This file also declares three global functions that are implemented in other files: R_RenderLightFrustum(), R_LightProjectionMatrix() and R_ScreenshotFilename().

The constants SCREEN_WIDTH and SCREEN_HEIGHT, used for relative placement in guis, are declared here. The comments provide more information:

// all drawing is done to a 640 x 480 virtual screen size
// and will be automatically scaled to the real resolution

See tr_local.h.


This file creates the CVars related to rendering (the ones that start with r_).

RenderSystem_init.cpp and RenderSystem.cpp implement methods in idRenderSystemLocal.


idRenderWorld (abstract) holds all visual objects that will be rendered. It is inherited by idRenderWorldLocal in RenderWorld_local.h.

  • The renderEntity_s / renderEntity_t struct holds the model of an entity and some additional graphics data (position, properties, settings).idEntity has an object of this type.
  • renderView_s is a struct that represents the image produced by a given camera (including the player's view). It is updated each frame.


idRenderWorldLocal manages visible entities and lights, portals (struct portal_s), and probably graphical debugging information.

Its methods are implemented in three files:

  • RenderWorld_demo.cpp: for demo purposes, irrelevant.
  • RenderWorld_load.cpp: loading and construction of models and geometry.
  • RenderWorld_portals.cpp: portal management, connections between rooms; information gathering (NumPortals(), FindPortal(), AreasAreConnected()).


When the g_showentityinfo CVar has a value of 1, names of entities in the map are displayed for debugging. The vector lines of these characters are described in this file.


A list of global functions.

  • GL_State() checks several things each frame; for instance, it solves the problem of distant objects that are drawn over nearby ones.
  • GL_Cull(): "This handles the flipping needed when the view being rendered is a mirrored view". (Comment from the code.)


Various effects that can be used on surfaces. Global functions, no specialised classes.


Character fonts.

  • idRenderSystemLocal::RegisterFont() tries to load a given font, and returns false if it fails.


Different kinds of interactions with guis.

  • R_SurfaceToTextureAxis(): I believe this function converts the player's orientation into 2D coordinates for in-game guis. This allows the gui to know where to draw the mouse cursor.
  • R_RenderGuiSurf() renders the gui's screen.
  • R_ReloadGuis_f() is the function behind the reloadguis console command. It fetches the gui's information from the .gui file if it has been updated.
  • R_ListGuis_f() is the function behind the listGuis command, and outputs a list of all active guis to the console.


All the functions here are global, except for one.

  • idRenderWorldLocal::CreateLightDefInteractions() manages interactions between lights and entities. Without this method, only surfaces that require no light (like guis) will be visible.

This function has several steps, such as:

  • checking that every entity is visible
  • checking if the light must produce shadows
  • checking if the interaction has already been created

Many of the global functions create a cache for resources used by lights and shadows.

  • R_CreateAmbientCache(): I'm not sure what this function does, but commenting it out made everything go black after the initial loading screen (though I could still open the console, which was invisible, and quit out of the game with the quit command).
  • R_SkyboxTexGen() is used for skyboxes.


Light management and display of entities (entity visibility relies on light sources in the scene).

  • R_CheckForEntityDefsUsingModel() identifies entities using a specific model.
  • R_RegenerateWorld_f() is called when the regenerateWorld console command is used. Here is the comment above the function:

    Frees and regenerates all references and interactions, which

    must be done when switching between display list mode and immediate mode


Classes :

  • idScreenRect
  • idRenderLightLocal (idRenderLight)
  • idRenderEntityLocal (idRenderEntity)
  • idRenderSystemLocal (idRenderSystem)

The areaReference_s struct holds information about what is inside each zone.

  • R_ScreenRectFromViewFrustumBounds() could be useful to frame and indentify objects in the scene...

struct drawSurf_s

According to a comment:

drawSurfs are the visible surfaces of the viewEntities, sorted by the material sort parameter

struct viewEntity_s

Contains information on an idRenderEntityLocal object that are necessary for the back end.

struct viewDef_s

This struct seems to group parameters for the current view. It contains the data necessary for displaying a camera view: a renderView_t object, a pointer to the render world, a number of booleans to indicate a reflective surface, and an idFrustum for the camera's view frustum, among others.

Member objects of note:

  • idRenderWorldLocal*
  • renderView_t renderView
  • idVec3 initialViewAreaOrigin
  • bool isSubview
  • idScreenRect viewport
  • idScreenRect scissor