ICE kineamtics performances ?

[Ahmidou Lyazidi]

Hi list
I was doing some performance testing with ICE kinematics and found out that having many separate ICE operators (ie: one per limb)
is way faster than one ICE operator making all the calculations, in my case, 25% faster!!!!
So I was wondering if it's supposed to be the normal behavior?


Thanks
--
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos

[Steven Caron]

i dont think enough time was spent by softimage devs to really performance test it and make a informed decision about how the customer's should use it. a shame i know... in fact i didn't spend near as much time with it as i wanted to (many factors, but one being the ICE kine changed through out the beta).

s

[Ahmidou Lyazidi]

It's even faster than the ICE kine rabbit way where all the calculations are stored in one big array, and have a per driven icetree reading the array...

2012/7/4 Ahmidou Lyazidi <ahmid...@gmail.com>

[Ahmidou Lyazidi]

Yeah that's really too bad, it's a so powerful tool to build rigs. I'd prefer to see this area pushed forward and ICE globally consolidated
than getting new features.

my 2 cents
A.

2012/7/4 Steven Caron <car...@gmail.com>

[Matt Lind]

Yeah, the idea of putting all the ICE trees in a single graph is a little suspect to me.  It’s convenient for certain types of productions in the form of visual organization, but having all of them pounding the same data structures for different pieces of information in different places probably isn’t the most efficient.  Our production cannot work like that since all our assets have to exist on their own like pieces of LEGO in a larger kit.

 

Some compounds use fixed custom attribute names as internal variables and are shared by other compounds in the same ICE tree.  So part of the reasoning for a single shared ICE tree may be those dependencies.

 

In short, I would keep an eye on your ICE trees and do some edge case testing.  Don’t be afraid to dig into the compounds as you’ll learn why you’ll get certain types of funky behavior.  Copying/pasting ICE trees is one area to test.

 

 

Matt

[Eric Thivierge]

Also note that the rabbit rig setup wasn't intended to be the 'be all end all' of setups. It was a proof of concept on one way to use it. Not sure any official word has ever been handed down.

--------------------------------------------
Eric Thivierge
http://www.ethivierge.com

[Simon Anderson]

Never trust a bunny, while speaking about ICE it would be cool if they made it a bit more uniformed to the rest of Softimage, allowing using to access nodes through the object model.

was trying earlier to just set a value on an scalar node, and found that even though i can see the Value in the explorer to update it when I have the node in a variable is near to impossible using the OM methods, you have to use the setValue command.

--
-------------------
Simon Ben Anderson
blog: http://vinyldevelopment.wordpress.com/

[Ahmidou Lyazidi]

Yeah I know that, but it was supposed to be the more efficient way, actually it's not :)

2012/7/4 Eric Thivierge <ethiv...@gmail.com>

[Ahmidou Lyazidi]

+1000 it's such a pain scripting ICE trees

2012/7/4 Simon Anderson <simonbenan...@gmail.com>

[Steven Caron]

what type of improvements are you suggesting?

while i dont have Connect methods for ports, adding new Ports to nodes, or any control over where the node shows in the gui, the rest seems ok to me.

s

[Simon Anderson]

I was just trying to do something simple earlier, automating a rig setup from a guide and the script calculates a value that is needed in the ICE tree (static value), I had created the entire ICE tree using a scipt so each node is in a variable, but to set the value of the scalar wasn't just a simple 'scalarNode.Value = calculateValue', had to utilize Application.SetValue. may sounds like something small but I prefer sticking with OM commands.

[Steven Caron]

scalarNode.Parameters("Value").Value doesnt work?

*written with my thumbs

[Simon Anderson]

nope, when you query for parameters it gives and error, eric just mentioned a way that im going to try now

oScalarNode.InputPorts("Value").Value   # this works

ports... Baaah humbug XD

working now :)

[Ahmidou Lyazidi]

I ran some more tests, it consist of the same compound duplicated four times , each one driving an SRT:

Per object ice tree                                                                   49 fps
One Ice tree for calculation and per object Ice tree to drive srt   41 fps
multiple ice trees under the same object                                   38 fps
One Ice tree for everything                                                       34 fps

2012/7/4 Simon Anderson <simonbenan...@gmail.com>

[Brent McPherson]

Hi Ahmidou,

Yes, the problem is that if a single ICE tree is driving multiple kines then it gets evaluated multiple times as each kine pulls on their connection to the ICE tree.

The recommended way of dealing with this is to write to local data (self.myxfo) in the master ICE tree and then have small ICE trees on the targets that pull that data and write to their own kine. The local data acts like a cache so the master ICE tree won't be evaluated multiple times. So you can still do all your calculations in one master ICE tree and just use secondary ICE trees to write the results on each limb.

As you have noticed the performance difference is significant. In fact, used this approach for the ICE tree used by stereo camera which generates two transforms.

Same thing applies to rig initialization which should be put in a separate ICE tree as outlined in the docs.
--
Brent

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ahmidou Lyazidi

[Ahmidou Lyazidi]

Hi Brent,
Yes, but it seem that it's even faster to break the calcultion in smaller pieces, ie one ICE tree per limb.
Now, if possible, that would be a good thing to push things forwards in this area and as in rigging performance matter a lot, having some more high level factory nodes
like bezier curves, Ik....
Bezier curve is a good example, someone made a C++ node for that, it's just 25 faster than the compound!
I also d'like to see way to envelope/paint weights with ICE xform attribute instead of real deformers

There's a lot of things to do, to make it production efficient.

Regards
A.

2012/7/4 Brent McPherson <Brent.M...@autodesk.com>

[Eric Turman]

+1

--




-=T=-

[Brent McPherson]

ICE currently only supports data level parallelism and since ICE kinematics primarily involves singleton data it is effectively single-threaded.

We are aware that higher performance can be achieved by splitting up ICE trees, using compiled operators etc. but there can be other advantages to using ICE kinematics or having the entire rig in a single ICE tree. I agree that there are many things that could be done to improve this area so please continue to send us features/bugs through the normal support channels.

--
Brent


From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ahmidou Lyazidi
Sent: 09 July 2012 05:36
To: soft...@listproc.autodesk.com
Subject: Re: ICE kineamtics performances ?

Hi Brent,
Yes, but it seem that it's even faster to break the calcultion in smaller pieces, ie one ICE tree per limb.
Now, if possible, that would be a good thing to push things forwards in this area and as in rigging performance matter a lot, having some more high level factory nodes
like bezier curves, Ik....
Bezier curve is a good example, someone made a C++ node for that, it's just 25 faster than the compound!
I also d'like to see way to envelope/paint weights with ICE xform attribute instead of real deformers

There's a lot of things to do, to make it production efficient.

Regards
A.

2012/7/4 Brent McPherson <Brent.M...@autodesk.com<mailto:Brent.M...@autodesk.com>>

Hi Ahmidou,

Yes, the problem is that if a single ICE tree is driving multiple kines then it gets evaluated multiple times as each kine pulls on their connection to the ICE tree.

The recommended way of dealing with this is to write to local data (self.myxfo) in the master ICE tree and then have small ICE trees on the targets that pull that data and write to their own kine. The local data acts like a cache so the master ICE tree won't be evaluated multiple times. So you can still do all your calculations in one master ICE tree and just use secondary ICE trees to write the results on each limb.

As you have noticed the performance difference is significant. In fact, used this approach for the ICE tree used by stereo camera which generates two transforms.

Same thing applies to rig initialization which should be put in a separate ICE tree as outlined in the docs.
--
Brent