Hey, just because i am too lazy to switch the viewer to display the alpha channel > Did you know that when you press the "A" key in the viewer it allows you to switch between Alpha and RGB? :)
On a side node: If i, lets say use a blur node set to use rgba, but > downstream only use alpha from that (i.e. as a mask input on another node), > will Nuke be slower because it blurs rgba instead of alpha only? Or will > only the requested channels be calculated upstream? It should just operate on the Alpha channel and if the blur node is just operating on Alpha then that should be all that it operates on and all that it *directly* supplies to its down stream Nodes. If you're viewing the Blur with RGB enable in the viewer then you'll pull those channels through the blur. So I guess you might (depending on you graph) be able to work faster if you operate on a channel at a time. When you mention expressions, do you mean expressions on the Roto/Paint > nodes themselves, or also generally in the script? > In this case Roto/Paint specifically. I've seen scripts with expressions on most of the points on most of the shapes. And what would you consider excessive? :) > Well, expressions are an incredibly useful feature and help us do lots of very cool stuff very quickly, but, by their very nature Nuke can not work out when the value that an expression evaluates to has changed; this means that Nuke has to evaluate Nodes (and sub-graphs with Nodes) with expressions more often, which can lead to slowdowns, sometimes. I hope that answers your questions :) F. On 1 April 2015 at 10:37, Daniel Hartlehnert <dah...@gmx.de> wrote: > Oh, i forgot to add that i have only worked with v7 so far, no experience > with 8 or 9 yet. > > > Am 01.04.2015 um 11:17 schrieb Frank Harrison: > > Hey Daniel, > > That's fascinating to hear, I wonder if it does relate to the bumber of > channels they use by default? > > There are various things you can do to make Roto and Paint appear slower, > such as use excessive numbers of expessions or view a node downstream of a > Roto with lots of comptationally expensive Nodes in between. > > If anyone does have any reproducable performance metrics or scripts they'd > like to share we'd love to see them, add them to our autotests and make > it a better experiance :) > > F. > > On Wednesday, April 1, 2015, Daniel Hartlehnert <dah...@gmx.de> wrote: > >> Hi Frank, >> >> thanks for an "official" answer :) >> >> My experience differs though, so i don't have any "metric" to base it on, >> Marten. Only common sense and experience. Therefore my answer i gave before. >> >> >> Am 01.04.2015 um 10:00 schrieb Frank Harrison: >> >> Hey Guys, >> >> Under the hood the two Nodes are exactly the same, they just cater to >> different work flows. >> >> As a result, the only time RotoPaint should be slower is when you have >> paint/clone/smear strokes interleaved with bezier/bspine shapes. >> >> F. >> >> On Wednesday, April 1, 2015, Daniel Hartlehnert <dah...@gmx.de> wrote: >> >>> Isn't it obvious? Roto node has much less functionality, hence it its >>> much faster to process and has a smaller memory footprint. Bugs from the >>> paint part of Rotopaint cannot destroy your script, Rotopaints with more >>> than 100 strokes tend to slow down your script (if i ever see that progress >>> bar from a rotopaint node i start to ...) >>> Rotopaints are responsible for most broken scripts in my experience. >>> >>> Wyh would you use Rotopaint if you don't actually paint? >>> >>> Am 31.03.2015 um 20:14 schrieb Simon Björk: >>> >>> For some reason I always reach for the RotoPaint node instead of the >>> regular Roto node. I'm not sure why I got into this habit, but it might be >>> (if I'm not mistaken) that the RotoPaint node was introduced before the >>> Roto node back in 6.0. >>> >>> Anyway, does anyone know if there's a difference in >>> performance/stability when doing just regular roto? We've all had or >>> problems with the RotoPaint node over the last couple of versions, but I >>> have never actually compared the two nodes to see if one is "better" than >>> the other. >>> >>> >>> >>> >>> >>> ------------------------------- >>> Simon Björk >>> Compositor/TD >>> >>> +46 (0)70-2859503 >>> www.bjorkvisuals.com >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> >> >> -- >> Frank Harrison >> Senior Nuke Software Engineer >> The Foundry >> Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906 >> Web: www.thefoundry.co.uk >> Email: frank.harri...@thefoundry.co.uk >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> > > -- > Frank Harrison > Senior Nuke Software Engineer > The Foundry > Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906 > Web: www.thefoundry.co.uk > Email: frank.harri...@thefoundry.co.uk > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > -- Frank Harrison Senior Nuke Software Engineer The Foundry Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906 Web: www.thefoundry.co.uk Email: frank.harri...@thefoundry.co.uk
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
