Quote:Original post by AndyTX
Thus I still count interpolation as one of the primary advantages of quaternions.

Though after doing the whole skeletal animation things with quaternions and comparing it to how I would do it without them the advantage is nice, but far from crucial.

I'll be going even further off topic here. A common thing seems to be to multiply a vertex with two matrices, then weigh the results and sum them up. Everybody knows that interpolating the matrices would screw them up, but not so many realize that it is still mathematically exactly the same. So the same square root used to renormalize a quaternion after interpolating it could be used to stretch the resulting vector to its original length. The result should be same: path is fine, velocity is wrong. Only angles close to 180° would be a problem. Hence I somewhere posted that quats should be more robust. Spherical interpolation is already involving a good bit of trig, so the extra cross and dot products for the vector based interpolation look a bit more harmless.

If you know you will be doing a lot per frame that's faster with quats and only convert once that would be the best case. Else wrapping your head around quats would have no benefit except for having learned something new.

Quote:
Quaternion multiplation (composed rotation) is effectively four dot products with a few negations (depending on your internal representation). No cross products necessary...

Because it's not showing when you "spell it out" for the function. It's already mixed in and where all the negations are coming from.

Quote:Incidentally the formula for building a rotation matrix around an arbitrary axis is exactly the formula for converting a quaternion to a rotation matrix.

True, but in the same way rotating a vector around a quaternion ends up as exactly the same as converting to a matrix and using that (meaning you don't use the existing quat multiplication, but write them as one). The difference above is more about finding the axis in the first place, though there should be a more efficient way than calculating the transformed vector for both and do the cross product. Skimming over the formula to extract the axis directly from a matrix doesn't look so tempting. Might be missing a shortcut though. Risky and lame trick would be to so save some work by always rotating (1,0,0) and praying that it doesn't happen to lie on the axis (or repeat for (0,1,0) and compare results, but here it starts to become really pointless.

Quote:Unrelated, but not with Sh (http://libsh.org) ;)

Might have to have a look at that. But with different numbers per vertex in a single batch I can't see a technical solution that doesn't involve the newest cards with real loops and branching.

Though in that case, quaternions would at least allow to store more bones in the registers. Some extra code to decide if they should be converted or not and which shader to use based on the number of bones/registers shouldn't hurt too much.

The main reason I'm sticking with them for now is this whole "but what if I want really complex skeletons, better be prepared for everything"-feeling. That and having to store inverse bind pose, relative transformation to parent and final transformation used on vertices. Storing multiple positions for vertices AND losing the option to interpolate quats/matrices instead of transformation results sounds like it's worth some overly bloated bone structs.