Whether you generate all your nulls in one ICE Tree or multiple ICE Trees is irrelevant.
The point I was getting at is creating anything in a scene will trigger events and other code running in the background to validate and ensure integrity of the scene. As the scene gets larger, those checks will take longer and take some measurable amount of time. When you create stuff iteratively, you effectively re-trigger the same events again and again. That time piles up. My suggestion to avoid that problem was to dynamically generate an ICE compound file (XML) and export it to disc as it wouldn’t trigger any of those events, then use the native ICE compound loader to import it into the scene. This would minimize the number of events that get triggered, or at least streamline them. This is the same principle behind why it’s more efficient to duplicate an object ‘n’ times with a single call to Duplicate() vs. ‘n’ calls to Duplicate(). Matt From: [email protected] [mailto:[email protected]] On Behalf Of Rob Chapman Sent: Friday, January 11, 2013 11:52 AM To: [email protected] Subject: Re: Cage deform by cluster Actually, I dont think this is a problem with my ICE tree :) or getting any data from a group of polygon meshes as you can see add point does that instantly. Also, as far as I'm aware, a separate ice tree is not made or needed per null, not sure where you both are getting this from. my prognosis is that whatever the menucommand is calling from ICE>Kinematics>Effects>transform objects by particles is the culprit and it is more likely not as efficient a script as Alan's is. With a bit of detective work (turning on script window) this is whatever Application.ICEFlow_ConstraintToParticles() is doing and digs down to ICEFlowConstraintToParticles.js in C:\Program Files\Autodesk\Softimage 2013 SP1\Addons\ICEFlowBuilder\Application\Plugins and in_reg.Author = "laforgg" so, its simply not fair to cast dispersions on others code without the opportunity of said coder able to step in and explain themselves, for they no longer work there. but lets not ignore the barefaced cheek of being called out by a non-coder! ;) wonder if its possible to add another menu item underneath and call it 'generate nulls per particle 27x faster than above' - and yes perhaps I am being unnecessarily harsh and you both (Matt & Alan) are correct that indeed the only way to attach nulls to particles IS by making a separate ICE tree per null. cheers Rob On 11 January 2013 18:54, Matt Lind <[email protected]<mailto:[email protected]>> wrote: The issue you’re running into with ICE is creating a new node or relationship between nodes triggers other updates/refreshes within the scene. That time piles up before too long. Thinking outside the box here: Since .xsicompound files are XML, try writing a tool that generates an XML description of what you want to happen. Then let the ICE compound loader do the heavy lifting. Probably will still be slow overall, but probably a lot faster than generating one node at a time in the scene. Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Alan Fregtman Sent: Friday, January 11, 2013 8:30 AM To: XSI Mailing List Subject: Re: Cage deform by cluster Hehe, I knew ICE was slower for this hence my more traditional solution. It's dissapointing, but ICE is just not fast enough when it comes to singlethreaded things and it has a lot of overhead. It kicks ass and takes names when it comes to large datasets (where it magically slices up operations to many threads) like with most deformers, but with simple tasks it's slow. Maybe if and when we ever become able to set an icetree on a group of objects and drive everything from 1 tree, then it could potentially be better. — 2400 icetrees is nuts, no matter how simple. :p On Fri, Jan 11, 2013 at 9:08 AM, Rob Chapman <[email protected]<mailto:[email protected]>> wrote: and my timings are 2400 nulls in 54 minutes. A rate of 44.4 nulls constrained per minute on 2013SP1 64bit dual Xeon X5680s @3.33ghz - my workstation must be faster. still, a ridiculous amount of time for such a basic task. Alan's script btw took 2 minutes to create, place and constrain all 2400 nulls. A very clear winner. apologies for the noise! best Rob On 11 January 2013 13:20, Nuno Conceicao <[email protected]<mailto:[email protected]>> wrote: Sorry mate, i made a mistake on my initial null amount, i had 2x more nulls than i needed, i counted triangles instead of polys,duh!, i changed my post a bit too late. Anyways, ive cut the time to half, but still was very slow, i think once it is large data sets it can get very slow in softimage doing things, in any case after i got rid of the excess nulls, i only got 2-3 fps while on the contrained to cluster nulls i got 4+ FPS. On Fri, Jan 11, 2013 at 1:14 PM, Rob Chapman <[email protected]<mailto:[email protected]>> wrote: wow, very interesting! 2 hours to constrain 2800 nulls - so thats only 15 nulls per minute , bit of a joke! Am sorry for suggesting it, I really did not appreciate how slow it is and thought the menu call to ICE > Kinematics > transform objects by particles might have been more optimised than Alan's Python script.. definitely not! maybe its written in VBscript or...? :) I guess the serious rigger constrainers are best to stick with Python scripted solutions for now. Also couldnt understand how it took so long as the example I made with few hundred wasnt that tedious to wait, so testing it out on a grid quick with 2400 nulls , the progress bar is already past 1/4 way though and its only been 5 minutes... oh wait screens frozen and gone white - will let you know final time if it finishes, just going for lunch! :D its obviously not multithreaded as only 1 core out of 24 is in use for this procedure - what a waste! cheers Rob On 11 January 2013 12:47, Nuno Conceicao <[email protected]<mailto:[email protected]>> wrote: took nearly 2 hours to apply the transform to all the nulls, after, to tes
