Per-vertex animation with VBOs: Stream each frame or use index offset per frame?

Posted by charstar on Game Development See other posts from Game Development or by charstar
Published on 2011-02-15T11:25:57Z Indexed on 2011/02/15 15:35 UTC
Read the original article Hit count: 286

Filed under:
|

Scenario

  • Meshes are animated using either skeletons (skinned animation) or some form of morph targets (i.e. per-vertex key frames).
  • However, in either case, the animations are known in full at load-time, that is, there is no physics, IK solving, or any other form of in-game pose solving.
  • The number of character actions (animations) will be limited but rich (hand-animated).
  • There may be multiple characters using a each mesh and its animations simultaneously in-game (they will be at different poses/keyframes at the same time).
  • Assume color and texture coordinate buffers are static.

Goal

To leverage the richness of well vetted animation tools such as Blender to do the heavy lifting for a small but rich set of animations. I am aware of additive pose blending like that from Naughty Dog and similar techniques but I would prefer to expend a little RAM/VRAM to avoid implementing a thesis-ready pose solver. I would also like to avoid implementing a key-frame + interpolation curve solver (reinventing Blender vertex groups and IPOs).

Current Considerations

  1. Much like a non-shader-powered pose solver, create a VBO for each character and copy vertex and normal data to each VBO on each frame (VBO in STREAMING).
  2. Create one VBO for each animation where each frame (interleaved vertex and normal data) is concatenated onto the VBO. Then each character simply has a buffer pointer offset based on its current animation frame (e.g. pointer offset = (numVertices+numNormals)*frameNumber). (VBO in STATIC)

Known Trade-Offs

  • In 1 above: Each VBO would be small but there would be many VBOs and therefore lots of buffer binding and vertex copying each frame. Both client and pipeline intensive.
  • In 2 above: There would be few VBOs therefore insignificant buffer binding and no vertex data getting jammed down the pipe each frame, but each VBO would be quite large.

Are there any pitfalls to number 2 (aside from finite memory)? Are there other methods that I am missing?

© Game Development or respective owner

Related posts about opengl

Related posts about animation