Ah yes, I do see why adding a view is a potentially awkward workflow. When a new view is created, there is no global way to tell Nuke not to use it by default. So if I already have views 'inputview[1-6]', when I add 'outputview[1-5]', those views will get processed further up the chain. That's bad.
Since the node can only output one image at a time, the most straightforward thing to do would seem to just have multiple copies for each desired output and just change its output mode. That could also be a button somewhere. This is cleaner to me than stuffing the output into layers because I believe layers must all share the same resolution. I do not think this is a problem, however, and might just be complicating everything based on a hypothetical edge case. In any case, one could make sure in the code that this is not much slower than using multiple nodes. -Jon On Thu, Aug 9, 2012 at 5:12 PM, Nathan Rusch <[email protected]>wrote: > Given your end product, views do sound like they would be useful. > However, I’m still of the opinion that adding views as part of the output > process (i.e. changing the project settings just to generate data) is a > somewhat strange and possibly painful way to go about it. > > As one other possibility, you could do something like: > - Output each piece of the projection into a layer with a qualified name > (based on its projection type and component). > - Add a button or write a small Python function to automatically break out > a set of Write nodes based on the node’s settings. > > You could even go one step further and add a file knob to your generation > node and allow it to be executed directly, handling the file outputs under > the hood. > > Does any of this sound like it could work in the context of your workflow? > If not, can you provide any more specifics? It may help to generate some > alternate solutions. > > -Nathan > > > *From:* jon parker <[email protected]> > *Sent:* Thursday, August 09, 2012 1:54 PM > *To:* Nuke plug-in development discussion<[email protected]> > *Subject:* Re: AW: [Nuke-dev] multiple outputs? > > I'm starting to think the best way forward is to provide an option to send > outputs to a set of named views if they exist, and a user controlled python > button to create those views if they don't. This way the creation of views > falls into the hands of the user and is not internal to the node. Win-win? > > On Wed, Jul 25, 2012 at 4:30 PM, Steve Booth <[email protected]> wrote: > >> The number of views is a project-level property that is set in the >> project-settings property panel. It doesn't necessarily have to be set >> prior to designing the SDG, but when changed will fundamentally alter the >> data structures created by the various nodes in your script. >> >> To my knowledge, there is no way to alter the project definitions from >> inside a single node (as it will affect all other nodes in the script), >> nor >> would it, It think, be a good idea, although it might actually be possible >> by executing some Python code. >> >> Not advisable, imho. >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of jon >> parker >> Sent: Wednesday, July 25, 2012 1:20 PM >> To: Nuke plug-in development discussion >> Subject: Re: AW: [Nuke-dev] multiple outputs? >> >> Okay, thanks for the info. Do views have to be already defined in order >> for >> a node to write to them, or can nodes create new views? >> >> On Wed, Jul 25, 2012 at 9:42 AM, Steve Booth <[email protected]> wrote: >> > Although technically true, realize that in a multi-view environment, >> multiple instances of your Op will be instantiated, one for each defined >> view, for every use of the base node in the SDG. Utilizing static storage, >> it is possible for your node to be aware, and potentially communicate with >> other versions of itself servicing those other view outputs. >> > >> > Sent from my iPad >> > >> > On Jul 25, 2012, at 12:27 AM, Thorsten Kaufmann >> <[email protected]> wrote: >> > >> >> You cannot have multiple outputs, but you can output to as many >> layers/channels as needed. >> >> >> >> Regards, >> >> Thorsten >> >> >> >> >> >> Thorsten Kaufmann >> >> Head of Production >> >> ____________________________________ >> >> >> >> Mackevision Medien Design GmbH >> >> Forststraße 7 >> >> D-70174 Stuttgart >> >> >> >> T +49 711 93 30 48 31 <%2B49%20711%2093%2030%2048%2031> >> >> F +49 711 93 30 48 90 >> >> M +49 151 19 55 55 02 <%2B49%20151%2019%2055%2055%2002> >> >> >> >> [email protected] >> >> http://www.mackevision.de >> >> >> >> Geschäftsführer: Armin Pohl, Joachim Lincke, Karin Suttheimer HRB >> >> 243735 Amtsgericht Stuttgart >> >>>> -----Ursprüngliche Nachricht----- >> >>>> Von: [email protected] [mailto:nuke-dev- >> >>>> [email protected]] Im Auftrag von jon parker >> >>>> Gesendet: Mittwoch, 25. Juli 2012 01:05 >> >>>> An: [email protected] >> >>>> Betreff: [Nuke-dev] multiple outputs? >> >>>> >> >>>> Greetings, >> >>>> I'm new to this list (and NDK development) so this might already be >> answered. >> >>>> Is it possible to create a node that provides multiple outputs? >> >>>> >> >>>> Cheers, >> >>>> Jon >> >>>> _______________________________________________ >> >>>> Nuke-dev mailing list >> >>>> [email protected], http://forums.thefoundry.co.uk/ >> >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> _______________________________________________ >> >> Nuke-dev mailing list >> >> [email protected], http://forums.thefoundry.co.uk/ >> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> > _______________________________________________ >> > Nuke-dev mailing list >> > [email protected], http://forums.thefoundry.co.uk/ >> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> _______________________________________________ >> Nuke-dev mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> _______________________________________________ >> Nuke-dev mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> > > ------------------------------ > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > >
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
