^Well as it happens I was just preparing an illustration...

I hope we can get more people looking in here BTW. This is an interesting problem I think; and if I had to bet I would say it won't boil down to a screw being loose in the code somewhere.

Anyway here is a few images (don't mind the URL, the FTP client wasn't finished changing directories when I uploaded)



The first (on the left) is the normal animation. The red lines are a visulization of the "skeleton" ... as you can see it's not a traditional skeleton. My thinking is the nodes are basically pivots that pull each piece down to (0,0,0) then put it back. But regardless that's not something the solution can assume since that is pretty much up to the artists/toolchain. BTW: Ignore the fact that our subject just happens to himself be a skeleton!!

The second image is with our inverse transforms being applied by themselves. In this image the underlying vertices have been switched around so that they look more or less like in the first image (striking a more lively pose than the artist's bind pose) but with the animation applied the vertices assume the original bind pose.

The last image is with the transforms from image 1 and 2 combined (same code as that above). As you can see the skeleton flattens out more or less. The skeleton seems to be exaggerated along the Z axis (the direction the subject is facing) but I don't think this is indicative of any screw being loose, and neither do I necessarily think its safe to assume that the flattening is due to superimposition of the two, it could in other words just be by chance, if the axes are rotated out of whack.

Edited: from a frontal vantage point you can witness other inconsistencies. Things moving in the wrong directions etc. It is not simply in other words something about one of the axes being misinterpreted somewhere in the mix.


I've been trying to study the skeletons in search of an epiphany just now, but nothing is really clicking for me. A veteran of such things might see more in these screenshots.

It seems to me that if the code was at any point incorrect the middle image would be wrong, unless it just happened to be virtually unscathed by a hypothetical wrench in the works. The code for the most part has all been widely tested in the field. And the new bits I've setup countless paranoid scenarios for that have all checked out.

Hmmmmmmmmmmmmmmm:

It kinda seems to me at this point like the second quaternion in the mix needs to be moved into the new coordinate space defined by the first quaternion. I expressed this wonderment before early on. But I am not really sure how to do that.


For example, compare the way 3D rotation happens with this link (http://www.swordofmoonlight.net/canvas.php) [Firefox or Google's Chrome browser is required] ... it feels very intuitive because the up/down rotation is relative to the left/right rotation. If it was absolute (X*Y rotation matrix) then the thing would only feel right from one or two angles (the others would swing back and forth sideways)

The way you get it to do that is you take the X axis and rotate it by the (inverse of) X rotation, and then have that be the axis for the Y rotation. Then combine the two matrices (X*Y).


Just don't know how to go about that in this case. Just feels like intuitively the animation quaternion (or rather the rotation quaternion/position vector system) needs to be moved into the original space that it occupied relative to the vertices being animated first (and only then could be it be combined via the code above)

I don't seem to be one to be able to let an open problem lie. I've found sketching things out on paper to be of some help (I draw pictures rather than crunch numbers for the most part)

I am "pretty" confident the rotation component should always be correct in my thinking; though I am a little confused about the order thanks this to this find:

[quote=http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/quaternions/transforms/index.htm]
The order worked out above assumes that each rotation, q1 and then q2 is done in the absolute frame of reference so we get q2*q1. When we are working in the frame of reference of a moving object such as an aircraft or spacecraft then the order is not reversed so the combined rotation is q1*q2.

absolute frame of reference
q2*q1

frame of reference of rotating object
q1*q2
[/quote]

I find it odd that the order should matter in different contexts myself. But I can't tell if by absolute he (assuming) means within the same reference frame (vs. across frames) or in some magical outer most frame.

I discovered that most if not all of the oddness in picture #3 above is actually built into this model, and can be observed if translation is taken out of the model. So a picture like #3 will happen naturally whenever there is not enough translation (the position component) correcting things.

I will most likely anyway, keep trying to work this out, on paper, another day. If it is true that only the position component must be solved for then it should not be too unwieldy a problem (let's hope)

The link for the above quote is (http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/quaternions/transforms/index.htm) ... did not appear in the quote citation.

For the record, this morning, I devised a solution that worked with 3 diagrams. The approach I ended up taking was canceling out the translation due to rotation, and then the remaining translation is pretty straightforward ... but what I found was the results were identical to having the second rotation+position pair drive the product of the two (basically q2*q1 from the quote above) ... which I found counter intuitive, and would not have suspected, but it works.

I am pretty comfortable with the dynamics, but it is still not working out. So rather than trying to prove that solving for the spaces between the reference frames (the relative frames) does or doesn't introduce the error, I reckon I will go ahead and slap together a global solution (one that computes the sum of the transform chains, combines the results, then chops up/portions out the results in relative terms) ASAP and just see.

Sweet success! A week worth of work down the drain, but nonetheless feels good to not have been totally for naught.

Long story short, the global solution plan went off without a hitch. I think I learned some stuff though. I just wish I could remember what order to multiply matrices etc in.... it's just too easy to try one way, and then the other if that does not take

All these years programming graphics, I still don't know.

PS: Would like to edit the subject to be "SOLVED" and provide a solution... wish I could think of a title that made sense. But the "Full Editor" link isn't working right now in two different browsers (one with no cache for this site) so no clue. Will try again later.