Why would I use ICE for rigging?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  04 April 2011
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:
  1. ICE is simply a visual way of creating a resuable procedure or method
  2. There is nothing I can do in ICE that I couldn't do in Python or C#
  3. 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...?
__________________
“Every child is an artist. The problem is how to remain an artist once we grow up.” - Picasso
 
  04 April 2011
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:
  1. Draw bone chain.
  2. PROFIT!
ICE way:
  1. Make two nulls thatlook like bones (or use implicits).
  2. Make two nulls and parent them together to make the FK controllers.
  3. Make two more nulls, a root and an effector.
  4. 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.
  5. PROFIT?

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:
  1. Store the resting length of each bone somewhere.
  2. 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.
ICE way:
  1. Store resting length etc...
  2. 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.

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:
  1. Delete the expressions you had for the stretchy IK.
  2. 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.
  3. Test it, debug it, fix it, rinse and repeat.
  4. 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++.
ICE Rig:
  1. 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.
  2. PROFIT!

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.


HTH
__________________
website | twitter

 
  04 April 2011
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...?
__________________
“Every child is an artist. The problem is how to remain an artist once we grow up.” - Picasso
 
  04 April 2011
Originally Posted by MarkInTx: 1) How is ICE faster than Python? Does it compile itself under the covers or something?

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.

Originally Posted by MarkInTx: 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...?

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.
__________________
website | twitter

 
  04 April 2011
Originally Posted by ShaderOp: 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?
__________________
“Every child is an artist. The problem is how to remain an artist once we grow up.” - Picasso
 
  04 April 2011
Originally Posted by MarkInTx: 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

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. : )
 
  04 April 2011
OK... thank you ShaderOp and ViCoX!
__________________
“Every child is an artist. The problem is how to remain an artist once we grow up.” - Picasso
 
  04 April 2011
http://renatopolimeno.com/m-a-r-s

=)
__________________
Website
Twitter
Facebook
Google+
 
  04 April 2011
Originally Posted by Polimeno: http://renatopolimeno.com/m-a-r-s


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

I will follow your progress...
__________________
“Every child is an artist. The problem is how to remain an artist once we grow up.” - Picasso
 
  04 April 2011
Originally Posted by Polimeno: http://renatopolimeno.com/m-a-r-s

=)


Really looking forward to what you come up with, looks like a great start
__________________
www.matinai.com
 
  04 April 2011
http://vimeo.com/21151418
Heres good example of ICE rigging. : )
 
  06 June 2011
reply ICE M.A.R.S.

Originally Posted by mattmos: Really looking forward to what you come up with, looks like a great start

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

Originally Posted by MarkInTx: It's good to see this project, thanks for the link!
I will follow your progress...


Thanks for the kind words Mark ! Mohammad and Juhani did give you a good explanation =) I want to share some thoughts aswell:
my thread:
http://forums.cgsociety.org/showthr...p?f=54&t=938877

the mailing list topic:
http://groups.google.com/group/xsi_...f45048c84?pli=1

__________________
Website
Twitter
Facebook
Google+
 
  08 August 2011
Originally Posted by MarkInTx: 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.


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.
 
  08 August 2011
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?
__________________
“Every child is an artist. The problem is how to remain an artist once we grow up.” - Picasso
 
  08 August 2011
Originally Posted by MarkInTx: 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.

Last edited by andymoorer : 08 August 2011 at 03:30 AM.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 04:30 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.