Making better use of Ogre's capbilities?

[Chris]

Might be an issue with the bone mapping.

Yes...

void Ogre::Entity::shareSkeletonInstanceWith(Entity *entity)

Shares the SkeletonInstance with the supplied entity.

Note that in order for this to work, both entities must have the same Skeleton.

Seems the mesh needs to have the same Skeleton to be properly shared, which makes sense in hind-sight... an object that contains a sub-set of the bones (like a piece of armor) can't just be shared with the main entity's skeleton, since there's no way to know which bones the armor piece should animate with on the main body. Neither the name or handle are good for matching the two. The armor/part meshes need to be given the same skeleton.

This would mean that attachObjectToBone would be superior for unskinned meshes (or meshes that are completely weighted to a single bone) since there's no need to muck about with matching skeletons. Just attach to the named bone and off it goes.

For skinned meshes, though, this would mean a tiny bit of extra work. Each skinned mesh that can be attached to an NPC would need to be created twice, once using the normal skeleton and again for the beast skeleton. What I'd imagine here is: when a skinned NPC part mesh is needed, it would load the NIF mesh(es) according to whether it's a beast or non-beast NPC (with the mesh name having an identifier appended to it to differentiate the two). Then after the mesh is created, it's given the skeleton name accordingly.

After that, when the mesh(es) are loaded it will automatically build bone assignments using the appropriate handles given the bone names in the nif's skindata, for it to be shared with the main entity.

Luckily the overhead here will be relatively small, since the actual mesh data is loaded as needed and can be removed automatically when it's no longer being used by anything in the scene. Only one copy of the mesh would need to be loaded unless both beast and non-beast versions are used in the same scene, otherwise Ogre will unload unused meshes when the resource size limit is exceeded. And even then, it's only the vertex data... the textures, materials, and shaders will be shared.

[jhooks1]

I managed to get the animations running without sharing skeletons, still have the same problems with robes and skirts though.

[jhooks1]

Ok I think now that our weighting formula
(mat*vertexPosOriginal[verIndex]) * ind.weight; is what is causing the problems with robes/skirts. I ran a test (which I will commit soon) where I am applying only one matrix4 transformation, and robes/skirts look better for the most part. Need to see if I can find a strategy that incorporates all weightings correctly.

[jhooks1]

I am not able to figure out a strategy to get robes, skirts, and ancestor ghosts to look correct. I think we are just going to have to wait until someone more knowledgeable with ogre and animations comes along.

[jhooks1]

To get ogre animation working correctly I think we may have to modify some of ogre's source code.

[Zini]

Absolutely not a favour of that. If we absolutely must, then we should try to improve OGRE's extensibility/flexibility for our needs and then get the changes into the OGRE project. Carrying around a modified copy of a large and quickly evolving library sounds like a sure recipe for disaster.

[Chris]

To get ogre animation working correctly I think we may have to modify some of ogre's source code.

What for? As far as I can tell, Ogre's animation system can do what we need it to do. It's just a matter of modifying the data from the nif/kf into something Ogre understands, building the animation sets based on the metadata in the NIF, and having the controls in place to set what animation sets are active based on the actor state.

The big problem right now is just getting the meshes and bones to line up before they're loaded into Ogre, and for the animation to set the bones in a way similar to MW. I see no reason why this can't be done, it just needs someone who's more experienced with NIFs and how Ogre works.


But even still, the worst case is that we control the bones ourselves. The savings will come from getting Ogre to do the skinning for us (particularly in hardware).

[jhooks1]

Many vertices have more than one initial transformation (Matrix4) in NIFs. In ogre we have one initial position per vertex, was thinking this could be the cause of the robe/skirt/ancestor ghost problem. If we could process each one of these transformations separately, then add the results together into one final vertex may fix the problem, just an idea (dunno if it would work).

[Chris]

Many vertices have more than one initial transformation (Matrix4) in NIFs.

Not sure what you mean. The initial positions are defined in the trishape, which may be offset by a parent node. The trick is to get it so the mesh's vertices and the skeleton's bones are based around the same origin, so when the bones are animated the vertices are correctly moved with them.

Unfortunately NIFs are obtuse about this, putting the vertices in a bind pose while the skeleton is in an initial pose. For skinned trishapes you have the bind-pose-to-skeleton-root transformation in the skinning data. Apply that to the vertices, then the vertices and bones can be easily matched up with the same origin. Vertices for unskinned trishapes are already defined around origin, as they're relative to their parent node, so no transformation should be necessary.

[jhooks1]

To get ogre animation working correctly I think we may have to modify some of ogre's source code.

Never really explained well why I thought this way, so here goes:

We are using this line of code (from Chris's project) to define vertices : newVerts[index] += (mat*srcVerts[index]) * weight;
Where mat is a transformation, srcVerts is the original vertices' position, weight is a weight. By going through this process we get a new vertex position for each vertex, newVerts[index].
This works for many creatures and npc parts, but for others it makes what I would call holes or distortions (which I noticed in robes, skirts, and ancestor ghosts).

I believe the proper way to handle npc parts/creatures would be to have a separate new initial vertex for each transformation. So if a vertex has four transformations associated with it it processes each transformation separately, rather than mixing them together before into one position then going through one process.

I did try just using one transformation (I believe I did newVerts[index] = mat * srcVerts, it was a while back) on a few robes and skirts, and not factoring in the other transformations. Things looked better, but still not perfect.

But even still, the worst case is that we control the bones ourselves. The savings will come from getting Ogre to do the skinning for us (particularly in hardware).

I believe in our case we have a skinning problem, the bones are in the right positions.


I would like to ask mark76 if he has any ideas on fixing this distortion problem with ogre's animation system. Or even a fast custom way to do efficient skinning and animating. Did crystal scrolls use Crystal Space's animation system, or a custom system?

Mark most likely knows more about NIF and animations than I. Looks like he is busy with esm/esp support though.



I wish ogre could read and handle NIFs natively. I doubt the Morrowind devs had to ever deal with animation problems. The gamebryo engine probably supported NIF animation with hardware skinning right out of the box, with no worries.