Posts tagged ‘Quaternions’
As I’m currently in the process of skinning many meshes for the current game I’m working on here are some rules I’ve learnt on the way:
 Don’t attempt to skin spherical deformation without having bones for deformation or quaternion based skinning methods. Key places where this must happen is the shoulders, thighs, elbows, knees, wrists and ankles.
 You don’t need lots of twist bones, three including the actual bone is enough e.g shoulder *deformer bone, main twist (100% to upper arm with a direction pointing to the deformer bone), 50% twist bone, 0% twist (100% to the upper arm)
*By deformer bone i mean a tweak bone/point, etc has average deformations between the shoulder and upper arm. Similar to elbow or wrist deformer bones.
 Don’t model the wrist/hand attached to the sleeve, tuck it inside and treat it as an element. The same applies to the ankle/foot and trouser leg.
 If you don’t see the underside of a mesh, don’t model it, cap it off. A good example of this is a skirt.
 The deformation of the wrist is not the same as the elbow or shoulder; the shoulder can be considered a one dimensional quaternion – in this i mean its twist is dictated by its direction. The wrist could be considered two dimension as the first quaternions direction dictates the rotation space (one plane) for the second quaternion to ride on. The wrist bone dictating the direction for the hand to ride on, as oppose to the upper arm bones direction dictating the entire deformation of the shoulder.
Just a quick theoretical idea – I’ve been thinking that a rotation is basically the reflection or product of a direction indirectly or directly controlled by its spin. This seems simple to understand in theory but in practice its more complex. Im coming to terms that rotation is really an illusion of a direction or a side product.
Thinking about this more in my notes, we can hypothesize that if a rotation is really just a direction, then we can seperate it into two parts: the direction and the spin and more importantly have direction controlled by anything, namely the tangent of a spline or curve. This seems amazingly simple now, the curviture of a spline dictating the direction of a quaternion about a hemisphere. But detaching yourself to thinking this way is really hard.
In this way we can treat the wrist and spine articulation the same – the spin (or twist in the conventional sence) is just used to dictate the direction of the system, with a spine you’d use the tangent of the curve itself, with the wrist the hand is the direction.
I don’t know if this is new but I’m calling it double strung quaternions (DSQ). Its a method to reinforce a rotation relative to a transform space. In lamens terms it trys to make rotations true to our way of seeing them in a control. I’ve been looking into ik spine systems and hopefully this maybe a way towards helping out with rotation issues. Here’s a demo using z as its direction.
(click on the above image to view it the demonstration)
Bugs im noticing are that it uses linear distances to work our the quernions, quatDrivers as I call them (they can infact drive any value with distances) – i get some slight wobblying, but i think this can be cured using a valuespace normalisation method like so:

a = 10, b = 20

summation = 30

norm a = .33 norm b = .66

multiplication by the norm gives a = 3.33r and b = 13.66r
This is a derived final value which might yeild better results. The whole system is enclosable and useable across a variety of articulation problems.
So I’ve been looking into using quats to simulate joint rotation and deformation. What I’ve found out is that most joints of a human can fall into two systems: single and double quaternion systems. If a bone system doesn’t twist using its bone like the forearm then it can fall into a single quat system, which dictates just a direction , resolution of the twist happens naturally when two perpendicular axis’ come together at 90 degrees.
If a system has a twist dictated by bones in conjunction with muscle deformation, then one quaternion is needed to dictate the twist space the second ‘deformation’ quat rides on. With this we can say that twist is not only dictated by the resolution of the system it exists in, but by the spin this system dictates. The order of which system drives each space is important.
A simple problem, with your arm out tpose palm flat (facing down) do this:
 Rotate you arm down to the side, then forward (You’ll notice the bicep faces up)
 Now go back to your arm out. Rotate it forward (the bicep will face to the right or left now)
We have an oddity here, and I think it’s one of the founding principles of biomechanical rotation, it ‘resolves’ itself. When two rotations meet the union causes another plane of freedom to be introduced – i.e the top of the bicep will twist 45 degrees with your arm going forward and 45 going backwards. Looking at this from a math perspective its spherical rotation. (a quaternion)This spherical rotation similar to a quaternion is what stops the arm from twisting itself off its joint. The muscles are are treating its ball and socket joint as a spherical rotation or in other words a quaternion. Now this may not seem interesting but this is before there’s been any rotation of the elbow.I.e the twist of the upper arms is brought on by the constant rotation of the shoulder and its resolution or twist, is brought on by the rotation of the elbow. This is why it can be hard to get a frame of reference for the twist. I’ll see if i can update this with some pics.
I’ve been looking into double quaternions and the belttrick. The trick also known as the ‘waiter trick’ allows a rotation with respect to axis order, to rotate from 360 to 360 – full 720 degrees of twist. This alone wont work in a rig and needs additional support for the identity matrix and a feasable way to produce (t) the tracking value along the surface of the hypersphere, between each frame (frenet).
Possible ways to achieve the (t) value of the Dirac algorithm is to use a simple slider from a range of 0 – 2Pi. This is a simple solution but takes away controllability to the animator – essentially we need to derive the value from the controls themselves.
Ive been looking into fourier waves and the sawtooth wave, its amplitude and frequency can both be accurately achieved with the phase offset being directly linked to the (t) of the belt trick.
Passing the output of the belttrick is a simple process of converting the quat to eulerangles. But deriving the t value is a lot more tricker, due mainly to the hemispherical problem of quaternions. A quaternion [v,w] is a vector and a twist on the surface of two 4d hemispheres, where abouts a transform travels across the hemispheres is Slerp.
What can happen is that if the vector crosses the equator of the hemispheres a 180 degree flip can happen – this is entirely correct but tricky to send to a fn as it keeps flipping. If we take the transform of two objects ‘a’ and ‘b’ with us storing the transform of ‘a’ relatively to ‘b’ as a script_function we can get the constantly updating angle of the transform.
But once we hit 180 degree’s it’ll flip and the transform will reverse – one way to fix this is to reset the transform space when we pass 180. Essentially resetting the rotation of of the transform: 0 180, 0180 – a sawtooth wave. A problem with this is rotating backwards.
We need a way of dialing up the transform space rotation, up and down and then feed this in the quat fn.
A lot of people are confused by this, and in one sence its the software duping the user into thinking that there rotation, be it local or world is what it actually is. Rotations arent angles there either a collection of vectors from an origin or a vector and a twist as in angle axis or a quaternion – quaternions are slightly different in that they have two sets – imaginary in 4 dimensions and referenced in 3 dimensions. The twist i.e w of I, J, and K is part of the algorithm and cant be torn away.
The matrix is the easiest way to understand, imagine a graph in three dimensions 3 arrows one down the x, one down the y and one down the z. Now you derive three vectors, three points on the graph for each axis.
Now the length of the line from the origin [0,0,0] to each vector is the unit length, and by adding them all up should equal 1 – this is important and is also known as normalisation. Why is normalisation important well first off scale and rotation are linked in a matrix, scale I regard is a happy result of rotation. The normalised unit length being 1 means a scale of 100% 0.5 = 50% and so on – you can still get nonuniform scaling.
Now another import part is each vector, they have to be 90 degree from each other. Else what happens – well you get sheering, because scale is a result.
So in essence your defining an axis for the rotation, with three vectors from the origin like so:
([1,0,0], [0,1,0], [0,0,1] [0,0,0]) – the first three are you vectors to build your rotation, the last is position. Position is simple its just an offset from the origin.
Now another factor is the parent – transformations are relative to the parent. So if theres no parent then [0,0,0] position would be world center. Where as if it had a parent, [0,0,0] would be the parents pivot.
Euler is a bad way of representing rotations, because its really a system to make each vector x y z. Gimbal lock occurs because an axis after being evaluated, doesnt reevaluate itself when the next is rotation. So when you rotate x 90, then y 90. Y is adding x – and so on and so forth. It means that once you get to z, your rotating x too because x has been rolled onto two axis.
One way to solve this is to project the axis into quaternions and reevaluate the axis everytime you rotate it.