Why would I use ICE for rigging?


I have no access to the internals and my knowledge is limited to what a handful of developers or support staff in the know can discuss publicly, or on project supports lists, so my word shouldn’t be taken as gold either.

That said, I’m sure the actual architectural/graph eval side of ICE could be decoupled from Soft with relatively little effort if it’s been written for that, and I’d be surprised to hear it wasn’t.
There is a chunk more though that I’m sure would need work before it’d become as fruible as it is in Soft, and a number of things are so inter-related with the way Soft encapsulates and offers data, that they would feel utterly awkward in Maya. That would need work.

ICE is still a complex and powerful Operator encapsulation system when you really, really get down to it. And Ops the way they work in XSI are very different from how you work in Maya. Max, I wouldn’t know, but it always seemed to me like it was written by aliens (with a large hive mind where no two cells agree), for other aliens :slight_smile:

I also have no doubt that since the acquisition AD has been looking into it, and maybe even enabled that decoupling work to go on in B time or in the background.

I was mostly saying that stating it was designed from the ground up to integrate with Max and Maya in the future is obviously incorrect, if for nothing else, at least for the fact that ICE pre-dates the acquisition by several years if you talk inception, and over a year if you talk deployment :slight_smile:


Makes sense… In fact I first heard about ice (though of course not by that name) was around the time I was finishing rigging for the barnyard film (I gather I missed seeing you there by about a week.) :smiley: Years later when it became a reality, I had been given the impression much of it was an early acquired technology originally intended to be offered for all packages, but there was a lot of misinformation early on as people tried to wrap their heads around what exactly it was, so no doubt stories got crossed.

As someone with more formal CS knowledge than myself, to what extent would you say ICE is “new,” in regards to being an innovation which can change computer graphics? One of the areas I often have trouble with when describing why ICE is, for me at least, a very liberating way to work is that usually the people I’m talking to have trouble visualizing ice as anything more than another node-based gui. Houdini folks usually get it but with most people I just have to urge them to try it…


ThE_JacO, thanks for your contributions to this thread, I understand the differences now.

Andy, I also thank you for getting the ball rolling here… this is really good stuff that helps me understand ICE’s role much better. (And I hope others coming by and seeing the thread understand it better too…)


Actually a 2 bone chain is much simpler than that with ICE:

  • Make two implicit bones [parented for FK]
  • Make a null [the IK target]
  • Make another null [call it ICE Rig for example]
  • Build an ICE Tree on the ICE Rig null using a 2Bone IK Solver node

You have to place the ICE Rig Tree on an object that’s not apart of the chain. That’s why you need that extra null. The object that holds the ICE Rig Tree does not have to be a null, per say, it could be any other object, a pointcloud for example.


Small OT

@ TwinSnakes

It is Latin “per se” not “per say” which doesn’t exist.



This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.