SCOPs have their time and place, and for certain things python isn't necessarily noticeably slower than JS (for COM object dupe or creation heavy stuff though it's painful beyond belief). 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!
