Encapsulation and incorporation without loss of independence.

No this isn’t about politics, more a case of keeping assets tied to a system, that allows them to be flexible with all departments – animation, tech and art, whilst being editable and exportable en-mass.

The most important factor is iteration. Assets, animation, and rigs will get iterated over time and you need the ability to change and update them whenever.

Assets need to be editable/exportable on mass and externally, to not slow production down. Version control systems generally have a locking process that means if all your assets are on one rig, another user will have to wait for the unlock or submitted changes to get it. Using externally linked or tied resource means, a tech guy can make changes to the file and user needs only to reload the resource back to get changes, even if the users had those assets loaded with the saved scene. Essentially dynamic referencing or passive referencing is crucial.

Animations are gold, and so need to be kept to the highest fidelity when loading them onto another rig. Crucially what needs to be kept between rigs is animation controllers, not bones. A mapping file then only needs to use what it finds to reload the animations back onto a rig.

The rig has to be updatable, and in a non-destructive way to the scene. It needs to get either dynamically changed – controller changes already existing and nodes that get removed and updated attached to the rig; or passively changed – where the entire rig along with everything attached to it gets loaded out and reloaded in with updates.

Rigs: To update or use a new version?

I found a dilemma today involving updating rigs – firstly what’s the best approach to update one, and secondly when should a users just use a new version? Should we just keep updating a rig with updates or at some point build a new version of the base rig with the said updates? I.e a new version. It’s a tricky problem for a development.

I guess the best paradigm for it is this – build a rig, and when changes happen apply them in a form of updates to users who are already using the rig. But in addition to the updates, update the original rig so that new users get the change instantly without being out of sync with the old ones.

Updating needs to be simple; simple enough for anyone to just drop an updated file in a folder and have the rig read it in.

As to any character pipeline backbone, the ability to update a rig without destroying the animation is crucial.

Matrices: Rules I try to remember, but tend to forget!

1. In 3d the product of matrix multiplication is always in world space.
2. An objects transform is a product of its target space multiplied by its reference space.

This second part is really vital to understand, (I dont think I’ve phased it myself well enough here even) But basically it means that if your transforming an object by the world, but the object is parented the difference between the object and its target space need to be multiplied by the objects local space.

I’ll try to describe this more with pics.

Matrices: Reference Coordinate System

All object transforms have a reference coordinate system i.e. the space they exist in even if there parented to an object or not. For example if I’m driving a vehicle, I’m relative to the vehicle which in turn is relative to the earth, and in turn the sun. 

When we want to find the difference or offset of an objects transform relative to its space – be it’s parent, world or an other object we use whats called the inverse. Now this is where it gets a little tricky so ill go slow – to transform an object by another object or get it transform relative to that object we use matrix multiplication. Matrix multiplication in laymen’s terms is basically addition like 10 + 10, but most importantly is non-communicative. 

This means simply that  if one matrix is 20 and another matrix is 30, 20 + 30 will equal 50 but 30 + 20 wont. Or simply put its like subtraction. This is due to how matrices are multiplied together.

If we got back to our start matrix – [1,0,0] [0,1,0] [0,0,1] [0,0,0] we can classify each vector as a ‘row’ i.e.

[a,b,c] – row 1

[d,e,f] – row 2

[h,i, j] – row3

[k,l,m] – row 4

With perpendicular values such as a,d,h,k being ‘columns’. In our example above we have 3 columns by 4 rows or a 3×4 matrix. The crucial rule you have to keep in mind when multiplying matrices is that the initial matrix must have the same amount columns as the matrix your multiplying it against has rows. For example if our initial matrix looks like this:

[1,2,3]

[4,5,6]

Our multiplying matrix must have the same amount of rows like so,

[a,d] 

[b,e] 

[c,f]

We multiply a matrix like so: 1 x a, 2  x  b, 3  x c and so on and so forth…

When we get the relative transform of one object to another, we multiply its transform by the inverse of our target object, parent or space. Now this is a quite a bit more complex so i’ll discuss it very simply.

If we treat two matrices as single values for example 10 and 20, when we get the relative space of 10 to 20 what we do is 10 + -20. Which gives us -10; in other words we’re finding the difference we need to go our base objects transform from our target object, parent or space. Were getting the transform ‘offset’ we need to apply to our target object to get our base objects transform. This offset is always in world space – because it’s the difference thats needed.

More on matrices: basics

Most object transforms in 3d software are matrices’ heres a rough breakdown of what they are.

A matrix in 3d is an axis defined by three vectors: X,Y and Z and fourth being it’s positional offset from an origin. The length of each axis from the origin defines the scale of that axis; 1.0 being 100%. The ‘identity’ matrix is an objects base transform e.g.

matrix3 [1,0,0] [0,1,0] [0,0,1] [0,0,0] – for the X, Y, Z axis’ and the positional offset from the origin.

So for instance if we wanted to scale an object by 200% along its X axis our matrix transform would look like this – matrix3 [2,0,0] [0,1,0] [0,0,1] [0,0,0]

Notice also that each axis is perpendicular to each other axis (90 degrees) – this is important is if it wasnt we would get skewing. Now each axis’ can point in any direction as long as the other two are perpendicular to it.

Transforms, matrices, ideas and the likes..

Sorry for the delay, pretty busy here at work essentially rebuilding some big pipeline tools, systems etc etc.

First up I’ve got a new idea for an animation controller which I’m sort of keeping under wraps. Basically rigs are hooked together by controllers which are animated, problem is most of these tend to be custom – what im planning is a very basic controller that does advanced transforms very well – on top of this customly defined controls can be added on top – which get sort of ‘wired’ into the system.

Secondly I’ve been trying to explain (hopefully) transforms over at CGTalk. A transform is basically a direction with a spin projected by an offset about a coordinate system. Now this sounds a little complex so over the next few posts i’ll explain them a little bit better hopefully with some interesting examples.

A meta-data paradigm for rigging.

I was reading up on Bungie’s modular rigging and ILM’s block party – they talk about modular nodes that define how the character is made and built. I think it’s a great system to use and I’m still trying to get my head around it!

My aproach is to treat the system as searchable properties with values. Nodes with assigned properties can be then rigged based apon them e.g a bone may have a property called, “left”, “leg”. And have sockets and plugs (ala ILM) to tell it how to be rigged.

My only problem is that how are properties different to each other to be meaningful? I.e we can rig a leg it different ways – how does it know which way to use? It may be just another simple tag like “basic’ or ‘dynamic’ but im not sure.

Bone:Left:Leg:IKFK? – maybe its this simple?

Also, do we need attribute headers i.e properties – “Type”, “Description” etc or just the values themselves, “left”, “arm”, “IK” ? Personally I think you have to have properties as firstly not everything should be a string and secondly most importantly how do you differentiate between numerical values of 2 or more properties? e.g TYPE:2  LOD:2 now two values of  2 are essentially meaningless, unless they have some identifier.

I’m going to pursue  this further as i think its definitely the way forward.

How my brain works… a quick example.

Just wanted to give a quick run down of how my brain works tackling a problem, I recently saw a video of a dynamic tail a friend of mine had sent me – the obvious approach would be verlet, a system where you can keep overlaying solvers ontop of solvers. But another key system the tail had was to maintain its shape whilst being dynamic this sent my brain into overide! How is this possible – here’s how my brain would solve it (this hasn’t been tested, all theoretical):

A chain of controls, points and bones. Get the transform space of the second control onwards, build a verlet framework of the points, with stiff rods connecting them and  point constraints made by getting the relative space of the control relative to its parent multiplied by the same points direction , i.e point 3 use the transform position  of control 3 relative control 2 multiplied by the direction of point 2 – point 1.  Finally build a matrix transform from this and apply it to the skeletal chain consecutively.

Now i dont know if this is correct, but this is how my mind thinks – i build little systems and stick them together, then i spend the biggest chunk of time getting the systems to talk nicely to each other.

Game Pipeline Notes

• ‘Non-destructive obsolescence’  is the paradigm you must strive for. Existing animations and mesh, must be able to to load onto changes in the rig. Meshes should be able to retain most of there skinning data.
• Care more about import than export (from GDC  08′ notes – Rod Green)
• Granulize the assets into file types: skin, animation, bones etc etc and allow them to attempt to be loaded, this is important not only for retention of source data but also allows for cross-mixing multiple assets eg. skin from one, mesh from another.

Notes on natural spine rigging

Here are some notes on natural spine rigging, im not going into details about stretchy spines are most of this stuff wouldn’t apply especially to do with twist.

• Natural spines do not make ‘N’ shapes!, the top chest part never goes below the lower pelvis part. The lowest the mid section can go is 90 degrees perpedicular to the lower part and top part. – This can be easily accomplished to never go below by using simple dot product math. Which beings me on to my next point.
• The spine system i used and still do is three bones: bottom, mid and top with an IK chain running between the mid and top joints – this allowed me to always make good ‘S’ and ‘C’ shapes, with the spine always keeping its length.
• For deformation ride a simple chain with a complex one, the ribbon spine approach is elegant approach to this. It allows for deformation to still happen when controlling the simple chain in FK mode – my approach is similar to this but is grounded in math.
• Do not try and reach the ‘holy’ 360 degrees in all directions, the math is insanely complicated (trust me!) and more pertained to tentacle rigging where by its controlled by deforming a curves control points in position space rather than rotational. A combination of 180 degrees in yaw and pitch, with a twist of -180 to 180 is fine.
• The animation mechanism can should work in Euler rotation space, by the system underneath directly driving the spine can work in quaternions, in fact i strongly recommend riggers learn quaternion math – naturally most of rotations from the shoulder to the wrist work in a hemispherical space. The key is extrapolating the combined rotational systems creating the final deformation.