Why would I use ICE for rigging?


Hi All, I am trying to understand the ICE thing. I see some purposes for it… but I can’t understand why I would want to take the time to learn ICE and rig in it in place of the tools that already exist in XSI for rigging… so I am probably missing something and I’m hoping someone can fill in the blanks for me.

It appears to me that:

[li]ICE is simply a visual way of creating a resuable procedure or method
[/li][li]There is nothing I can do in ICE that I couldn’t do in Python or C#
[/li][li]ICE only accesses tools and properties that are already available, anyway

Coming from that as a premise (which surely might be wrong) I am trying to understand why I would want to build an ICE rig? I can understand, I guess, creating something to be used in conjunction with the typical bones and envelope rig… but why would I replace it with an ICE rig?

I am sure that it offers more flexibility… but can’t you start a rig in the traditional way and then add scripting or ICE to add the flexibility? Wouldn’t that be faster?

It seems to me that ICE would be somewhat less reusable than a “classic” rig…?

Yet, Softimage seems to be moving in the direction of “All ICE, all the time…” So I must not understand its capabilities.

Can someone help me out here…?


Since you’re asking specifically about rigging, let’s frame the discussion with an example of creating a two-bone leg, i.e. just a root, two bones, and an effector.

Classic way:
[li]Draw bone chain.[/li][li]PROFIT![/li][/ol]
ICE way:
[li]Make two nulls thatlook like bones (or use implicits).[/li][li]Make two nulls and parent them together to make the FK controllers.[/li][li]Make two more nulls, a root and an effector.[/li][li]Build an ice tree that uses the last two null to drive an IK solver node and blend the position of the bones between the results of the IK solver and the FK controllers.[/li][li]PROFIT?[/li][/ol]

Which is absurd of course. Classic bones win hands down.

  But if you try to take it further than that, the scale start to tips to the ICE side. Say you wanted to make the bones stretch in IK mode.

Classic way:
[li]Store the resting length of each bone somewhere.[/li][li]Put an expression on the length of each bone that take the distance between the root and effector and the resting length of each bone to do its magic.[/li][/ol]
ICE way:
[li]Store resting length etc…[/li][li]Pipe the output from the last node in the ICE tree you made previously into another node that outputs the length of each node and the modified position of the effector.[/li][/ol]

ICE has the added convenience of all the computations take place in a single ICE tree instead of having them spread across two expressions buried somewhere in the bones’ property sheets. I think this is a major advantage when you have a sprawling hierarchy of bones and controllers that would require a metric ton of expressions spread all over the place in a classic rig compared to just one ICE Tree in the case of ICE rigging.

 Now take it up one more notch. You test the rig and the knee is popping all over the place in IK mode. This won't do so you decide to implement some sort of Soft IK solution.

Classic rig:
[li]Delete the expressions you had for the stretchy IK.[/li][li]Code some kind of solver in Python or what have you that adds a bit of cushioning as the distance between root and effector approaches the full length of the leg.[/li][li]Test it, debug it, fix it, rinse and repeat.[/li][li]Apply the solver to the bone and pray that the performance doesn’t suck too much so that you don’t have to recode it in C++.[/li][/ol]
ICE Rig:
[li]Pipe the output from the last node in your ICE tree into another node that does the stretchy IK calculations and outputs the modified position of the effector and length of the bones. Performance is almost guaranteed not to be an issue and you’ve just given the 15 idle cores on your machine something to do.[/li][li]PROFIT![/li][/ol]

So I think ICE rigging only shines when you start adding features to your rig that go beyond simple IK/FK. It’s more modular, allows you to experiment with different solutions, simplifies the rig hierarchy, lets you put the whole rig logic in a single ICE tree for easy access and modification, and is going run faster then scripted operators and almost as fast as C++ operators.



OK… that is real good feedback.

Two questions:

  1. How is ICE faster than Python? Does it compile itself under the covers or something?
  2. How portable is it to another mesh? Let’s for sake of argument say the the other model is similar… like both are bipeds, but difference scales and proportions…?


No, no compilation takes place on the ICE trees as far as I know. But think of it this way: A highly specialized programming language like ICE will always have more opportunities for performance optimization compared to a general purpose programming language like Python.

In the case of ICE, the biggest performance boost probably comes from multi-threading. ICE splits point cloud into chunks and runs each chunk through the ICE tree in its own thread. The SDK Guide explains the process nicely.

I’m not sure what you mean by portability here. An ICE spine solver for example will be portable across rigs if it doesn’t make any assumptions about the length and number of segments in the spine. But you still have to provide it with the right inputs. I would say that ICE rigs aren’t any less portable than classic rigs.


Well, when I look at something like the GEAR tools, for example, I see a way of having components available that can be reused pretty easily.

I’m not clear as to how I would do that in ICE. I realize that I can reuse an ICE tree, but it seems to me that it is very constrained by the groupings – which are not visual. What I mean by that is in order to use the spine in GEAR, I visually draw it over my model… but I don’t know how to do that in ICE. It may be possible, but I thought ICE could only access something that already exists… not be drawn on… But this may just be my misunderstanding… I really don’t know much more about ICE than what I have gleaned by watching Paul Smith’s (Pooby) Vimeos

In other words, if I have a group of vertices that make up a “Bicep” I see how I can have an ICE tree moved from one model to the next – but that more or less assumes that they are the same scale – doesn’t it? Wouldn’t changing the size – or much of the geometry – impact an ICE rig more than it would a conventional rig?


You cannot do drawing sessions or logic like that in ICE.
ICE is like one huge customOperator doing calculations. However, you can make compound that is based on some basic bone stucture and you use that as a refrence in the ICE tree.
In that way, ICE is not replacement of scripting. : )


OK… thank you ShaderOp and ViCoX!





It’s good to see this project, thanks for the link!

I will follow your progress…


Really looking forward to what you come up with, looks like a great start :applause:


Heres good example of ICE rigging. : )


Thanks mate !
I´ve added your twitter, vimeo and liked your fanpage.
Keep in touch, cheers :slight_smile:

Thanks for the kind words Mark ! Mohammad and Juhani did give you a good explanation =) I want to share some thoughts aswell:
my thread:

the mailing list topic:



To give another take on your question…

ICE will be unlikely to replace entire rigs, but ICE is already used in rigging work quite a bit, for a number of reasons:

  • It is an excellent way to obtain and manipulate data within softimage. You can get to, manipulate, and operate on pretty much any parameter in the application.

  • But that’s true of more traditional programming languages, too. The thing is, developing in ice is quicker due to it’s modularity. For instance, on a project not long ago we were able to use ICE to control sculpted corrective shapes on the enveloped mesh (like you would with an expression) but to also set up a fast way to paint those corrections, mix them with additional deformers based on raycasting to prevent passthru, add some dynamics and make the entire thing camera aware so that processing time wasn’t wasted when characters were offscreen etc. The whole thing was built and operating in an afternoon, because we were able to leverage a library of custom compounds. On another project the lead TD was using ICE to handle various aspects of facial animation, and he had a great setup to handle sublties like eye bulge under eyelids and the movement of the larynx under the skin of the throat.

ICE is like other types of scripting and programming in that once you get past a certain point it opens up huge vistas of possibilities. A lot of the people I know using ICE are also adept programmers. ICE is another tool, a fast way to create and implement custom operators. Unlike scripting or c++ etc ICE is entirely visual, which means you are spending far less time on “syntax” and far more focusing on the actual task you are trying to achieve.

ICE kinematics are just another area you can get into. Don’t like how a normal IK/FK bone works? Build your own, that follows the rules you want. It’s fast enough to develop ICE logic that it becomes entirely feasible to write your own solvers and constraints on the fly.


I understand what you are saying… And I see where ICE is useful in rigging (or what have you).

But I guess I still don’t get why it is so hyped. It’s just a GUI interface to a programming language… right?Is there anything you can do in ICE that can’t be done through the SDK?


Hmm, well it’s not what you can do so much as how you do it, and how fast you can do it. It’s not a gui to a programming language, but the underlying language itself, as well as the gui. If it was just a nodal front end used to generate code, like say mental mill, it would be welcome but nobody would be that excited.

Bear in mind, the hype is following the usage, while it had the usual rollout hype it didn’t become shouted from the rooftops until it became obvious to the marketing droids that it was immensely popular.

In other words, ice really IS amazing, in this case the hype in some ways does more harm than good, because it masks a significant development in the state of the art. {edit/unreliable information has been removed}

I’ve seen a pattern over and over, skilled TDs who are dismissive of ice until they end up using it in a production scenario, and a year later practically live and breathe it. It really is that useful. I wouldn’t say it’s superior to traditional scripting or programming, it fills a different niche that hadn’t even been defined before ICE came around.

Anything you do in ICE can be done via the traditional SDK, just like anything you do in soft can be done in max, maya, houdini or blender. But the experience is different, and you can’t really define that without trying it out yourself. :slight_smile:


I don’t understand what this means… how can it be a GUI and a programming language?

Doesn’t ICE, at some level, generate code? For example, Java is taken down to byte code that ends up getting executed – so does C#, Python, every language I know of (unless it is simply interpreted at runtime, which I am assuming ICE does not…) Isn’t ICE just another language, expressed through a GUI tree-like interface, that ultimately becomes byte code that Softimage recognizes?

I guess what I struggle with is that I am not a TD by profession, but rather a programmer. And I worked on a team that worked for a long time to create a tree GUI interface for a modeler we had… it worked OK. But in some instances, the metaphor broke down, and the users ended up asking us for a scripting language so they could code the parts of their stuff in a scripting language instead of using the GUI. What we discovered was that the GUI was a nice introduction to the scripting language, but at the end of the day, complex ideas needed a language – not a GUI – to be fully expressive.

So, I’m trying to understand how ICE succeeds in getting around that complexity barrier…?

(BTW, I appreciate your responses, because heretofore, ICE has sounded almost mythical… you seem to really understand what it does, and I’m hoping to get a better understanding of it, as well…)


I wouldn’t say I have any kind of deep understanding of how it works from an architectural perspective, I’m closer to an artist than a programmer. But my understanding is that the base level nodes are precompiled, with the lowest-level nodes built to execute as fast as possible. The tree structure of compounds and trees is, I think, compiled “just-in-time.” But I may be mixing that up with the fabric engine, which kind of takes the general idea of ice further into the realm of application development.

But yes, it’s all converted down to byte code, you can write and edit compounds by hand in human-readable text. However I haven’t run into a case where I or anyone I know has had the metaphor break down to a point where they would rather edit in text…

ICE is built at a very low level, with the same kind of basic functions you would expect from any programming language … build arrays, an extensive library of math operations (basic, comparison, logic, matrix, vector, trig, statistics) data typing (boolean, color, integer, scalar, euler rotation, quaternion, string, 2d/3d/4d vectors, 3x3, 4x4 and arbitrary matrices) execution control (if, case, while, iterative repeats, filtering etc) pretty much anything you would expect from a mature programming language. It just happens to be expressed visually in a node graph rather than through textual syntax, to a degree that you really rarely feel a need to even look at any text. There’s a sense that the gui IS the code, if that makes sense.

I’ve heard one skilled programmer call ICE “a programming language used to build custom operators on scenegraph objects.” Another tried to describe it as “a framework for manipulating large data sets.” The best evidence that it’s a new way of thinking is this very difficulty in describing it to someone who hasn’t used it enough to really get a feel for it.

The immediate trappings people see are a node graph, which is hardly uncommon, and so they tend to assume ICE is akin to “X”… which can cause some confusion. Some people are convinced ICE is just an advanced particle system like thinking particles, others think it’s a GUI reflecting a scene graph like maya’s hypergraph, and others expect it to be a GUI-based code-generator like mental mill. There are elements of all of them in ICE, but at it’s heart it’s a programming language and underlying engine optimized to manipulate data sets (be they freestanding points, topology, UV sets, or some abstract data set defined for a specific conceptual purpose.)

Kinematics in ICE is just the extension of ICE to get and set kinematic data in softimage, and a library of functions helpful for kinematics work. Having built the programming language, ICE, softimage is gradually extending it. It started with particles, then kinematics, now topology and UV data, and so on…

I hope this helps. This is just my take on things, there is a 100% probability that some of what I’ve said is incorrect, but I’m doing my best to reflect the understanding I’ve gained from a few years using ICE.

As an aside, as a freelance TD I’ve never been busier. I am turning down work every week because I’m constantly overbooked. ICE is being used a lot more than is obvious, and by some of the best studios around… yet there are relatively few people focusing on work in ICE, so the demand for us is ridiculous. At the moment I am working on a feature film effect sequence, two national broadcast commercials, I’m on hold for two more (holds instituted by myself, I’m overbooked) and I’m turning down incoming jobs automatically at least once a week (some for studios I would kill to work for, sob.) And I can’t even pass names along, because the other ICE-guys are just as busy.


Thats interesting. Where did you get this information? I try to follow Phils doings, but hes not too active posting in the net : )


Sorry Andy, but you might be getting your history a bit messed up there :slight_smile:
ICE was not originally created or designed by Phil. Phil came on board much later in fact.
ICE was created before the acquisition, and was never originally created to work equally well inside Maya and Max, in fact I seriously doubt that’d be something that could happen anytime soon, even if they whised it to, as it’s got some deep ties to the way Softimage deals with its internals.

Phil, AFAIK, was on board as a designer on the character side of things, but didn’t contribute to ICE’s codebase. He did contribute a fair few compounds during and after the ICE kine beta stage, but not higher upstream than that.
Not 100% sure, maybe something of his has actually found its way further up, but I’d be hugely surprised if it was anything affecting the design or the architecture to such a fundamental level as you suggest.

Phil’s figure has always been a lot closer to that of a TD than that of an RnD person (which is what made him so good to have around actually, beside the fact he was a greatly helpful and active person on all channels)
The daddies of ICE (some still in Soft, some moved on) are a completely different set of people.

It’s a fairly dangerous comment you posted there :slight_smile:

Some of the other details, while I see what you’re trying to get across, are also fairly muddy.
The GUI and the “language” are not one. ICE is a graph evaluation system leveraging the best out of a particular architecture, it is not its gui.
There are in fact some pretty deep idiosyncracies between its internals and its GUI, and things such as iteration and arrays are highly artificial constructs compared to what something like ICE deals well with.
That makes it considerably different from a classic programming language, and using it as one is going to get you sore soon.

There are also no distinct levels of implementation.
You have a graph eval, and you have nodes.
All nodes are written in the same language and against the same API. Things such as compounds are purely GUI and management supersets for user convenience, but after interpretation there is no such distinction.

All the API exposes is the templates and constructors and all to create nodes, and that’s it. Nothing else is accessible, which makes it again very different from programming languages. It is a lazily evaluated acyclic graph with explicit connections, it’s good to remember that when working with it.

And lastly, no, not everything you do in ICE can be done in the SDK when you set the boundaries to what it’s reasonable to do, and viceversa.
IE: try using the SDK point locators to sort out data VS what you can do in ICE, the difference in performance is in the order of 80x for us on our current show.
Conversely, try doing blind data retrieval in ICE (trivial in the SDK) reliably. It’s just not built for it.

ICE creates encapsulated graphs evaluated one at a time and threaded internally, and is completely ignorant of the scene besides what you explicitly tell it to look up. It’s practically the polar opposite for adoption and ease of implementation of the SDK. It’s somewhat closer to OPs in XSI, not the entire API with its scene components, stack etc.

Good posts in general, and please don’t mistake this for a personal attack or anything, just some of the info is the kind of stuff that starts dangerous and unfounded rumors :slight_smile:


I stand corrected. :slight_smile: As I said, I knew my understanding was flawed, so I’m glad to get your correction. Much of my information comes from other TDs and clearly has gotten muddled in too many retellings. That’s one of the problems with the Softimage community, we’re all so spread out, a lot of information goes word of mouth from person to person. That’s one of the reasons I like to post conversations like these in public forums, so others can jump in and set me straight. :wink:

But I hope on the balance I did more good than harm in trying to explain why ice kinematics in specific and ice in general is worth examining, even for non-Softimage users. (I am disappointed to hear you say it isn’t applicable towards Maya and max, however. I had been told that pretty firmly by some folks in special projects in fact, so I had taken it as the straight dope. Just goes to show that word of mouth can’t be relied on.)