PLEASE NOTE: The following python scripts require this procedure to work properly.

Facial Animation

A thread started at XSI Base simply named, facial animation (questions), many facial rigging and animation concepts were shared. The two concepts discussed mostly were your traditional shape animation controlled by in scene controllers (a la Osipa) and also using Control Splines or curves with many complex rig elements that give you the desired motion. At the end of the day shape animation gets you pretty far with many character types ( realistic and stylized ) and setup time is pretty fast. The setup time is also important here, Softimage considers this a feature for FaceRobot that they market and rightfully so. Time is money, producers know this as should you! So if you will hear me out I am going to explain a way for you to continue to use shape animation and still get the low level control over subtle face movements.

The Static KineState

What is the Static KineState? I am sure anyone spending any amount of time rigging knows something about it. So lets define it for those that don’t.

The Static KineState indicates that an envelope is applied to the skeleton element. The StaticKineState is the initial position of the skeleton when the envelope was applied, and is used for envelope calculations.

If this property is storing these initial values then I must be able to change them. This is the gem that makes this rig work.

Dorritos

Now we are going to make the rig. This is not intended to be a tutorial so I apologize if I miss steps, all the project files are included at the bottom. So lets go over the rig!

I am starting with Primitive>Character>Face Man and I first made a quick “smile” shape, followed by a typical neck, head, and jaw for the character. I used nulls instead of joints for simplicity sake.

Now I am going to make a clone of this enveloped head and immediately remove the duplicated shape cluster, envelope cluster, and the “ShapeWeights” property. The clone uses the “CopyOp”, with this we get all the deformations from the first head which include the envelope deform and shape deform. Now we need to setup the local deformers for the cloned mesh.

These local deformers use an “Object To Cluster” constraint. I like to use edge clusters but you could use any SubComponent you choose. So I picked an edge in the corner of the mouth and ran this handy script that creates the cluster, the object, constrains them, and makes the local deformer. You need to select a component on the original head, and run the script.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

#imports
import win32com.client
from win32com.client import constants
 
#globals
xsi	= win32com.client.Dispatch( "XSI.Application" ).Application
xsiPrint = xsi.LogMessage
 
def setupDorrito():
	if xsi.Selection < 1:
		xsiPrint("Select an component!",constants.siError)
		return False
 
	root = xsi.ActiveSceneRoot
 
	#create cluster constrained null, setup its look
	clsCnsNull = root.AddNull("clsCnsNull")
	clsCnsNull.primary_icon.value = 0
	clsCnsNull.size.value = 0.1
	clsCnsNull.shadow_icon.value = 7
	clsCnsNull.shadow_colour_custom.value = 1
	clsCnsNull.B.value = 1
	clsCnsNull.G.value = 0.5
 
	#make cluster from selection
	subComponent = xsi.Selection(0).subComponent
	cnsCls = subComponent.CreateCluster("cnsCls")
 
	#constrain object to cluster
	cns = clsCnsNull.Kinematics.AddConstraint("ObjectToCluster",cnsCls)
	cns.tangent.value = 1
	cns.dirx.value = 0
	cns.diry.value = -1
	cns.upvct_active.value = 1
	cns.upx.value = 1
	cns.upy.value = 0
 
	#make dorrito
	dorrito = root.AddNull("dorrito")
	dorrito.primary_icon.value = 0
	dorrito.size.value = 0.2
	dorrito.shadow_icon.value = 8
	dorrito.shadow_colour_custom.value = 1
	dorrito.G.value = 1
	dorrito.shadow_offsetX.value = 0.1
	dorrito.shadow_scaleX.value = 0
 
	clsCnsNull.AddChild(dorrito)
	dorrito.kinematics.local.transform = XSIMath.CreateTransform()
 
setupDorrito()

The result…

At work we call this controller a “Dorrito” because when the first “on the face” rig came out, one of our animators, Jason Taylor, started calling it that and it stuck. So my controller is a flat pyramid that looks like a Dorrito, so I suggest you do the same :) Now I will add an envelope to the cloned mesh and choose this Dorrito as a deformer. I now need to paint the cloned mesh’s envelope. The way I do this is add another deformer to the deformer list, set all the points to 100 % of this new deformer, and then choose the Dorrito and paint it’s influence. Once I am happy with the deformation I just remove the extra deformer from the envelope and I get zero weights except for where I painted the Dorrito’s influence. This deformer moves with the cluster constrained null, but it causes this nasty double transform when I rotate the head!

Why is this happening? Because you have the first envelope on the original head which is deforming the points based on the transformation of the deformers (neck, head, and jaw). Then you have a “CopyOp” and another envelope above that is getting transformed by the same movement so XSI just does it twice! What you want to do is subtract that first envelope transformation from the second envelope transformation. The Static KineState gives you access to that intial position. If you take your deformer’s Static KineState property and set it’s parameters equal to the global transform parameters of your cluster constrained null you will effectively be constantly reseting the deformer’s initial position. Here is a script to setup the expressions between the cluster constrained null and the local deformer. Just select cluster constrained null first, then the Dorrito.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#imports
import win32com.client
from win32com.client import constants
 
#globals
xsi	= win32com.client.Dispatch( "XSI.Application" ).Application
xsiPrint = xsi.LogMessage
 
def setupStaticState():
	defList = []
	clsList = []
	for i in xrange(0,len(xsi.Selection),2):
		clsList.append(xsi.Selection(i))
		defList.append(xsi.Selection(i+1))
 
	for a,b in zip(defList,clsList):
		defKineState = a.Properties("Static KineState")
		clsKine = b.Properties("Kinematics")
 
		defKineState.orix.AddExpression(clsKine.FullName + ".global.rotx")
		defKineState.oriy.AddExpression(clsKine.FullName + ".global.roty")
		defKineState.oriz.AddExpression(clsKine.FullName + ".global.rotz")
		defKineState.posx.AddExpression(clsKine.FullName + ".global.posx")
		defKineState.posy.AddExpression(clsKine.FullName + ".global.posy")
		defKineState.posz.AddExpression(clsKine.FullName + ".global.posz")
 
setupStaticState()

Now you can rotate the head or jaw and the deformer just rides the mesh, you can even use shape animation and the deformer just rides on top of that with no double transform.

Viewport Capture

Closing

There are many ways to rig a face and none should be discarded from any rigger's toolbox. I hope other riggers will get some use out of this technique and will share their work with us. Before I go, I want to thank my rigging supervisor Remi McGill for suggesting the usage of the Static KineState and Blur for allowing me to share with the community. Below are the project files which includes the scripts. Thanks for reading!

Project Files

Okay so here’s how it works:

1. Create your geometry and rig
2. Put rig and geometry into two different models
3. Create the connection (envelope, constraints etc)
4. Export FIRST the geometry, and SECOND the rig.
5. Go to a new scene and import FIRST the rig and SECOND the geometry as referenced models.
6. To ensure the models are loaded in the right order in the future, also name them alphabetically in that order. (in my example I am using numbers to set that order)
7. Put both ref models into a new one and export it as the “fullmodel”.

You end up with three files. The first one includes just the geometry + envelope operator and weightmaps, the second one includes just the rig, and the third one, the “fullmodel”, includes just two file pointers to the previous two.

If you want to go ahead and make changes to the rig, you can externally, while just loading the rig up and modify it. If you are about to change the geometry, and you don’t want to loose the envelope, just open up the fullmodel, localize the submodels and do your edits, afterwards convert the geometry back to referenced, and reload the “fullmodel”.

Below you can see a working example in the explorer, and a repro script to generate this setup. All steps (also changes on the geometry after the connection has been established) are part of that script.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

var project = ActiveProject.path;
NewScene(false,false);
 
// create objects
CreatePrim("Cylinder", "MeshSurface");
Create2DSkeleton(0, 3, 0, 0, 0, 0.5);
AppendBone("eff", 0, -3, 0);
 
// create models
CreateModel("root", "_0rig");
CreateModel("cylinder", "_1geo");
 
// reset the transform of the models so
// they are in the center of the world
SetUserPref("SI3D_NODETRANSFORM_CHILD_COMPENSATE", 1);
ResetTransform("_0rig", siObj, siSRT, siXYZ);
SetUserPref("SI3D_NODETRANSFORM_CHILD_COMPENSATE", 0);
 
// create the envelope (connect the rig)
ApplyFlexEnv(
"_1geo.cylinder;"+
"_0rig.bone,_0rig.bone1"
);
 
// export to files
ExportModel("_1geo", project+"\\Models\\geo.emdl");
ExportModel("_0rig", project+"\\Models\\rig.emdl");
 
// new scene
NewScene(false,false);
 
// import both as referenced
SICreateRefModel(project+"\\Models\\rig.emdl", "_0rig");
SICreateRefModel(project+"\\Models\\geo.emdl", "_1geo");
 
// create a new model including both
CreateModel("_0rig,_1geo", "fullmodel");
 
// export this model again
ExportModel("fullmodel", project+"\\Models\\fullmodel.emdl");
 
// new scene
NewScene(false,false);
 
// import the fully rigged, separated model as referenced
SICreateRefModel(project+"\\Models\\fullmodel.emdl", "fullmodel");
 
// change the geometry while maintaining the connection
MakeModelLocal("_0rig", null);
MakeModelLocal("_1geo", null);
Translate("_1geo.cylinder.edge[67]", 0,0, -1.5);
ConvertToRefModel("_1geo", project + "\\Models\\geo.emdl");
 
// reload the full model
UpdateReferencedModel("fullmodel");

Here’s a link to the script file so you can download it and try it out.

I hope this helps!
Helge

Lets start. One easy way to approach this problem is to create a mesh including all objects we want to envelope, and then simply set the envelope weights of all points of a single instance to the exact same weight, aka:

In this image we have a mesh with 6 cubes (all merged together) enveloped to a two-bone chain.
By default the weight is blended in the middle part,

which results in a deform for the middle two cubes:

by using the weight editor, I adjusted the weight of all cubes so they only target one bone:

which results in movement, but not deformation for each one:

So this is all working, why bother dealing with a system to deal with these things? Well, as long as we are dealing with six cubes it is all cheesy and simple, but as soon as we start dealing with something like feathers on a bird, we can’t just go in and envelope each feather with the weight editor, well, we could, but it would just take forever.

What I used to do in those cases is to build an instancer operator, which would take a mesh containing “where-and-how-to-instance” information, and a single mesh which is supposed to be instanced. First, lets clarify the “where…to-instance” part:

When instancing an object, all you need is a position, orientation and scaling, which can be stored as three points really, but in this example I am going to use 4 points:

1. Pos: The position of the object to be instanced
2. Cns: The Z-Direction of the object (seen from pos)
3. Upv: The Y-Direction of the object (seen from pos)
4. Bnd: An additional point to be used for deformation (later)

So basically we could draw a quadrangular polygon instead of four points, like below, where we are instancing ten grids:

Now: Instead of enveloping the objects we want to be instanced, we envelope the mesh containing the quads. This is going to be called our “Instancing-Cloud”. It contains all of the information we need to instance our objects. Moreover, it is easy to envelope, as we know exactly which points are to be enveloped where. Every first out of four points is the position, every second out of four points is the z-direction etc… All we need to build is a couple of scripts:

1. One which adds a quadrangle to a mesh based on a transform of a null.
2. One which creates a new mesh and instances an object onto an Instancing-Cloud.
3. One which generates clusters for the instance-cloud for easier enveloping.

A finished setup could look something like this: We see the quads representing the instances:

When deformed: The quads deform, but the instances will not:

Including the instances it should look like this:

When deformed:

As we have point clusters for each type of point in the instance-cloud (pos, cns, upv and bnd) it is quite simple to rig the cns for example to a bunch of rotational controllers:

And when we rotate them, only the cns points are deformed, therefore the instances rotate as well:

Additionally we can deform the cloud overall:

So now lets discuss the last part of the story: What’s the bnd position for?
The bnd position is used for deformation of each instance. As this is quite limited, all I am going to do is move the instances points using a sinus function, to get somewhat of twisting and bending going on. This is up to your imagination, as I said, this setup has been used for feathers, that’s why the bnd position is used for bending (and named like that as well: bnd = bending).

In the next image I rigged the bnd position to the rotational controller earlier used for cns, to show what happens:

So now when I rotate them:

Or along another axis:

As always – I’d like to share the progress so far, but I have to warn you, it is not at all documented:

Put the file into one of the plugins folders, and run the following script to get some feather setup going:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

NewScene(false, false);
var cloud = mt_createFeatherCloud();
 
var grid = CreatePrim("Grid", "MeshSurface", null, null);
SetValue(grid+".grid.ulength", 0.4);
SetValue(grid+".grid.vlength", 3);
SetValue(grid+".polymsh.geom.subdivu", 1);
Translate(grid+".pnt[*]", 1.4, 0, 0, siRelative, siLocal, siObj);
FreezeObj(grid);
 
var mesh = mt_createFeatherMesh(cloud, grid);
var feathers = new ActiveXObject("XSI.Collection");
for(var i=0; i<10; i++)
{
feathers.Add(mt_createFeatherNull());
feathers(i).kinematics.local.posx.value = i;
}
 
mt_addFeathersToCloud(cloud,feathers);
mt_createCloudClusters(cloud);
 
DeselectAll();

Let me know how it goes,

enjoy!

Initially, figuring out how this could work seems like a pretty tricky problem. The bone chain needs to stretch intuitively to give the impression that it’s stuck to the IK effector. But we also need it to flatten gradually to avoid the snap effect. Unfortunately, the only thing we have available to us to control these two effects, is the ability to change the length of the bones, since the end position of the chain must always be located at the effector.

So we need to scale the bones to allow them to stretch, but at a specific rate to make sure we avoid the snap. Like this:

The first thing to do is to look at how we solved the problem for the non-stretchy bone chain. When we look at what happens when we move the Soft Effector past the point where it starts to leave the original IK effector behind, all we want to do for the stretchy bone chain system is make sure that the bone chain gets longer so that the original IK effector is at the same position as the Soft Effector. But we need to do this while also keeping the bones angles the same, this avoids the snap effect since the bone angles would change at exactly the same rate as in the non-stretchy bone chain system.

A diagram should make things a bit clearer. Basically, given a non-stretchy chain, we want to match the position of the two effectors by scaling the chain length, but without changing the bone angles, like this:

Okay, so that doesn’t seem too hard. We just need to figure out how much to move the IK Effector to match the position of the soft effector.

The only way we can do this is by changing the length of the bone chain. Again, this initially looks like quite a tricky problem, until you realize that scaling the length of each bone by some value X, also scales the distance of the original IK effector from the IK root by a factor of X as well. A simple test proves it (and it can be easily shown with a little math too):

This diagram shows a bone chain with bones of different lengths, before and after I scaled each individual bone length by a factor of 2. It can be seen that the IK effector has traveled directly away from the IK root and has doubled it’s distance from it. Not only that, but the bone angles have remained unchanged. This is exactly what we need!

Now, all we need to do is to figure out the amount we need to scale each bone length to make the original IK effector match the position of the soft effector. That scale factor is just the ratio of the distances of the two effectors:

Scale Factor = EvalDistance(IK root, Soft Effector) / EvalDistance(IK root, original IK effector)

Where EvalDistance() is just a function that measure the distance between the two objects.

Finally, we need to position constrain the original IK effector to the soft effector, so that it follows it. Otherwise, all that would happen is that the length of the chain would change.

So that’s it, we’re there. All that remains is to package it all up into a plugin with a handy custom property to drive it all. This is what the new property page looks like:

The bone lengths can be adjusted (and even animated) from this PPG, as well as the Soft Distance parameter, which behaves in exactly the same way as in the non-stretchy Soft IK. The bone lengths are all driven from this PPG using expressions. Note, that for extra performance we only have one Scripted Operator here which operates on the BoneScale parameter of the PPG.

I’ve updated the original Soft Effector script to include a new menu item to apply the Stretchy Bone Soft IK system to any chain you select.

Soft Effector Download (3Kb)

Incidentally, if you ever want to remove the Soft IK (stretchy or otherwise) from a bone chain. All you have to do is delete the Soft Effector object. All the expressions and operators will be automatically deleted since they will have lost their connections. Nice and tidy!

P.S. Thanks to Daniele Niero for suggesting I cache the math objects inside the operator user data!

In XSI, we need a way of allowing the chain to gradually fall behind the position of the effector. This stops the effector from snapping the chain into the final position, and gives rise to a much more natural motion (as seen below).

(Note: If you are unable to view the GIF animation, you may need to change settings in your Firewall. For example, in Zone Alarm, you need to disable Privacy->Ad Blocking)

The snap effect visible in the top chain isn’t due to some inaccuracy in the IK calculation, but is just down to a simple geometrical effect. It can be shown mathematically (see diagram below) that as the effector pulls the chain into the final position, the velocity of the bones towards their final position tends towards infinity! This is obviously not desirable and can make the animation look jerky and artificial.


(click to enlarge)

To achieve the type of motion shown in the lower chain, we need to add an extra object which is used to drive the IK chain effector. A scripted operator links the two objects and we use a mathematical expression to give the desired result. The only bits of information the operator needs are the total chain length, and something I call the “Soft Distance”. This represents the distance from the chain’s full extension that the effect starts to work.

There is one downside with this approach, as it means you can’t fix the end point of the chain in position. However, this can be solved as long as you are willing to put a small amount of extra work to animate the Soft Distance parameter.

The soft effector object has a custom property to allow you to easily control the operator.

To make things easier for you, the Chain Length is calculated by an expression which sums the length of each bone in the chain. This allows you to change the length of a bone, and still have the Soft IK work.

In the diagram below, the Soft Distance is represented by the distance between the green and the red lines (actually, they’re circles, but too large to see). As soon as the effector reaches the green line, our scripted operator starts to lag the chain effector behind our soft effector. This is done while making sure that we have no jerkiness in the motion of the chain effector.

(Note: If you are unable to view the GIF animation, you may need to change settings in your Firewall. For example, in Zone Alarm, you need to disable Privacy->Ad Blocking)

The equation used to create this effect is shown below:

(click to enlarge)

For a chain length of 3 and a soft distance of 1, this equation looks something like this:

(click to enlarge)

You can use the following link to download the Soft Effector plugin:

Soft Effector Download (3 Kb)

(Note that this also features the Stretchy Bone Chain extension shown in Part 2 of this article)

To install the plugin, just download the zip file, unzip the script, and copy it to a “Plugins” folder. So for example, you can use your “C:\users\username\Softimage\XSI\Application\Plugins” folder, or one in your workgroup.

To use the Soft Effector, create a 2D or 3D Skeleton Chain, select any part of the chain, and go to “Model->Create->Skeleton->Apply Soft Effector”.

• Making sure all objects follow a valid naming scheme
• Giving objects the correct icons / wirecolors / looks
• Setup position- / rotationlimits based on the objects’ types
• Putting objects into groups based on their types
• Changing names of sides when duplicating in symmetry
• … and so many more

To deal with these things one of my favourite ideas comes into play: Automation.

To explain a little bit what complexity we are dealing with, here’s a screenshot of some rig in the schematic view in different zooms:

A. Object templates

As you can see in the lower part of the image, there is naming convention applied to all objects in the hierarchy. The naming convention looks like this:

prefix_name_suffix

In this example the prefix can only be “m”, “l” or “r”, but it could be anything depending on your implementation. The suffix is used to determine the type of object we are dealing with, in the example the greenish objects have the “JNT” suffix, which stands for joint, a bone in a chain. Note that all objects have correct naming and the reason is that they have been created using templates. Here”s the idea:

Use one scripted command to create every object in a rig, using a template to define its attributes. This function would look like something similar to this (pseudo-code):

function makeElement(prefix,name,suffix,parent)
{
    1. check if the object already exists
    2. check if the prefix is valid
    3. check if the suffix is valid
    4. create the element as a child of the given parent
    5. apply all attributes based on the suffix
    6. return the created element
}

Not only will all objects obey the template rules, there are also some additional advantages to this method. Turning the workflow around, by having to know the name for an object before you create it, rather than naming it after it has been created already (we are all lazy, aren’t we) makes sure that rig-elements get the correct names, as you will not be able to create an object which already exists. Furthermore every object created by such a function can be re-created, as all of the information how to create the object is inside of its name. When you find an object called m_global_SRT which is a child of the object m_global_BUF you know how you can re-create it: You just call the function like this: makeElement("m","global","SRT","m_global_BUF");

This means you can analyze the hierarchy quite easily and regenerate parts of a rig in a simple manner. Which brings us to the next type of templates.

B. Hierarchy templates

Templates for a full hierarchy are something like a script which describes how to generate the hierarchy, relying on object templates for each of the objects. There are some additional steps to do here though, as the objects might contain additional modifications. I am assuming that the helper functions to apply those modifications already exist in our rigging-toolset ;-) so I am not implementing anything here.

So a template for a simple hierarchy containing a hip and and a chest srt controller could look like this:

1
2
3
4
5

function makeHipAndChest(parent)
{
    hip = makeElement("m","hip","SRT",parent);
    chest = makeElement("m","chest","SRT",hip);
}

Tweaking the functions a little bit, we can end up with something similar the code below:

function makeElement(prefix,name,suffix,parent)
{
    1. check if the object already exists
    2. check if the prefix is valid
    3. check if the suffix is valid
    4. check if the suffix is SRT and if so, create a buffer object for it, using the same prefix and name but a "BUF" suffix
    5. create the element as a child of the given parent or of the buffer
    6. apply all attributes based on the suffix
    7. return the created element
}

1
2
3
4
5
6
7

function makeHipAndChest(parent)
{
    hip = makeElement("m","hip","SRT",parent);
    transform(hip,[0,0,0,0,90,0,1,1,1]);
    chest = makeElement("m","chest","SRT",hip);
    transform(hip,[0,5,0,0,0,0,1,1,1]);
}

Simple enough, the example hierarchy looks like this:

The transform method is representing one essential modification done to the object in the hierarchy, well, its transform. But there are some more things to look at. Stuff like expressions, constraints, added custom property sets etc… should be persisted, as they are essential to a rig. What is important for the functionality as well is to be able to recreate a hierarchy changing parts of the naming scheme, for example make a left arm and then a right one, or prefix the name of each object created with “upper” or “lower” to specialize the naming of those objects. Using a function such as “makeElement” which is based on names will make this quite difficult though. To explain this in more detail, imagine the following scenario:

We created a simple hierachy of a camera and an interest, where the camera has a direction constraint to the interest. The camera is called “m_Camera_CAM” and the interest is called “m_CameraInterest_POS”. Now, if we call our function to create the camera, which could look like this:

1
2
3
4
5
6
7

function makeCamera(parent,newPrefix,newName)
{
    prefix = newPrefix ? newPrefix : "m" // if there is a newPrefix, use that, otherwise use "m"
    makeElement(prefix,newName + "camera","CAM",parent);
    makeElement(prefix,newName + "CameraInterest", "POS",parent);
    makeConstraint("DIR","m_Camera_CAM","m_CameraInterest_CAM");
}

If we would call the function with the following parameters makeCamera(parent,"l","hero") we would end up with two objects called m_heroCamera_CAM and m_heroCameraInterest_POS with no constraint, because the makeConstraint function is based on the old objects’ names. To deal with those things we have to introduce a remapping scheme. It could look like this:

1
2
3
4
5
6
7
8
9

function makeCamera(parent,newPrefix,newName)
{
    prefix = newPrefix ? newPrefix : "m" // if there is a newPrefix, use that, otherwise use "m"
    element = makeElement(prefix,newName + "Camera","CAM",parent);
    remappingTable [ "m_Camera_CAM" ] = element.name; // store the current name of the element to be able to remap
    element = makeElement(prefix,newName + "CameraInterest", "POS",parent);
    remappingTable [ "m_CameraInterest_POS" ] = element.name;
    makeConstraint("DIR",remappingTable["m_Camera_CAM"],remappingTable["m_CameraInterest_CAM"]);
}

Alright – now we can rebuild hierarchies persisting their attributes by using object templates, adding local modifications such as transforms etc, constraints and expressions can be stored by remapping their inputs using the remappingTable etc…

With this we can now build a library of rig elements and recreate them easily, while still being able to change prefix and specialize the name. Moreover the rig parts can be recreated anywhere in the existing hierarchy, as the function takes the base parent as an input argument. What is really interesting about this approach though, is that you can write a function to auto generate rigging-part-functions by just analyzing what somebody rigged manually. Put simple: Rig manually -> Create a rigging function out of it -> Re-use the function to create the rig part multiple times !

To finish up the theory and the talk about “how nice it would be”, here’s an implementation of my own which I put together while rigging a couple of characters…

Documentation
Addon (This is often saved as XML, just rename the file to “mt_rigz.xsiaddon”.)
Movie (Camtasia Capture 56 MB Techsmith Codec)

If anybody pushes this a lot further, and is allowed to share any of it, I’d love to get some feedback in this blog!

Enjoy!

So as an example, you could create a Digital Asset of an apple. In the interface that you create, you would maybe expose a control to change the color of the apple. In fact, to make it even easier, it might just be a slider that controls the color to go from green to red. You could call that control “Ripeness” if you want. You could also add a slider for controlling the size.

If you now give this asset to another artist, the only way they can change the apple is for them to use the controls you have provided. This means that they won’t be able to make the apple turn blue (accidentally or otherwise).

In a large pipeline, this can prove to be extremely useful. It means that if the TD knows what they’re doing, they can deploy assets in production which won’t get broken or changed in an unexpected way later on. Obviously, care must be taken not to take this paradigm too far and to over encapsulate the object making that asset inflexible. So research and planning for an asset’s role in the pipeline is vital to make sure that the right level of control is applied.

So how can we create Digital Assets in XSI? Natively, they aren’t supported. What do we need? We just need a way to store our asset, a method of presenting certain parameters of our choice to the user, and a way of hiding objects from various XSI editors (Explorer, etc.).

The obvious choice for storing our asset is to use an XSI model. Each model represents a unique namespace for objects and they are XSI’s current method of asset encapsulation (albeit limited).

The second one is also easy. Proxy parameters enable us to provide another location to change any parameter we want. We can also use conventional parameters and then link to them using expressions. While this method might not be quite as nice as a fully customized interface, it will do for this article. Other options might include using an HTML page to display controls to drive parameters, or an ActiveX control, etc.

So that just leaves us with hiding objects from the various XSI editors. To do that we use this:

obj.SetCapabilityFlag( siNotInspectable, true);

The SetCapabilityFlag() method can be found on the ProjectItem object, which occurs near the top of the class hierarchy of the SDK. This means that a large number of objects support this method, including mesh objects, operators, clips, materials, properties, clusters, and many others. In addition, the parameter object also has this method, despite not inheriting from the ProjectItem object.

So here’s an example implementation of the apple Digital Asset.

In the end, I put in four controls.

The Deform parameter drives the amplitude of a push operator connected to a weight map to add variation to the shape of the apple. Since I didn’t lock the weightmap, you can still modify it using the weight paint brush to change the shape.

The Ripeness parameter drives an expression to control the color in the render tree (you need to render the apple to see the color change). Note that I had to use a “Vector Share” via a “Vector To Color” to drive the diffuse color, as XSI doesn’t let you put expressions on color parameters.

The Size parameter uses some basic rigging to change the size of the apple without changing the size of the stalk.

And finally, the Resolution parameter directly drives the Geometry Approximation to alter the subdivision level.

After hiding all the properties that I didn’t want the user to see, it looks like this in Explorer:

Note that I’ve set the Explorer view to show “Local Properties” so that we don’t see any inherited properties that would otherwise appear there in italics.

To hide the various properties that I didn’t want to see, I used a simple script that can be run from “Model->Get Property->Digital Asset Tools->Pick Objects to Not Inspect“. You can download this script below. When you run the tool, you pick items in Explorer that you want to hide with the left mouse button. Right click to finish and see them disappear. Note that I haven’t supplied a tool to make things re-appear again, so make sure you know what you’re doing!

Okay, so this all seems great. However there are a few gotchas that you have to be aware of:

• Once you’ve hidden something, you’ll have to use scripting to get it back again. There’s no other way.
• Don’t try to hide shared properties (e.g. ambient, the Scene_Root’s material, etc.) as it will hide all instances of that property. For example, if you hide the shared ambient property, you’ll find that the “Ambient” button in the Render toolbar won’t show the PPG to let you edit it.
• Only hide an actual object when you’re certain it’s not needed. In my example, if the user selects the Apple mesh and presses H, they can always unhide it by selecting it in Explorer and pressing H again. If you’ve hidden the actual object from the Explorer too, then the only way to get it back is to use the “Unhide All Objects” from the Display menu.
• Hiding individual parameters can be great for hiding them from editors such as the graph editor. BUT, be very aware that you’ll no longer be able to access that parameter from scripting using many of the conventional methods. This may well break numerous common operations in XSI, so make sure you research the implications of what you’re doing. You have been warned!
  (In fact, you can still access the parameter to unhide it again, but you have to do it by pushing it’s name into the Items property of an XSICollection)
• Duplicating the DigitalAsset model with Ctrl-D will lose any expressions that you’ve set up, unless you’ve enabled “Copy Animation” in the Duplicate Options. This can cripple your Digital Asset if it relies on expressions to do some of the work.

The most important thing to note, is that (to my knowledge) this technique has not been production tested inside XSI yet. This is a fairly non-standard way of working in XSI, and it isn’t something that Softimage would be expecting you to do. Hence there may be other gotchas that I’ve not found yet that could invalidate this way of working.

Having said that, it’s definitely a cool technique, and I hope that this or a similar type of workflow will be acknowledged or supported by XSI in the future.

I’ve uploaded the asset as an XSI 5.0 model (both the unhidden and the final versions of the asset), as well as the script for making your objects and properties hidden. To install it, you need to copy the script to your user/application/plugins folder.

DigitalAsset.zip

(Disclaimer: I’ve given fair warning during this article about the dangers of hiding things, so I accept no responsibility for any losses you may incur! Please take care.)

The first important step is to dissect our big problem into smaller ones, which will not lead to our half-artistic brain crashing. By following this rule, even a big thing such as a feather simulator can be prototyped without a degree in computer science.

This article is not a tutorial nor is it done to teach how to make the definitive simulator. It will just show a starting point for prototyping a small feather system and, hopefully, it will offer a good topic for discussing alternative solutions and approaches.

With that being said, lets start with our problem to solve: how to cover a mesh with feathers.

Feather instantiation

When I made my prototype I had in my mind one clear thing, it would be so simple to instantiate the feathers on a nurbs surface, it would be just a matter of offsetting each feather along U and V, XSI would then do the rest finding the XYZ cords of a UV point on the surface.

//Pseudo-code
function InstantiateFeathers()
{
    U_steps = 1/N1;
    V_steps = 1/N2;

    for(u = 0; u < N1; u += U_step)
    {
        for(v = 0; v < N2; v += V_step)
        {
            position_vector = GetXYZFromUV(u,v);
            CreateFeatherAt(position_vector);
        }
    }
}

However, most of the time, the object to be covered is a polygon mesh, so the situation is a bit more complicated, we have to recreate the UV space somehow.

A solution could be to group polygons in rectangular clusters and automatically generate an unwrapped UV map for each cluster.

By doing this it is possible to treat a poly mesh as a parametric surface, but we cannot rely anymore on XSI’s internal UV-to-XYZ function, we have to make our own.

This function will use two edges of a polygon to define a local cords system XY, once a point is located in the polygon’s local UV it is just a matter of tracing the same vector in XY space, maybe the image bellow explains it better.

Now that a way to cover meshes with feathers has been found, it’s time to think about how those feathers are going to be oriented along the mesh, the UV approach came really handy in the development of our next step.

Feather orientation

If the goal is to orient many objects with the minimum amount of work for the final user, then a solution is to control those objects with a small number of sub-controls.

The orientation and the scale of each feather is in fact the result of the interpolation between several control objects, lets call them “control-feathers”, with just a few of them it is possible to orient thousands of elements, even over time which means animated feathers!

Such an interpolation is based on the distance of a feather to its control-feathers, the nearer a feather is to its control the more alike is the feather’s orientation.

The unwrapped UV space used for instancing feathers along the mesh is perfect for calculating the distance between two points, even if the surface is curved as a cylinder, that in the case of a bird is pretty much a good approximation of our target mesh.

This system was used in production with great results, but the concept of separated polygon groups gave many problems.

It was time expensive to set up a mesh for hosting feathers, each cluster had its own control-feather set and it was quite difficult to maintain continuity along the seams, so as it often happens, once you’ve done the job, you find a better way to do it.

An alternative approach.

It is possible to get rid of the UV approach by sacrificing just a bit of control over the feathers’ distribution and bit of precision for the distance calculation between feathers and control-feathers.

In short, the instantiation process would be done on a per-polygon basis by virtually subdividing each polygon for a user defined N number of times, a weight map could scale in proportion this N value to give better control over the density.

To calculate the distance of a feather to its control-feathers we have to get rid of those controls that are too far and on the opposite side of the mesh.

For each feather we have to find the distance to each control-feather and set a tolerance range so that only those controls inside that range will be used for the interpolation, but still those controls on the opposite side of the mesh could be inside our tolerance range, so to get rid of them we have to play a bit around with the dot product and see what’s the angle between the feather and the controls, at this point we can interpolate even without the UV space being sure that only the right controls are going to be used.

Download the Test movie.
Download some shots from the short movie “Tricky & Ducks”.

I’d like to thank Paolo Martella and Daniele Niero, who worked with me to develop this system.
Bird model by Daniele Niero.

Once a character rig is complete it’s very difficult, if not sometimes impossible, to modify it without wasting a lot of time. What if we missed one bone in the middle of the hierarchy, or if we discovered that our rig’s proportions were wrong. The case is even worse if the rig we have to fix is made by another person, that huge amount of data organized in a hierarchy is going to be a puzzle, impossible to read and understand.

If a rig is made by a sequential series of instructions sent to the 3d application, which is what happens when making a character just using the graphical interface, we loose the history of what buttons we pressed. In other words, we loose the source code of our work. Saving the content of the log window is not the solution, we would end up with a mess of commands that don”t really describe what our character looks like, it would be just a long linear list of actions.

For example:

1
2
3
4
5
6

Create2DSkeleton(-3.758, 0, -0.310, 0.107, 0, -1.72, -90, 0, 0, 4, null, null);
SetValue("eff.kine.local.cnspos", false, null);
SetValue("eff.kine.local.cnsori", false, null);
ParentObj("bone", "eff");
AppendBone("eff", 3.78, 0, -0.167, null);
ParentObj("bone1", "eff");

Would you say that this is an arm?

A rig as a piece of software.

The new generation of scripting languages like JScript, Python or VBscript offer almost all the structures to model our code as other lower level languages as c++ do. Those languages are object oriented, it means that instead of having our code as a sequence of actions, we can model objects to describe the reality in complex structures still easy to be read.

So, how can an object oriented language helps in defining a rig?
Here is an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

function Arm() {
    //Public Properties:
    this.Name = "arm";
    this.ShoulderPosition = XSIMath.CreateVector3();
    this.ElbowPosition = XSIMath.CreateVector3();
    this.HandPosition = XSIMath.CreateVector3();
 
    //Private Properties:
    var armComplete;
 
    //Public Methods:
    this.Create = function() {
        var armChain = ActiveSceneRoot.Add2dChain(
                            this.ShoulderPosition,
                            this.ElbowPosition);
 
        armChain.AddBone(this.HandPosition);
 
        armIsComplete = true;
    }
 
    this.SayHello = function() {
        if (armComplete == true) {
            LogMessage("Hello, I''m " + this.Name + "!");
        }
    }
}

This is a JScript object, the equivalent of a class, it is describing our arm using properties to collect the data we need and methods to take care of how this data is used.
Now let’s create an instance of this arm in scene:

1
2
3
4
5
6
7
8
9

var myArm = new Arm();
 
myArm.Name = "HelloArm";
myArm.ShoulderPosition.Set(0,0,0);
myArm.ElbowPosition.Set(3,0,-0.5);
myArm.HandPosition.Set(6,0,0);
myArm.Create();
 
myArm.SayHello();

Here we are, we’ve got our HelloArm which is an instance of an Arm object, proceeding in this way we could create a leg object, a spine object and then use all these objects from a human object.

After the first rig will be coded it will be really easy to make new creatures, modify our base human object and treat all those files as shared libraries that everyone can use and flex to the production needs. In such a workflow a character rig is nothing more than a piece of software and XSI is our compiler.