 |
The changes made in Doom3 BFG for GPU Skinning: - In Model.h: The basic surface type (triangle mesh) has had an extra pointer added: idRenderModelStatic* staticModelWithJoints. That's used for meshes whose vertex positions are determined by a set of joints. - idMD5Mesh -- which represents a modelDef, the data shared by all AI of a given type has had several changes: - - idMD5Mesh::ParseMesh builds an AI mesh in base pose (T-pose) which it loads to the GPU as a static vbo. That's the base mesh used to draw all AI of that type later. It also generates a list of matrices, one for each joint, that translate from model space into joint space. - - idMD5Mesh::UpdateSurface chooses wehther to skin a given mesh for a given frame on the CPU or GPU. It used to do CPU skinning in all cases. In BFG it can choose to produce a set of updated joint matrices instead, whixch'll be used on the GPU to skin the mesh. - idRenderModelMD5::InstantiateDynamicModel used to call idMD5Mesh::UpdateSurface for each mesh. In BFG it builds the skinning matrix, a matrix for each joint in its current position which will be used to move all attached vertices into position. - tr_frontend_addmodels.cpp This is a new file in BFG, which inherits some of the functions from (missing) tr_light.cpp, including R_AddModels, now with more variants. Does VBO allocation for loading the current joint configuation for an AI to the GPU. Uses a single-frame vbo, so it gets replaced once per frame. Tests whether it's current for the frame. - tr_backend_draw.cpp - - RB_RenderInteractions chooses between versions of the usual shader programs for light-interacting surfaces or shadow volumes -- each program now comes in 2 flavours, for skinned or unskinned meshes. - - RB_DrawElementsWithCounters binds the uniform buffer (current joint config) and does the rest. - VertexCache - - has been upgraded to allow a third type of vbo -- the list of current joint matrices for a skinned mesh. This is a uniform buffer object, not an array of vertex data. - The shader system is now pure GLSL (no ARB assembly shaders). That enables some of the above techniques. |
|
|
Some parts of the above implementation are supported only by GLSL shaders, and we won't be able to use them unamended with our ARB shader programs. Upgrading to allow GLSL shaders is an obvious later step for TDM engine, but there are reasons to push ahead with GPU Skinning and soft shadows first -- i.e., that upgrading to GLSL might take a very long time or not get finished. The BFG implementation is still a close fit for our engine, so we'd use much of it, but we'd need some changes: - VertexCache -- we can leave this unamended. We can't use the new uniform buffer objects for storing joint matrices until we have GLSL. - Model_MD5 changes: we'd want these. The routine to build the initial bind pose, and the changes to InstantiateDynamicModel which makes a skinning matrix for each frame. But we'll need to break the skinning matrices into a more compact representation -- a quaternion plus a vector offset (7 floats) instead of a matrix (minimum 12 floats). - tr_frontend_addmodels: we won't use this change. We can't (yet) use uniform buffer objects. We will have to load the skinning matrices during the backend draw, using the environmental and local shader program variables. Additional changes ================== The big thing is we can't pass as much data to the gpu per AI as BFG's GLSL implementation does. It uses a set of 102 4x4 matrices (=408 "registers") to hold the current position and orientation for each joint -- so the joint limit for any AI is 102 (not counting joints that are not used for skinning). We will have to deal with tighter limits. My GPU allows 4096 regsiters to be passed as uniforms to GLSL programs in a single draw call, but only 256 registers for ARB programs. And the spec for ARB says that cards have to support only 96 registers, so we should try to stay in that limit. We can get a second set of 96 registers by using both environmental AND local parameters, giving 192 to play with. The engine already reserves 21 environmental registers (numbers 0-20) for drawing light interactions, and 4 local registers for the "VertexParm" parameters that people can specify in shader programs. So we have range 21-95 of each set clear to play with. That's a maximum of 76 joints, if we put the joint's orientation as a quaternion in one list, and the joint's position as a vector in the second list. Each of those can be packed into a single register. TDM's most complex AI models use 68 joints for skinning, so it's enough. Any meshes that wanted to use more joints in future would have to continue to be skinned on the CPU, at least till we implement GLSL. BFG packs the vertex->joint mappings and weights into the original mesh's "color" settings. I'll have to check whether we use vertex coloring for any light interactions. If we do, then we can't do that. Ideally we'd find somewhere else to put them so we maintain maximum flexibility. |
|
|
Fortunately, there's not much code that creates VBOs, and even less that's used by MD5 meshes. It all sits in idVertexCache, ::Alloc() and ::AllocFrameTemp(). This is a clean design and it shouldn't be too hard to work with. ::AllocFrameTemp() deals with the memory meant to be used for single-frame meshes. Two buffers are maintained of 2mb each, so that one can be written to while the other is being read from ("double-buffered"). In theory anyway. We don't need it while we are using single-threaded architecture, and it isn't used much. Only used by gui drawing, weather patches, skybox texgens, and some decals. ::Alloc() is the one used by md5 meshes (as well as the rest of the world's solid objects). Only 2 functions pass lists of mesh vertices to the GPU (they use "Alloc"): - R_CreateAmbientCache -- which does visible surfaces - R_CreateVertexProgramShadowCache -- which does shadow volumes For a static model, this only needs doing once at map start. For md5 meshes, it's done every frame while they are in view. Those functions pass the entire mesh to the GPU. Individual lights will hit subsections of those meshes. Only 2 functions pass indexes to the GPU. The indexes are what specifies subsections of the meshes loaded above, for individual light interactions: - idInteraction::AddActiveInteraction -- which deals with lit materials and shadow volumes - R_AddAmbientDrawsurfs -- which deals with unlit materials (or unlit stages of a material decl) A given light will probably hit less than half the tris belonging to an AI (because the other half will be facing away). So the interaction between that light and the AI mesh will need a subset of the vertices that got uploaded by R_CreateAmbientCache above. That subset is identified by an index, and the index needs calculating and uploading every frame, as the subset of tris changes frame by frame. Likewise the shadowcasting sillhouette changes frame by frame. That gets uploaded as a index to the shadow volume verts too. Typical figures in bytes for the allocations in 1 frame, for one AI hit by 1 shadowcasting light and one ambient: R_CreateAmbientCache 273120 (Verts) R_CreateVertexProgramShadowCache 74176 (Verts) idInteraction::AddActiveInteraction 190560 (Index) R_AddAmbientDrawsurfs 66312 (Index) The aim of GPU skinning is to save the Verts allocations, or just over 57% of the total. We might be able to cut down on indexes too. The duplicate data mentioned in the original report is duplicate index data coming from idInteraction::AddActiveInteraction, but that's probably a separate task. Also, I need to check the BFG code again to see how it handles he indexes for interactions. Maybe (hopefully) it's doing something different. To be able to calculate the indexes on the CPU as is done now, it would need to skin the visible meshes on the CPU too, else it wouldn't know which tris face the light and which don't. |
|
|
Moving objects like func_rotators and func_movers don't upload new vertex data every frame. The verts are static because they are measured in relation to the model's origin and axis, and those measurements don't change when the model moves. It's just the model origin and axis that change. Instead of uploading new verts, they just create new indexes for light interactions, to say which bits of the model are hit by lights. Likewise a moving light doesn't cause static models to re-upload their vertex data, but again the indexes are nvalidated and get recreated and re-uploaded. For static models where the lights are not moving, none of the above gets recreated or re-uploaded. Both vertex and index vbos are re-used frame to frame. |
|
|
BFG only did half the job with vertex skinning, and we shouldn't stop where it left off. It saves about half the traffic between the CPU and GPU (the vert locations for animated meshes), but it still relies on the CPU calculating and uploading the other half each frame: the indexes (lists) of triangles that are hit by a light each frame, and the shadowcasting sillhouette of each model. BFG is still an OpenGL2 renderer. It uses GLSL but it doesn't take advantage of any of the OpenGL3 facilities that could cut out the rest of the traffic. We could try using a geometry shader to discard unlit triangles, for example, and to work out the shadow sillhouette. Doing this work on the GPU instead of the CPU is essential because we want to use Instancing for drawing multiple copies of a model in one draw call, which means we'll want to use the same lists of tris for every copy of a model. No more having the CPU work out what tris get hit by a light, which makes it maintain and upload a different Index for each copy of a model. One example that we do want to follow from BFG: it adopts a "stateless" system where none of this info is cached between frames, or even between draw passes in a single frame. It's all re-calculated every time it needs to be used. That's a good thing both for code simplicity and for performance. Since the engine was designed, number-crunching has become relatively much cheaper than storing and retrieving blocks of data. |
 |
Today: 9/17/2017 Code freeze: 10/4/2017 Possibility of completion in 2.06? 0% Moving to 2.07 |
 |
Is this track still relevant give all the new changes since 2.08..? |
|
|
@cabalistic , thanks for picking this up fella. |
|
|
Id Tech 4 "Iced Tech Engine" has implemented this: https://github.com/jmarshall23/IcedTech Though the divergences in this engine may be too extreme to be of use compared to porting BFG changes (etc). Edit 2024-03 : icecoldduke ( the developer ) has offered assistance with porting the GPU skinning portion |
|
|
Hah, Robert had a fork of vanilla Doom 3 with GPU skinning hidden in his repo for awhile: https://github.com/RobertBeckebans/TEKUUM-D3 |
- Anonymous
