If anyone is interested, I'll follow up on our solution that we ended up with.
Our developer created two Ops to do the transformation to other projections: a node that would accept multiple inputs and do the transformation heavy lifting which then stored the results in channels, and another node that allowed the user to extract a certain 'view' from the channels it created, using metadata generated by the transformation node. I then realized we could use Nuke's built-in per-view parameter overrides to store the results in the views we wanted in a relatively native manner. In the end, with some gizmos to automate the view merging/splitting this solution was pretty easy and intuitive for the user. HTH, -Jon On Thu, Aug 9, 2012 at 6:42 PM, jon parker <[email protected]> wrote: > 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
