Getting from A to B via C, D, G, H and Z

· by Steve · Read in about 3 min · (485 Words)

I seem to be getting sidetracked an awful lot while doing this shadow work, more than is usual even for me. The fact is that there are a few things I’ve been meaning to change for a while, and they are going to affect the shadow work anyway, so I figure I might as well get them done now.

I’m currently implementing a ‘buffer copy licensing’ scheme where objects can ‘lease’ temporary vertex buffers which have the same attributes as another buffer, used for working storage for things like skeletal animation. This is because the current skeletal animation system stores no results, but I want to store them when doing software blending since I need the results in more than one place when I’m doing shadows. Interestingly, this has become even more important since I discovered that just about no graphics hardware supports fixed-function hardware skinning, which is GL_ARB_matrix_palette in GL and indexed vertex blending in D3D. The D3D docs give the impression it’s a common feature, but a straw poll of cards at all ends of the spectrum reveal that support is all but absent. Therefore, the only hardware skinning support will come from vertex programs, which are great but are a little laborious to write for all your vertex formats and for all your numbers of vertex weights per bone (you need a different program for each of 1-4 weights per bone). I’m going to add a flag to the vertex program definition which will be used to indicate that the vertex program performs skinning, which makes the software skinning calculation not happen (except for shadows; this is a bit of duplication of effort since the CPU will be calculating the skinning for the shadow, and the vertex program will also be doing it for the visuals, but the fact that you can keep the vertex buffer static makes it worthwhile).

The other thing I’m going to do is instantiate a copy of the skeleton per entity, which I haven’t done in the past to try to keep memory requirements down, but after a year of doing it this way I’m convinced now that a copy is worthwhile. This is especially true when you want to manually control the bones, which is hard when the skeleton is shared the way it is now. This is very relevant at this time because there are now no fewer than 3 ragdoll implementations using OGRE, and they will be much simpler to hook up to skeletons if they are not shared. EZPhysics has already linked up the skeleton, but the demos only use one entity so this is probably why.

Anyway, at least I have a good plan for efficiently dealing with animated characters and shadows, albeit via a bunch of other changes including adding vertex program skinning and rejigging the skeleton structures. I’ll post more in a few days when I should have some results.