# Posts tagged ‘Rotations’

Never really needed to do this, but if you try to scale a rotation as a quaternion all you do is scale it’s axis’. The only way I know of is summation:

```( local rot = (eulerAngles 0 45 0) as quat local sum = quat 0 0 0 1 local scl = 2.5 ```

``` for i = 1 to floor(scl) do ( sum += rot )```

``` sum += slerp (quat 0 0 0 1) rot (mod floor(scl) scl) )```

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.
I’ll discuss more on the differences of the wrist compared to the shoulder in later posts.

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 value-space normalisation method like so:

1. a = 10, b = 20
2. summation = 30
3. norm a = .33 norm b = .66
4. 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 t-pose palm flat (facing down) do this:

1. Rotate you arm down to the side, then forward (You’ll notice the bicep faces up)
2. 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.

Heres a list of what I’ve found should be in a rig. It’s from studying generalized rigs and demos, Building them, and most of all asking the animators I work with every day.

• Main torso control with keyable pivot
• Independant pelvis control
• Independant chest control
• Head control with keyable rotation space (local/world) and keyable pivot.
• FK/IK  arms with keyable rotation space (local/world) in FK mode.
• FK/IK legs with keyable rotation space (local/world) in FK mode and keyable foot pivot in IK mode – additional support for quick pivot places (gui based).

On top of this, you could add stretching, breakable limbs, pinnable arms legs etc – but this is the bare bones rig.

Edit: The keyable head space pivot is an idea inspired by  Jason Schleifer’s, Animator friendly rigging. Go check out his site here. And Bernard’s utterly stunning softimage reel over here. – sorry if there was any confusing, if people thought it was my idea.

I posted this at cgtalk

Has anyone though of using VCK with a transposed arc length method to get rotations about the elbow? Basically VCK ‘vector coupled ik’ is an ik chain driven by the vector magnitude to positioning the goal whilst having standard rotation for general fk, it basically allows you to break the ik and add nice arcs to the animation – the problem i see with it is you cant drive about the elbow. But what if we use a transposed arch length method, which would ontop drive the general rotation and the magnitude we could get rotation about the elbow- this could even have its own fk controller driving additively over the top i think -you need just a few variables such as bone length, as you drive it as an additive to the main control i.e a layer over the top.

I now must go to bed.

Im looking into areas that can essentially be shared  – modular continuity between arms/legs etc on biped and quadrapedal rigs (even bird rigs). Its opened up some interesting ideas namely to first break the lower arm in half and some oddities in the foot.

Breaking the lower arm in half basically allows for a front arm to act like a front leg of a quadrapedal – why is this important well for one thing it allows a quadraped to act like a biped and vice versa. It doesnt mean you would nessesarily use it in a biped rig, but its a simple additional that allows for the control.

For the foot rig – ive seemed to find a stumbling block namely where the control of the foot goes? In human locomotion the pivot exists at the heel, but when its on the ground its at the ball. The problem is even more compounded in that we both swivel and hinge about the heel – hinging is a simple heel<>ball setup, but swivel is more of a problem. Do we change the transform space of the main control if its at the ball or add an additional layered control?

The problem is exactly the same and virtually opposite if the main control is the ankle, you get heel and swivel control but ball of foot swivel is lost.  Its not truely lost, you could drive its z rotation of the roll controls z rotation but, as where dealing with ik system our trigonometry plane space would freak out and the foot as a whole would twist – the old gimbal problem looming as two rotations overlap each other.

Probably the most important aspect of rigging, infact what we can sum rigging up is relativity – everything relies on. If its the mesh its relative to a skin, the to the bones and the bones to a rig. And even at the finite level the controls of the rig are relative to a other controls – they exist in a space of there own but are relative to something else even if this is the world.

Rigging is relativity and reference – its a bold statement but is the basis for everything needed. Everytime you parent or constrain an object to another you set its relativity and its reference. The key to rigging is a system where both dont fight but work hand in hand with one another. A good example is the spine – the animator wants control of the hip, chest and head. But also wants control of the torso (everything) – they also dont want counterotation and the ability to hold a pose.

Its a lot of systems but if we boil it down to relativity and reference its relatively (pardon the pun) straight forward. The hips are parented to the torso – so we have defined a refence: the torso and a relavity (torso-hip) to work in. The chest is parented to the torso, the same applies here. But the head is different the neck is really a part of the spine and really moves with the chest, but the problem comes in that we want it to move with the head when needed.

So we define 2 references – firstly we set the heads position relative to the chest, but its rotation to the torso. This means when we rotate the chest the head moves with it but crucial stays pointing at a target. But additional if we move the head the neck will follow – this is via an ik system or lookat/pole vector – simple stuff.

So when building a rig really understand whats relative to what, and understand the methods and math of space.

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 non-uniform 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 re-evaluate 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 re-evaluate the axis everytime you rotate it.