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 <ml...@carbinestudios.com> 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:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *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 <tekano....@gmail.com> 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 <nunoalexconcei...@gmail.com> > 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 <tekano....@gmail.com> 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 <nunoalexconcei...@gmail.com> > wrote:**** > > took nearly 2 hours to apply the transform to all the nulls, after, to tes > **** > > ** ** > > ** ** > > ** ** > > ** ** >
