On 1 July 2015 at 08:53, John RA Benson <j...@illum-mg.fr> wrote: > I am curious though - isn't the Op graph already visually exposed in the > GUI with the nice little computation highlight? Why not have a python > function for it? Transient or not, it would be relevant on a per frame > basis or we'd never get repeatable renders done. > Op generation is pretty deterministic* and their lifetime is scoped during their use. Otherwise we end up with an unfeasibly huge amount of Ops and Knobs hanging around in memory per session.
Because they're just deterministic, and we have aggressive caching, we can just regenerate them *or* reuse them depending on various factors. F. * in 99.99% of cases To be fair though, in my situation, I don't know why, but the tree > highlights both branches around my 'switch' gizmo, but the code below still > works (after changing the class). The highlight is correct around a normal > switch. An internal nuke function based on what does the highlights > probably wouldn't work for me anyway! > hmm, weird. > Cheers > JRAB > > > On 07/01/2015 12:01 AM, John RA Benson wrote: > > I thought evaluating would make it pretty slow so I avoided thinking about > it when I sent the mail. As you suggested, in the end it worked out fine, > and this was a simple mod. I ended up using a modification of some code > (from Vilya) found in an old post ( > http://community.thefoundry.co.uk/discussion/topic.aspx?f=190&t=101385 ): > > def getSwitchedUpstream(startNode, maxDepth=-1, found=set([]), > what=nuke.INPUTS): > if maxDepth != 0: > newDeps = set([n for n in nuke.dependencies(startNode, what=what) > if n not in found]) > found |= newDeps > for dep in newDeps: > if (dep.Class() == 'Switch'): > dep = dep.input(int(dep['which'].value())) > getSwitchedUpstream(dep, maxDepth - 1, found) > return found > > From the return, I can easily find the needed prerender class nodes and > only render those. > > It turns out that this little bit is surprisingly fast (using timeit, it > ran through a typical huge comp using the Write node as the startNode in > about 0.3 secs for 10000 iterations). Simple and fast, that'll do for now, > even if nothing else is exposed. > > Cheers! > JRAB > > > > On 6/30/15 8:03 PM, Frank Harrison wrote: > > 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 <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 > > > > -- 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
