For any Rig, the aim is to setup controls that Animators can move. These controls… well … control various aspects of the Rig, eye blinks, arms moving etc.
Since different parts of the rig live in different
3d Spaces we need to be able to
construct and deconstruct these spaces effectively so the Rig behaves correctly.
Some basic understanding of
3D space (in relation to objects in 3D space)
and how to manage them is very important.
The first 3D space you will be introduced to will be in the viewport. And while rotating around inside the 3D viewport you’ll usually be presented with a grid, and this grid has a center point.
This is the center of the universe, [0x, 0y, 0z].
Side note: the further away we get from this the less accurate the [floating point] calculations are etc.
If you were to make a pCube01 it’s position will most likely default to
[0x, 0y ,0z] and this is deemed to be at the
worldSpace because it has no parent, it’s just sitting there
in the universe all on it’s own controlled by nothing.
How ever; if you were to make a another cube (pCube02) and you
pCube01 under pCube02, pCube01 is now deemed to be, a child of, and inside
space of pCube02.
It is now considered
local to pCube02.
If you move pCube01 around now you’re moving it
relative(local) to pCube02’s
space in the world and the numbers you see might not reflect
for the cube any more?!! This can be confusing, but just remember most applications
will now represent the position of pCube01 RELATIVE to pCube02 and not the
because it is a child of pCube02!
Does this mean you can’t get to pCube01’s worldSpace? No. You can still
query pCube01 for it’s worldSpace position via the application’s API/
nodeEditor etc; and when do you query for this
worldSpace value, the
application’s calculations will account for all of pCube02’s
as well as the cumulative result of every transform(that affects pCube01)
that’s happened to get pCube01 to where it is, is considered pCube01’s worldSpace.
Well invariably behind the scenes there will be math ops dealing with matrices / vectors etc to calculate the results required and put an object where it should be; and at some point you’re going to need to understand this math if you want to get serious about controlling your rigs, but to begin with, inside your chosen 3D application, and are usually presented in a more accessible way (see the list below).
Side note: Interestingly in respect to the earlier comment about getting further away
from origin and inaccuracies in the computers ability to caculate the math,
we can use these spaces to tell the rig that we’d like to move everything
all the way back to
origin before doing any calculations and then put it
all back to where it should be. This kind of manipulation of the rig’s
can help reduce jittering / render issues when scenes are very large.
It is also more commonly known as
localising a rig.
So…anyway, approaches/tools that help us deal with spaces, but not limited to: