This is the kind of thing I've dreamed about being able to do for a long time, and I would love to see more work done on Nuke's Python API to expose lower-level constructs and things like Op tree interfaces.
For instance, I would love to be able to build an OutputContext and then "cook" an Op tree using that context and a given root node (without actually performing an engine() call), similar to what happens when an Op is executed. That would give you back Python interface to the snapshot of the underlying Op graph, and the interface would hold the graph in memory either until it went out of scope or explicitly released the graph (for instance, if it implemented a Python context manager interface). Once you had that interface object, you would then be able to traverse it, query fully-resolved knob values, etc. In cases where Ops were doing things like time-based input splitting (e.g. FrameBlend, OFlow, etc.), the inputs of an Op may actually be connected to multiple instances of a given input node's Op at once, with different OutputContexts used for each. My thinking is that this splitting would be exposed by the interface as a single merged and pruned graph, rather than multiple parallel graphs existing at different times. All knob values would be fully resolved (e.g. sequence paths would yield individual files, expressions would be evaluated, etc.), so you would be able to do things like find the exact input file paths that were required to generate a given output frame at a given node. So, for instance, a FrameBlend downstream of an image sequence Read would have as many inputs as frames it was blending, and each one would be connected a Read whose 'file' knob would yield a path to a single frame from the sequence. You could then easily do things like group these paths based on the node that owned on each Op instance if you wanted to. Anyway, I know this is more or less a pipe dream for the foreseeable future, but it's nice to hear there are people at The Foundry that find these types of ideas interesting. I do see questions like "can I find the files used to render frame X of my output?" coming up with some regularity, and with enough special-case code for handling specific node types, I think it could be possible to do this using the current API. However, it could be quite painful, and might fall short of getting everything 100% correct. -Nathan From: Frank Harrison Sent: Tuesday, June 30, 2015 11:03 AM To: j...@illum-mg.fr ; Nuke Python discussion Subject: Re: [Nuke-python] finding *needed* dependencies I don't think this is directly possible in Nuke's Python... yet, but there may a workaround for it, or a way to infer this information. If it's just Switch Nodes you need to monitor, perhaps you could try traversing up graph until you hit Node of type Switch, evaluate the Switch:which knob and follow the Input its set to? Would that work? Is there is a better way perhaps? As an aside, because this is really talking about something I'm quite interested in.... Graph topologies: What Nathan's example, in your link, is doing is traversing the topology of the Node-graph (easy), whereas what you're asking for is to traverse the Op-graph that's been generated for a given context (not so easy). That is, the DAG only shows a representation of the actual operations (Ops) the Graph will generate. For your use-case there are just one Node-graph but two (or N) entire op-graphs, one for each of the switch configurations. This would be a very useful feature and I can think of a couple of uses for allowing access to more topological information in Nuke, both Node topologies and Op topologies. For example we already have an internal structure we can query to find out things like a.. what types of Nodes are up- or down-stream of another Node b.. find the shortest path c.. get all paths between two Nodes It's very cool and useful. The problem is that Ops are very transient and we'd have to be /very/ careful how we exposed them to Python, and we probably never will, directly. On 30 June 2015 at 16:23, John RA Benson <j...@illum-mg.fr> wrote: Hmm - Ok, I'm not having an issue finding dependencies (this does the job just fine, for example: http://community.thefoundry.co.uk/discussion/post.aspx?f=190&t=103381&p=894390 ), but I discovered that I don't have a way to find my *currently needed* dependencies. Basically, let's say I have a write node and want to find nodes of a certain class in it's dependencies, let's call the class 'PreRender' I want to render those prerenders, but only those in the tree that are switched on. I have a switch for prerender1 and prerender2, because the tree above them branches with some differences specific to the prerender. I need to render two jobs at two separate times, manually switching them, but the output is to the same write node. The pipeline fills in the write path based on 'stuff', so I'm not actually overwriting anything when I re-render - except that, even though prerender2 isn't being seen in the first render because the switch is looking at prerender1, it's still part of the dependencies tree, and consequently, it's getting rendered. Is there a way for me to walk through the dependencies via python to eliminate the non-rendered part of the dependencies tree? thanks JRAB _______________________________________________ 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 -- 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-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
_______________________________________________ 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
