Performance

[holland01]

A lot of the desired features will be pointless to implement if the renderer performs poorly.

While a release build will be significantly optimized when compared to a debug build, the debug build will be tested more often than the release build, since it contains debugging information. A reasonable performing debug build which can hit 60 FPS should be the bare minimum.

So far, there's been an ~12 MB decrease which was set apart by:

• Removing the image data after it's been copied to the GPU
• Locally allocating some data which was originally held by the renderer instance.
• Ensuring that various texture settings that were stored were not repeated/duplicated in other areas of memory. Example: settings for mag and min filters, bytes per pixel, internal and external texture formats, etc.

This is good, but there are still bottlenecks which are most likely due to the following:

• Draw calls. (NOTE: it may be possible to submit a single glDrawElements call with an aggregation of offset indices into the element array buffer that refers to the vertices themselves)
• Visible surface determination: what are you doing that you don't need to be doing? This implies the following questions:
  • Could there be a performance improvement by incorporating a raycast which finds the farthest projection plane? Could/should you check for this far plane during the frustum cull check?
  • Is there anything you're doing in the BSP tree traversal itself that may be of value in the end?
• Something which might help on the far plane check would be sorting the objects we render by their depth (in view space) and then computing the distance from the camera to the farthest object; that would be the far plane we wish to use. Sorting could be used via bounding boxes, or even something more fine-grained - if we use bounding boxes we should store indices (not pointers, since indices are 4 bytes and pointers will be sizeof(void*) on x86_64 is obviously 8).

• Iterating over the leaf faces in a faster manner. Example; maybe you could do something along the lines of:

    for (int i = 0, j = numFaces - 1; i < half && j >= half; (i += 2, i -= 2))
    {
          processLeafFace(faces[i + 0]);
          processLeafFace(faces[i + 1]);
  

  processLeafFaces(faces[j - 0]);
  processLeafFaces(faces[j - 1]);         

  }

[holland01]

Things to think about:

• Draw Surface Container and Ordering: Using a hash map to store draw surfaces; likely ordered, using a specific view-space oriented z-value pertaining to something; bounding boxes, partitioning planes, whatever. Find data which is relevant to a given face (e.g., a bounding box which contains a group of faces, or a plane which the face lies in) and use that as an index. The traversal is designed to draw faces in the following format:

surfA->face0: draw
surfA->face1: draw
surfB->face0: draw

The problem with this is that the grouping is not dependent on any particular draw order, but is more dependent on the following parameters:

* The shader of the face
* the texture of the face
* the lightmap of the face
* the type of the face

While these are all useful, they do not quite cut it because there is nothing in there which will group faces into a surface such that they result in having the intended order of discovery. In other words, if: face0, face1, and face2 are found in their respective order, we could potentially draw face1 and face2 before face0, because the surface might group face1 and face2 together, when in reality face1 is far closer to face0 and should be grouped based on that.

So, you need a better heuristic.

• Additive Sorting: for effects (as per the quake 3 manual - the sort keyword) refers to keeping transparent faces in a back-to-front order (i.e., if a shader has a blend func, we can consider this shader as a transparent entity - so, IsTransFace() should return true if the face's corresponding shader has anything that is not a GL_ONE, GL_ZERO combination.
• Tree Traversal Ordering: you want to figure out whether or not the indices in the node's children array are formatted as (0 => back, 1 => front) or (0 => front, 1 => back). This is kind of a big deal, because it effects everything. it seems like what was originally there was the correct order, HOWEVER, this should be verified somehow (you may need to check the id Tech 3 source code).
• Tansparent/Solid Face Gathering: See if you can take care of transparent faces and solid faces simultaneously during the same traversal, instead of doing one entire search for solids and then one entire search for transparents afterward.

[holland01]

List of simple improvements

• Removing any duplicate shader programs, referring to them via a handle based mechanism in the effect shader.
• Assessing what kind of state can be handled directly in the vertex shader or fragment shader.
• Removing anything in shaderInfo_t* which isn't actually used in the render-loop (this coincides with the previous bullet, considering that certain effects such as vertex deforms may be better handled directly in the shader).
• Using glMapBuffer strictly for writing; doing reads is known to cause performance problems.
• Allocating enough space in the vertex buffer per object, and using glMapBuffer to update object data as necessary; this should save a lot of GPU memory. The indexing mechanism will need to be redesigned, though, given that its current implementation is dependent entirely on the layout of vertices in the map file.
• compressed texture formats.
• Algorithm which provides better z-fighting resolution with a 16-bit depth buffer. It sounds like glPolygonOffset can cause performance issues, so it may be beneficial to resolve this in the shader directly; e.g., by modifying the clip space transform.
• Reducing as much GL state changes as possible.
• Analyzing the structure of the command buffer, and seeing if there can be any improvements made in that area.
• Taking the gTextureImage_t buffer in gTexture_t and ensuring that no duplicate items are created; this will likely require a complete decoupling so that each member of the texCoordSlot_t struct is put into its own separate array. Then, an arbitrary texture struct can just reference each member individually using indices. This will save memory, given that the max a key-holding data-type would have about 4 bytes maximum, where as the current gTextureImage_t struct literally takes up 32 bytes. Technically speaking, it's very possible that 2 byte indices could be used instead.