Hey Charles.

I haven't made any further progress on this, mostly because the system isn't vital until my artist actually comes up with some morphed models.

Your system sounds very impressive. I do the animation in the shader, and the limit is still a back-of-mind worry, but I haven't pressed any further with it so I figure I'll deal with it when I have to. How do you generate and export/import your animation? My system allows the artist to do this in 3ds MAX, which is handy.

I'm not exactly at a release stage yet, but I plan to get it there when I've got a pressing reason to work on it. I'd love to compare notes, too.

Also, have you combined it with skinned animation at all?

We do the models and morphing meshes in 3DS Max and export in FBX as usual.  Since the importer does not import the morph modifiers, we simply name the meshes appropriately so our content processor can detect them when we load.  As an example, we might have a face mesh and four emotion meshes for smile, frown, anger, sad.  The face mesh will be named:  Morph Target Face in 3DS Max.  Each of the morphing meshes will be, in turn named:  Morph Face smile, Morph Face frown, Morph Face anger, Morph Face sad.  We set up the normal Morph modifier in 3DS Max and create animations.  We export the animations as XAF files.  We have a custom importer and processor for XAF files that detects the animations for the morph modifier and renamed them so they apply to the correct avar. 

The biggest thing we've learned in XNA is that you can pass a lot of information from 3DS Max or Maya to XNA in the naming convention you use.  We use this to pass collision zones, camera zones, cameras, hotspots, doors, and all kinds of other things. 

I have combined the morph with the skinned animation, be we don't in the any of the models in our game.  Since the only things we morph are faces, we cut the face from the body mesh and just make it a child of the head bone.  This keeps the number of morphed vertices relatively small.  (We are also morphing another specific part of the male anatomy, but, that's a different story).  We do the morphing on the processor side rather than the shader, so there's not really an issue to combine them. 

This is probably way too late but I thought I would stick my idea down here in case it is of use to anyone.

Store the morph targets as textures.

It would be fairly easy to use the fbx api to extract the morph targets from a file and store them as textures.

Then export the base mesh and import it into XNA as a model.

In HLSL you could take the base mesh and any number of textures and mix them in the vertex shader. So you could have 10% happy, 25% sad, 55% angry, 10% frown.

Just an idea, but I know it works as I did almost the same thing a few years ago to animate a talking 3d head using a text to speech system as the input.

Why use totally unsupported morph targets when bones are supported? Its more work up front but a face can be rigged for every phoneme.   Then do bone blending in code.

Speed.

Doing all the morphing in a vertex shader is a lot faster than doing it on the cpu in c#, especially when you want to mix several morph targets.

Charles: That sounds like a smart way of doing things, particulary exporting the animations as XAF files. My system is a little different (okay, heck, it's a lot different) in that the morph meshes aren't actually recognisable meshes, they're a series of delta-positions (positions representing the distance each vertex moves when morphed). This, along with the animation data, is extracted directly from the FBX file during an intermediate step (between exporting from MAX and importing to XNA).

I love the idea of making the face a seperate rigid object attached to the head-bone: it makes way more sense than trying to build a combination skin-morph system (given that I'm morphing in the shader, it's more of an issue for me than you), and as you said keeps the # of morphed vertices down.

I'm kind of regretting the delta-position choise at the moment, because apparently exporting to FBX doesn't maintain normal-morphs, which may affect lighting (my vertex positions will be morphed, but my normals will not, and I don't know any way to re-generate them). I don't yet know if this will be hugely apparent or if I can afford to write it off.

Stainless: That's not a bad idea. A texture would be an excellent way to import large quantities of morph data without hurting the # of shader constants, and you could even mix them in XNA before bringing them into HLSL. Hmm... [mind working]

Gregoroamin: Well, I was going to say because I've got an artist who refuses point blank to use bones for facial animation, because morph targets are a whole world easier. But Stainless has a point: direct vertex manipuilation is a much faster option than using a load of different face bones.

Honestly I had it working on an iPaq, the trick is getting the textures from your art package in a painless way. After that it's trivial.

I was lucky, the application took a photo of a person (taken by a digital camara attached to the iPaq) emailed it to a company in the US that returned a 3D mesh in a standard format.

The 3D mesh was morphed to match the photo, so you got a 3d mesh of the target.

Since it was in a standard format, I could build the expression textures before hand and just apply them to the mesh.

It was very easy, but very impressive.