Making better use of Ogre's capbilities?

[ElderTroll]

Did you try posting a concise explanation of the problem in Ogre's help forum? It might be worth a shot.

[natirips]

newVerts[index] += (mat*srcVerts[index]) * weight;

I haven't got a faintest clue about the workings of Ogre, but the logic behind multiplying a coordinate offset (if I'm getting it right and newVerts[] are coordinates) by weight is strange.

This way, heavier stuff moves more, lighter stuff moves less. As much as I hate division in computing, shouldn't it be

Code: Select all

newVerts[index] += (mat*srcVerts[index]) / weight;

?

[Chris]

I haven't got a faintest clue about the workings of Ogre, but the logic behind multiplying a coordinate offset (if I'm getting it right and newVerts[] are coordinates) by weight is strange.

This way, heavier stuff moves more, lighter stuff moves less. As much as I hate division in computing, shouldn't it be

Code: Select all

newVerts[index] += (mat*srcVerts[index]) / weight;

?

Dividing isn't right, because the matrix that belongs to the bone may only partially contribute to the vertex's position. There can be other bones that also affect the vertex, and adding the weight from all the other bones that affect the vertex should result in 1. If you divide, then multiple bone matrices would move the vertex farther (weight of 0.5 would scale the result of (mat*srcVerts[index]) by two for the given matrix).

But it's also possible (mat*srcVerts[index]) * weight isn't completely correct either, though it does produce nearly-correct results in some cases.

I'll probably need to take this back to the drawing board. I actually have some code that deals with loading MD5 meshes which also uses bones with weighted vertices. I have no idea how relevant it would be for nifs, but I'll try to play around with it to see what I can get.

[natirips]

Ah, I thought weight was as in kg/lbs.

[jhooks1]

I should show what the problem looks like.

Here is the ancestor ghost.
Notice on the right arm the distortion, it looks like triangle pieces.

http://oi46.tinypic.com/2zsacde.jpg

The robe

http://oi50.tinypic.com/mw2is3.jpg

Both of these are using newVerts[index] += (mat*srcVerts[index]) * weight;


Here is one of the robe, using only one transformation:

http://oi45.tinypic.com/5p0l4x.jpg
Notice it looks a lot better, but still not perfect. It is hard to tell but there is a small crack of empty space right above the belt that shows through while running the animation. Using only one transformation doesn't seem to help the ancestor ghost.

EDIT: While inefficient, the custom animation system that we are using in master (.12, .13, .14, .15) looks flawless on just about everything. I think the reason it looks so good is all transformations are stored separately (not mixed together before doing any animation), with each frame handleShapes() applies each vertex's multiple transformations separately .

[Chris]

I'm about 99% sure the vertices are being transformed correctly using

Code: Select all

newVerts[index] += (mat*srcVerts[index]) * weight;

If I set the matrix to the combination of the NiSkinData's bone transform and the bone's world transform, the vertices come out 100% correct. i.e., if I use NifLib and do:

Code: Select all

mat = data->GetBoneTransform(b) * bones[b]->GetWorldTransform();

then the mesh fits perfectly with the bone pose (multiplying matrices has the same effect as applying one matrix after the other to the vertex the result is applied to)... as long as the bones themselves are left at identity and never moved.

I don't really understand why transforming the vertices to be as if the bones were at identity, then letting Ogre transform the bones away from identity to whatever position they should be in, doesn't quite work. If I do the transformations before loading the mesh into Ogre and don't move the bones, they're positioned correctly.

I could get a better idea about what's going wrong if I could match up the mesh and skeleton in a pose that I know is correct (by either moving the skeleton into the binding pose, or moving the mesh into the skeleton's initial pose), and animate the bones from there. But NIF animations specify bone transformations for animating from origin, and I haven't successfully gotten the animations to base off of a different skeleton form (closest I've got had the bone transformations over-compensating, like this).

The problem I'm running into there is that Ogre's not differentiating between the skeleton's binding pose (the bone positions that line up with the mesh's vertex positions) and its initial state (the bone positions from which the animations are offset from). The Ogre docs make no mention of the two being dependent on each other in any way, yet it acts as though they're the same... whichever I set last "wins".

[jhooks1]

The weird thing is, the ogre animation setup seems to work for most npc parts and creatures (about 75% correct). Right now it's either we keep our current animation system which looks great on everything but is inefficient, or we switch to the ogre animation solution which is extremely efficient - but doesn't look right on 25% of creatures/parts.

If we can bring it up to 100% or close the ogre animation solution would be definitely the way to go.

[Chris]

Just after I say that...

Here's my NIF loader code: http://pastebin.com/gmetuinH

[jhooks1]

You got it working? Can you try an ancestor ghost? What all is different in this code in comparison to your last release? Is it just the Matrix44 mat = data->GetBoneTransform(b) * bones->GetWorldTransform();

[Necrod]

Good job, hope it will be ready for 0.16