* "That said, ICE as a proto for a SCOP is a bit non-sensical. If you can get something done in ICE there are very good chances you just got something that will work much faster than a SCOP to begin with."*
Sure, I just haven't found an ICE Rig I can't break yet, especially with anything which needs simulation-style behaviour. That might just me having a couple of bad experiences and writing off the whole thing forever, mind. Should probably give it another go if/when it comes up... On 8 February 2013 03:06, Raffaele Fragapane <[email protected]>wrote: > > That said, ICE as a proto for a SCOP is a bit non-sensical. If you can get > something done in ICE there are very good chances you just got something > that will work much faster than a SCOP to begin with. > > Given SCOPs suffer from many of the same limitations (I/O needs to be > explicit etc.) I can't think of more than a handful of mixing deck style > ops kind of cases where I'd use one these days. > > For pipeline work and proto there's Python, for some ops there's ICE, the > rest you have C++ for. Anything else is crippling IMO. > > > On Fri, Feb 8, 2013 at 1:51 PM, Enrique Caballero < > [email protected]> wrote: > >> i agree with ahmidou. >> >> I avoid SCOPS like the plague, usually i can do it with pure ICE. >> >> if for some reason it cant be done with ICE then I insist that people >> here use jscript. Otherwise your animators are paying a big price speed >> wise. >> >> Truthfully though, since ICE came out, i've been able to avoid using >> SCOPS 100%. I consider it obsolete tech now. >> >> >> >> >> >> >> >> On Thu, Feb 7, 2013 at 8:56 PM, Peter Agg <[email protected]>wrote: >> >>> I see it more as a trade off of speed with quality of life. :) >>> >>> >>> On 7 February 2013 12:39, Ahmidou.xsi <[email protected]> wrote: >>> >>>> I'd never use python for SCOPs, it's way slower than jscript. >>>> >>>> Le 7 févr. 2013 à 20:47, Peter Agg <[email protected]> a écrit : >>>> >>>> I tend to use ICE as a sort of SCOP testbed, especially if the maths is >>>> a little complicated it's easier to dev the system there and re-write into >>>> Python later. The only exception would be if I needed to make use of >>>> locations/geometry queries. But then it's still easier to store a custom >>>> attribute then read that into a script. >>>> >>>> >>>> >>>> On 7 February 2013 02:02, Raffaele Fragapane < >>>> [email protected]> wrote: >>>> >>>>> I mean output to an ICE par, not to a CP par, which is akin to hitting >>>>> your testicles with a large mallet. >>>>> >>>>> >>>>> On Thu, Feb 7, 2013 at 11:07 AM, joshxsi <[email protected]> wrote: >>>>> >>>>>> FYI, outputting to a parameter to ICE is around 10x slower than >>>>>> outputting to a transform, so I highly recommend that if performance is a >>>>>> requirement, never output from ICE into a parameter. >>>>>> >>>>>> Cheers, >>>>>> -j >>>>>> >>>>>> >>>>>> On Thu, Feb 7, 2013 at 10:42 AM, Raffaele Fragapane < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> You might be better off decoupling the length computation, which >>>>>>> tends to be expensive with any high order surface or curve, and output >>>>>>> it >>>>>>> to a parameter you fetch from graphs further down the stream. >>>>>>> That way you should save a fair chunk of cycles. >>>>>>> >>>>>>> If you need to keep them aligned you could also use some tricks to >>>>>>> basically reduce the dirtyness to a simpler check, like comparing point >>>>>>> positions before you start integrating your length function. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Our users will know fear and cower before our software! Ship it! Ship >>>>> it and let them flee like the dogs they are! >>>>> >>>> >>>> >>> >> > > > -- > Our users will know fear and cower before our software! Ship it! Ship it > and let them flee like the dogs they are! >
