|
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.
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!
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.
|
