Hi Den, I had a look there to see what options are available and I didn't see anything that would be immediately useful. (That's not to say someone else hasn't found a way!) It seems that the way forward is to add a Python callback to update your Group knob with the metadata you want.
Here is the list of callbacks, some may be more useful than others (e.g. 'addUpdateUI()' might fire too frequently): http://docs.thefoundry.co.uk/nuke/90/pythonreference/nuke.callbacks-module.html Hopefully someone else on the list here has a better / cleaner idea! On Tue, Sep 15, 2015 at 1:38 AM, Den Serras <denserras...@gmail.com> wrote: > Hey Dan, I'm trying to get metadata to show on a standard group properties > pane. So far the only trick I've found that works is to make a ViewMetadata > node and use Pick to link it, but that is not formattable and looks ugly. > It seems like only the label will parse TCL commands like [metadata > custom/data]. Any ideas? > > Thanks! > Den > > > > > > > On Fri, Sep 11, 2015 at 4:50 AM -0700, "Dan Ring" <r...@thefoundry.co.uk> > wrote: > > Hi Den, >> >> in my experience, if the data is non-image, then the metadata route is >> the best place to pass data through the pipe. If artists are likely to >> change or move the node setup, then your receiver node can simply pop up a >> warning if it expects some metadata and doesn't receive it. >> >> Another way of doing things is having a node that looks up-stream for a >> particular "data source node" any time the original node's input is changed >> (although I don't know if the inputChanged event is fired in Python.) >> Searching the DAG upstream is relatively quick, and it only happens when >> the input is changed. (Although it won't fire if an upstream node's input >> is changed. You'd need to perform separate hash checking to test for that.) >> >> Hope that helps, >> >> Dan. >> >> >> >> On Fri, Sep 11, 2015 at 12:11 AM, Den Serras <denserras...@gmail.com> >> wrote: >> >>> Hey all, I'm wondering if people have favorite ways of passing data down >>> a pipe, and the pros and cons. I am thinking of using metadata, though the >>> artist could strip it by accident. Then there's channels, with similar >>> problems, but the advantage of holding a lot more data in a matrix. I also >>> thought about having a separate database stored in root, but then I'd have >>> to parse the upstream which can get heavy. Could also use variables in >>> custom knobs or filenames, but that seems easy to get messed up if an >>> artist duplicates a knob or moves it. I'm sure I'm also missing some other >>> method... >>> >>> My goal is when the artist creates or moves an in-house Node it >>> auto-populates with data from upstream. >>> >>> Thanks! >>> Den >>> >>> >>> >>> _______________________________________________ >>> Nuke-python mailing list >>> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> >>> >> >> >> -- >> Dan Ring, Ph.D. >> Senior Research Engineer >> The Foundry >> 5 Golden Square >> London >> W1F 9HT >> Tel: +44(0) 20 7479 4350 >> Web: www.thefoundry.co.uk >> Email: dan.r...@thefoundry.co.uk >> >> The Foundry Visionmongers Ltd. >> Registered in England and Wales No: 4642027 >> > > _______________________________________________ > Nuke-python mailing list > Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > -- Dan Ring, Ph.D. Senior Research Engineer The Foundry 5 Golden Square London W1F 9HT Tel: +44(0) 20 7479 4350 Web: www.thefoundry.co.uk Email: dan.r...@thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027
_______________________________________________ Nuke-python mailing list Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
