=Cinematic

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.

=glext.h

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

=GuiModel

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_files

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

• R_LoadCubeImages() is used to render skyboxes.

=Image_init

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

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

=Image_load

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

These low-level functions communicate heavily with OpenGL.

=Image_process

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).

=Image_program

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

=Interaction

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

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

=Material

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).

=MegaTexture

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)

=RenderEntity.cpp

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.)

=RenderSystem

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.

=RenderSystem_init.cpp

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

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

=RenderWorld.h

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.

=RenderWorld_local.h

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()).

=simplex.h

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.

=tr_backend.cpp

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.)

=tr_deform.cpp

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

=tr_font.cpp

Character fonts.

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

=tr_guisurf.cpp

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.

=tr_light.cpp

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.

=tr_lightrun.cpp

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

=tr_local

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