XSI as a compiler!

June 15th, 2005 by Andrea Interguglielmi - Viewed 16799 times -

Usually the common behavior for a character TD is to create rigs in a visual way: pressing buttons, dragging and dropping relationships and so on. Unfortunately this is the most diffused way to approach character rigging, it leads to a few issues and surprisingly, it could be the wrong way to go.

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:

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:

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(
        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:

var myArm = new Arm();
myArm.Name = "HelloArm";

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.

18 Responses to “XSI as a compiler!”

  1. Quite a few of the more technical riggers have been doing this for a while.

    Meanwhile, the point that you get across very clearly is that it can be kept quite simple and offer a great deal of flexibility in the long run!

  2. I think this is going to be a really hot topic over the next few years, everyone tries to protect his skills, but what is the real way to go? if there is one… ; )

  3. Helge Mathee says:

    To me it seems that this technique also offers a lot of options for a rigging-team.

    As far as protection of skills goes: Inspiration and development of new techniques is far more important if you ask me.

  4. So if I understand this approach right, you never “physically” edit (ie edit in 3D) the rig, but instead make modifications to the code and regenerate the rig everytime?

    If my understanding is right, then I”m not sure I grasp the full potential of this solution. I kinds of set us back in the times when interactive 3D work was non-existant. While I can see the advantage of using this approach in terms of trouble-shooting, isn”t it defeating the purpose of 3D tools? What would be such advantages brought to rigging teams and how “flexible” is this approach compared to the interactive one?


  5. Bernard,

    I think the idea isn”t necessarilly to constantly create everything in scripting but to encapsulate portions of rigs that can be reused into scripted blocks. First you create visually until you have found your direction, then you encapsulate rig parts in scriptable components for ease of reuse and rebuilding – if needed.

    One of our riggers here created a really cool tentacle type thinggy rig that was repurposed for an underwater dragon”s tail, a little cartoon flame and the tentacle of an octopus. Having this block of rig as a script could easily allow a rigger to reuse the concepts and quickly build complex rigs.

  6. Anthor says:

    It seems like a lot of work, but it ”front loads” the effort. Each change to the rig or regeneration of the rig requires a small fraction of the effort required to make the rig in the first place.
    This makes it practical to regen the rig very frequently as opportunities to improve it arise.
    Think about having 150 characters, and how you are going to keep them viable through a production….

  7. Guy Rabiller says:

    Now, imagine that each ”Class” is represented as a ”node” in some graph view similar to the rendertree.

  8. loocas duber says:

    Very interesting! Though I”m not a XSI user, I can see this in the app. of my choice. Thanks for the article Andrea.

  9. I”m glad you”ve found it interesting Loocas, thanks to Patrick who cleaned up my bad italinglish from the article ; )

    Ciao Guy, are you working on something like that? ; ) … I”ve seen somewhere a python visual editor working in such a way…I can”t remember where…

    At the moment I”m very happy with this worflow:
    Visual studio
    A character is defined inside an XSI plugin, the new plug-in system is perfect for managing characters
    and JScript as main language.
    I”m just missing an include statement and probably this will force me to move on python…I”ve got serious problems with its syntax, Patrick, don”t get mad at me :D

    Really Looking forward to have DotNet\Mono APIs…

  10. Shorty says:

    Been doing this for a while, as much as anything it makes sure things are clean. Especially in a node based package where you can end up with loads of dud nodes, or objects floating around that will bog down a scene or even just make it larger than nessicary. Also you can use sensible values on angles and length, it makes it easier to see what you”ve done or what someone else has tinkered with.


  11. David says:

    I can see the beauty in this have much experience in web content management and development. This type of coding with JScript is amazing and I think many XSI users should take advantage of it. Just image building a body in six different parts and using the JScript to make changes on the fly instead of reanimating each movement. I can see different body parts accually being combined with different nodes with the JSciprt instead of re-rigging!!!! Taht is 2 Kool!!!!!!!!

    I also understand the XSI has a XML parser as well which makes the software 100x”s more powerful. being able to create a unique scripting invironment is critical to realtime and runtime production and development. I hope that many take advantage of this modular content development framework that Softimage included in the latest release of XSI.

  12. teanau says:

    quote: Guy
    “Now, imagine that each ‘Class’ is represented as a ‘node’ in some graph view similar to the rendertree.”

    anyone would think you were working on an fx tree!?



  13. Michal D. says:

    Thanks for sharing. Isn”t is similar to what Character Develpment Kit scripts do (and XSI built in rig)? I use similar techniques (well, use as I learn more likely :)) for some additional things on my rigs, like setting up shadow bones and names. This article inspired me to try to write some simple procedural arms and legs. Next thing would be to tackle a spine :).

    Do you mind if I ask how do you drive all of this? Do you have some sort of template/guide rig then generate real one based on guides?

  14. Chris says:

    On a large scale the time savings are huge. Not only is it quicker to rig, due to similar naming conventions, but you can also take advantage of animation library”s. In a case I just tackled, I had to animate a shot of 70 different characters in one week. I made a small library of animations like David suggested. I animated a few tails, a few different 4 legged walks and 2 legged walks and few different facial animations. Then I cut them together in the mixer. I would never have been able to do that if the naming conventions from one character to another weren”t the same.

    I”d be curious what some people”s thoughts are on implementing this kind of pipeline in a small commercial house. Again I can see the benefits no question. But in a situation where one week your animating a cereal box, the next week a talking wallet, then a 4 legged character. Every job being done by different artists, some freelance, and more often then not by someone with no scripting skills. Is it worth the time invested, and the babysitting of artists to properly name things, when it”s just a one person job that”s gonna take 3 weeks, and the files will most likely never be opened again? Coming from a small shop, where some people tend to be lazier then others, it would be difficult to implement. Just playing Devil”s addvocate.

    To answer Michal D”s question. It”s as simple (more laborious then simple on the scripting side) as using nulls for positioning. So a null that is representative of each joint and in cases of legs arms nulls for up vectors. Each of the nulls is representative of where a joint starts and ends.

  15. It is absolutely possible for a big production to function without rig assembly via other non-linear application of other departments contributions, but if those tools also accomodate changes thru a non-linear pipeline then it becomes a indespensible tool allowing assets to be sent back thru the pipe quickly.

    I”m with Guy on this one, a node graph would really help.
    A node graph of classes returns to rig assembly some of the interactivity we experience when creating the rigs in the app thru the gui interface.

  16. I”m working on a 3dsmax automated rig at the moment that is working in two stages. The first creator is effectively a button that when clicked allows you to drag out a bounding box in your viewport (width height and depth are set to match the bounds of a character mesh). As you finish making this the script generates a set of points in the viewport based on regular human proportions. The points are then moved into their correct locations on the mesh and another button is pressed which will set up bones and helper controllers based on the naming conventions of the original points.

    I”m interested in getting an XSI version up and running too as one of our main animators here prefers XSI to animate in – I”ve got an exporter written for max that can pull out fcurve data for objects to text files so I”m working on getting a standardised rig setup that operates the same in max and XSI and can export it”s animation lceanly between the two (I dont want to do an fbx key on all frames type style)

    I”d be very interested in how the interface is designed in XSI as the version I”m doing now is really off the top of my head rather than experience from a big facility.

  17. Guido Zimmermann says:

    just wanted to share some thoughts with you about this article:

    this approach of creating a rig by using script functions rather than just “clicking it together” is the only way (I could think of or have experiences so far) to have rigs for a big production (like a full animated feature movie). Only this way a team of many people rather then just one person can work and modify on many complex rigs. I know that the beginning can be a pain in the butt with this approach but this way you can modify everything at any time and everybody in the team can do it (try that with a “clicked together” rig!).

    I am very happy to see that the XSI comunity is heading this way now and I love the tools (scripting) XSI provides us with. Unfortunately we do not use XSI here but I can tell you this much: our pipeline (proprietary) has always been this way, more scripting then clicking, and it proved to be very efficient.

    In a way you are doing riging on a higher level. Rather than always starting from scratch you are inheriting functionality from more basic “body parts” or classes and you can develop very powerfull modules for rigs.


  18. Michal D. says:

    I’d be curious what some people’s thoughts are on implementing this kind of pipeline in a small commercial house

    Hey Chris. I am freelancing mostly for small/medium sized commercial houses over here and currently I am in the process of implementing some of those concepts for my own enjoyment and speeding up my work. I usually find myself in a situation when I have to rig a character quick. Most of characters I work on have arms and legs, and are symmetrical, so having a script which will build an arm and symmetrized it using common naming conventions saves me a lot of time. I also color code my rigs (left side blue, right red etc) use boxes as shadow bones for arms, cylinders for hands etc.. small things but speed up animation a bit when added. Not to mention I am always sure about names and groups etc… in fast production it gives me more time to animate later and of course I can reuse my animations if I want.

    I have idea for reusable simplified face rig as well, one would have to model some common, predefined shapes and the script would do the rest, but it”s long way… need to learn a lot to be able to do it.

    Of course most important thing is that I learn scripting a bit doing it :)