On 30 June 2015 at 19:54, Nathan Rusch <[email protected]> wrote:
> 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. > Me too ;) > 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. > Me too. > 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. > We don't ordinarily work on graphs where we split out sub-tree at a different frame-context (ignoring scale, view, etc. for a sec), but a decent enough meta representation would allow you to perform whatever analysis you wanted, i.e. `get me all sub-graphs at frame N`. > 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. > Our file-localisation tools do something similar. I have a bug I'm looking at in this area... it's nice to hear there are people at The Foundry that find these types of > ideas interesting. Oh you have no idea ;) > > -Nathan > > > *From:* Frank Harrison <[email protected]> > *Sent:* Tuesday, June 30, 2015 11:03 AM > *To:* [email protected] ; Nuke Python discussion > <[email protected]> > *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 > > - what types of Nodes are up- or down-stream of another Node > - find the shortest path > - 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 <[email protected]> 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 >> [email protected], 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: [email protected] > > ------------------------------ > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > _______________________________________________ > Nuke-python mailing list > [email protected], 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: [email protected]
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
