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
<mailto: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
<mailto: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 <http://www.thefoundry.co.uk>
Email: frank.harri...@thefoundry.co.uk
<mailto: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
