Flexbodies deformed in vertex shaders

[ohlidalp]

Presently, flexbody deformation is calculated entirely on CPU and then uploaded to GPU (each frame, even if not seen by camera). This puts enormous load on both the CPU and the RAM->VRAM bandwidth, resulting in bad FPS. Normal mapping is disabled solely to save FPS, otherwise the process of calculating tangents (needed for normal mapping) is the same thing as calculating the vertex positions. But the tangents would be additional 3x4 bytes per vertex and the performance impact would be too big.

This is how the system works:

• user specifies an OGRE .mesh and a list of flexbody nodes in the .truck file, see https://docs.rigsofrods.org/vehicle-creation/fileformat-truck/#flexbodies
• on startup, the program loops through that mesh's vertices and for each one, generates a "Locator" which pairs the vertex with 3 softbody nodes (ref, x, y) and an offset (X Y Z). The nodes are taken from the list provided in .truck file, based on distance. Click for code
• before each rendering frame, the program loops through the "Locators" and updates vertex positions (in RAM) using the 3 nodes as euclidean space and the offset recorded on startup. click for code Then, the RAM image of the mesh is uploaded to GPU.

How it could work entirely on GPU (i'm 99% sure):

• .truck file remains the same.
• "Locator" generation remains the same.
• new setup step: Locator data are embedded directly to the mesh:
  • the offset (3 x 4-byte float) is placed to vertex position channel (VES_POSITION) - because we never need the original position anyway.
  • the nodes (3 x 2-byte unsigned short) are placed to secondary texcoord channel (VES_TEXTURE_COORDINATES) - because we only use one set of texture coordinates.
• new setup step: we apply a vertex shader to the mesh which will do the deformation.
• before each render, the code collects positions of the flexbody nodes and sends them to GPU as a 'constant buffer' (same data for all invocations of a shader). There is usually 10-50 nodes bound and we only need to send the positions (3x float4). @paroj Please help me here - is this a sane assumption, and does OGRE api support it?
• during render, the vertex shader implements the same deformation logic as done by code right now, just drawing the Locator data from the vertices and node positions from the 'constant buffer'.

PROS:

• neglible CPU cost, small GPU cost - very good FPS.
• normal mapping ON.
• OGRE makes sure it's only updated when on camera (frustum test).

Cons:

• executed on each individual render (shadowmap, envmap, water reflection, mirror, videocamera) instead of just once as with the CPU implementation. But since it's cheap for the GPU, this shouldn't be a problem.
• may impose a limit on the number of bound nodes, depending on hardware and OGRE capabilities.

[paroj]

disclamer: I did not read up how flexbodies actually work.

This reminds me a lot of pose animation. You can find a working example of doing them on the GPU here: https://github.com/OGRECave/ogre/blob/master/Samples/Media/materials/programs/GLSL/HardwarePoseAnimationWithNormalsVp.glsl

before each render, the code collects positions of the flexbody nodes and sends them to GPU as a 'constant buffer'

you could use plain uniforms, e.g. uniform vec4 data[150] and see how the hardware support for that is like.

True hardware constant buffers aka. UBOs aka Ogre shared_params are only available with D3D11 & GL3+. If you want broad hardware support, you will have to use vertex textures.

Note that you can also compute approximated tangents in the fragment shader: https://github.com/OGRECave/ogre/blob/07016dad53787106423087e9aabdb30d35bd4b19/Samples/Media/PBR/pbr-frag.glsl#L122