optimizing ICE kine tree's

[missingkey]

Hey All,

I'm working on some custom rigging stuff inside ICE, and I have most the functionality nailed down, but am now looking for way to optimize my ice tree.

There's basically just alot of vector math, and decomposing/rebuilding global and local transforms.

I'm not really setting much data at the end of the tree, but there are connections everywhere. I know I can use 'custom attributes' inside an ICE tree, and am wondering if this will speed things up more? or make the tree more editable, or less readable? Or what your thoughts are?

Things are broken down into logical sections, and I could easily set and get custom attributes to alleviate some of the connections. But is that really any quicker in this case?

Thanks!

[EricTRocks]

Not that I know of. One thing to remember is that unless you're processing arrays of data you will probably get hit with some performance degradation compared to traditional rigging methods. Use ICE Kine sparingly and only when you need something the built in tools / traditional methods won't get you.

[missingkey]

Hey Eric, Thanks for replying. It makes sense to use the built in IK solvers for basic things and performance. But what about when an arm rig starts getting weighed down by multiple IK chains, dozens of nulls, and lot's of constraints, all blended together to form some sort of solution, vs. building the solution into the math/functionality of the solver itself. Do you think speed still favors the traditional method? I know I should test it out, just wondering what others have figured out before me.

I'm sure there's lots of information on this, I don't mean to start yet another thread on ice kine. Perhaps a scripted operator is a better solution?

[EricTRocks]

First question would be, how do you know it's getting weighted down? What are you using to calculate the performance of just that component of the rig? The scene debugger is quite useful for this. I'd see what it shows as being the major calculations being done.

You should also look at your rig setup and see if you actually need everything in it. In this respect I'd first ask you why you have multiple IK chains in the same component of the rig? You should only use bone chains when utilizing the IK functionality. If you're not, you should be using a hierarchy of nulls that blends between the IK and FK solutions. When in FK the IK chain does not get manipulated thus gets rid of useless cycles (even in FK mode it can still be churning away).

Unless you're pulling / setting arrays of data like arrays of transforms for the entire rig and setting back to an array of transforms that drive deformers then I'd say it's likely you'll still get better performance out of traditional methods.

With that said, and as you know you'll have to do your own bracketing / testing of the different setups. There honestly isn't a lot of information out there on this topic but I do keep seeing tons of ICE based rigs being showed off on demo reels yet they don't show the frame rates that the rig can do. I don't see comparisons between the traditional setups and the ICE setups either to justify why it's being done in ICE.

Lastly, ICE can be useful if used the correct way. You just need to test, get stats, and compare.

My 2 cents and I'd love to hear some other experiences of those out there who have rigged with ICE.

[missingkey]

Hmmm, well I'm not exactly sure if the setup is all that heavy to be honest. I came across custom ICE attributes about half way through, and all of the sudden optimizing became the focus, lol.

My brain must have blanked when I was typing multiple IK solvers. lol. yeahhhhh. ;)

Well, I'll continue to do some tests. In the meantime, here's one of the IK solvers I've been working on. I'd love for someone to play around with it a bit, and tell me what you think.

It takes a few inputs, so I've provided a model, with an arm setup.


It's funny, I somewhat remember when ICE was first released, there was all this talk about how it was going to revolutionize rigging. As if entire character rigs we're going to be contained within one node, with various control inputs. A hierachy of controllers, deformers, and an Ice tree, without all the secondary nulls and constraints and hierarchical restrictions.

Is Ice used much in Species?

[EricTRocks]

ICE is NOT used in Species at all.

A rig CAN be built with ICE entirely like you suggested if done correctly. You should look for Phil Taylor's example videos and also the ICE_Rigging example workgroup int he SDK folder of the Softimage install.

[missingkey]

ICE is NOT used in Species at all.

A rig CAN be built with ICE entirely like you suggested if done correctly. You should look for Phil Taylor's example videos and also the ICE_Rigging example workgroup int he SDK folder of the Softimage install.

you sound pretty adamant about not using ice in species. I'll admit, I'm not too familiar with it (species), but is there a reason for zero ice? Just curious really.

anyhow, I checked out some of the kinematic examples, and while they're somewhat helpful. They're still just simple examples. Don't get me wrong, I'm super happy for having them. It's just harder to understand things sometimes when the application is so simple. now i'm just yapping...

anyway, I managed to speed up the tree a bit, by basically just reducing some redudant nodes, and simplfying a few things. nothing fancy. I updated the previous file, but I think everyone has lost their interest in ice kine. lol.

Thanks for your help, and general thoughts.