# Posts tagged ‘Transform Spaces’

Maybe I was a little hasty. Crucially when it comes to keys, animators need to know the reference a value exists in – and that, it shouldn’t change.  For example if I animate a guy jumping from one platform to another – the curves of the jumping, moving from and to the platforms shouldn’t pop erratically to allow its reference space to change. More over the the space the values are relative to should be transformed.

Offsets

The offset is a great mechanism for retaining space – it wouldn’t be a good mechanism for FK/IK systems because your trying to force the IK/FK into its opposite – i.e you want its value to change. Can we form a rule here?  When you want the value to change directly transform the object, when you want to retain the value transform the objects parent space.

But..

You still need to allow this approach to be understood by the animator. The offset needs to be understandable, accessible and crucially clean-able!. Any system  that transforms an object by an offset will encounter pops and hitches if the keys of the offset change, get moved or deleted. (Another reason to place them in there own area – attributes etc)

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.

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.

I tend to think in small chunks – I break down an idea, work out each part and then put it back together hopefully. I’m trying to use this approach with dynamics – I’m looking into a simple system to handle a variety of situations. Currently I’m thinking of simple spherical detection. This method use just a diameter from a point – its a simple system, but it might be scalable for more complexity.

Dynamics I find very hard to get to grips with, I have to take it very very slowly. Just understanding derivatives is hard, as its the function of the equation. Its also very fragile as a system – finite tweaks make big changes, especially in complex systems. My aim is to build simple systems that can be ‘bolted’ together right across the board from dynamics, to transformation stuff. Its sort of the middle man of rigging. I’m not the string or the parts of the puppet, im the knots that tie the string to the parts.

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.

Edit: My last post was more of a hinderance  than a help, so i took it out.

In my  last post I discussed a possible way of doing animation pivots – it sadly was just notes in my book and spare of the moment ideas. I think i missed out a vital chunk, and i think in theory I can make it a little cleaner – weak referencing not needed.

So this is still theoretical, but if we examine a standard object matrix3 transform it contains the transform space and its pivot space i.e the offset to keep it in the right position. So if we essentially generalize this idea (i.e making itself over the top of itself) i think we can work it out.

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.

I thought about an idea for unifying an fk/ik system today – using a single fk chain driven by a detached wrist to define a hypotenuse, to make it act like IK. And driving the same wrist with weak node referencing, and storing two matrix3 values driving its transform space so it stays glued to the end of the elbow joint. Rotation would use the same method.

So you would move the wrist, and in doing so define the 3 lengths needed for ik solution (2 of the lengths are constant unless you introduce stretching). And when you rotate the bones – on another float_list (bezier controller) you drive the transform positional space of the wrist, keeping it glues to the end of the elbow.

Weak referencing could also be used for gluing the knee control to the knee, and also a control at the elbow to break it, stretch it etc.

Some issues maybe doubling of transforms, plus controlling the elbow. Also pulling the wrist too far from the the ik solution – this i think could be fixed.