Proper Interpolation

Topics: Developer Forum, User Forum
Sep 9, 2007 at 4:00 AM
First, thanks for actually making this code available. It shows signs of having significant effort put into it.

However, there are a few design problems with the code that makes using the code harder than it needs to be, and that creates unnecessary limitations at runtime. Here are the top three I've run into:

  1. The library uses matrices, instead of quat/pos/scale values, for posing. This has three sub problems:
    1. Interpolating between matrices causes vertex collapse, just like if you interpolated between two meshes in good-old Quake 2 style. If you want to play animations in slow motion, you will have to interpolate.
    2. The storage requirements for matrix poses at 60 Hz are quite significant. Storing only translation, orientation (as quaternion) and scale, and only for keyframes, is a lot more compact. When you're using long animations, this is a deal breaker.
    3. With 4x4 matrices, you can only get 40 (or 56) bones to the card. By using 4x3 matrices, you could get a little more (53 and 74 for PC). By using a quaternion and a position, with a uniform scale factor in w, you can get to 80 bones on Xbox and 112 for PC, using the same amount of constant registers.
  2. The library seems built to require code changes for any customization. There could be more variation points in the code to allow overriding or re-use.
    1. For example, getting the "world" and "matrix" parameters from the effect could easily be factored into a virtual method, or into a separate interface.
  3. The library uses a very different approach to effects and parameters than many existing code bases -- and the library is less efficient in that way.
    1. One example is the common practice of sending down worldViewProjection as a single parameter to a shader -- right now, the drawing library has no variation point to let you calculate that value for each new world matrix.
    2. Another example is getting the posed data of a skinned animation -- if you render using your own code, you will have to duplicate about one-half of the drawing code (which deals with posing), while not running the other half of the drawing code (having to do with rendering). This is extra annoying if you use a single effect instance and just vary effect parameter values, instead of using a new effect clone per ModelMeshPart.

Maybe you could look at some of these issues in the next version?

At this point, I'm trying to decide whether to use the current code (which is there, and I don't have to write it!), or whether to break down and change it to do the above things -- that change wouldn't be compatible with the current API and usage scenario, though, so it couldn't be easily merged back. In general, I find the GameComponent concept to be mostly useless for things more complex than an FPS counter. A real scene graph needs a much richer interface, and a lower-weight containment mechanism. But that's another discussion :-)