3dSpaces
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 origin of worldSpace.
It’s in 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 parent
pCube01 under pCube02, pCube01 is now deemed to be, a child of, and inside
the 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 worldSpace
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 worldSpace
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 transformations
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.
How do WE handle these spaces?
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 3dSpaces
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:
- parenting -(one object becomes the child of another thereby creating a heirachy)
- direct connecting -of attributes (that affect the position/orientation) etc of one object to another
- constraining -one object to another (point, orient, scale etc)
- deforming -an object via a special 3D deformer (this will most likely move the components of the object through a space rather than the base transforms.)
- math - lower level nodes for matrix mathematics for direct manipulation of the transform space