Bypass toggle

[Muhammad Junaid Baig]

Hi,

I am a Maya user and knows MEL pretty well, but I am having difficult time in figuring out how to toggle the "bypass" of other nodes using a custom toggle parameter from, say a null node, using HScript.

Any help will be appreciated.

Best,

[cosku]

You can toggle a switch, which evaluates or skips your bypass-node as its inputs.

[Muhammad Junaid Baig]

Thanks for the response. I guess I haven't made myself clear enough. Say this is the case:

I have a Null object which is at the end of the graph and I have my custom attributes in to drive the parameters of the other nodes up in the graph. Now I want to have check box where it reads Visualize. What it should do, it should directly command the bypass function of the specific color node up in the graph.

I can always use a switch node and drive the graph with it, but is that the only way to do that? Can't we modify the properties of the nodes directly from other nodes' parameters?

Thanks,

[anim]

you can do it using python:

node.bypass(1)[/CODE]

or hscript command

[CODE]opset -b /path/to/node[/CODE]

so you may need to do it as a callback to your parameter if you want it to be executed each time you change it

after saying this you still need to consider if you really want to do it this way as it has many disadvantages and I don't recommend it at all

mainly if you want to use it for live bypassing during the animation or inside of a locked asset

rather use the switch technique, it's working quite well

or if nodes you want to bypass are VOP SOPs just implement bypass or mute parm in there which you can drive by expression easily

[Muhammad Junaid Baig]

Thanks Tomas, I appreciate your input. I'll keep your advice in mind for the neat workflow. I'm not really old in Houdini and trying the stuff to make myself more comfortable with the environment. This particular thing was for a tool I'm building for myself, hence I am open to any experiments.

Thanks again,

Best.

[old school]

One other motivation to using Switch SOPs over manipulating node flags is that if you choose to wrap this up in to a Digital Asset, you can't alter flags on nodes inside locked assets. Switch SOPs use channel references making switching things trivial in Assets though.

All node flags can not be edited inside an HDA including display/render flags, bypass, lock flags and the non-visible ones including geometry unload flags.

Coming from maya, you might think that having large forked trees of nodes would be very expensive but in Houdini, nodes that are not evaluated are unloaded from memory and the only overhead per node is very small (~15K?). This makes it quite possible to have multiple forked chains of SOPs feeding in to Switch SOPs to choose between various options inside your SOP network chains. Side Effects has been keen to optimize these node workflows for the past 25+ years now and the recent geo rewrite in H12 offers even more optimizations to these branched chain workflows. If anything this is the true magic behind Houdini: not any specific node but how the nodes evaluate as a whole.

You have to think backwards in Houdini laying out SOPs coming from code when it comes to switches. Upstream operators are enabled by a downstream Switch SOPs.

In Houdini, the SOP node tree is evaluated in two steps: First pass to evaluate dependencies starting at the Display/Render flag SOP and then upwards all the way to the top including all external dependencies. Once this is done, the SOPs will now evaluate in reverse order from top to bottom terminating at the SOPs with Display/Render flags.

Obviously creation order is what triggers everything btw. On the obscure side of things, the rare dependency bug can be worked around by a simple delete/undelete of an object to shuffle creation order which in turn will alter the dependency evaluation. Fun times.

Knowing that should help you a lot in constructing SOP chains to be as efficient as possible.

One critical tool in analyzing how SOP chains evaluate is to use the Performance Monitor Pane. There are several different ways to view the tree evaluation. By default the Performance Monitor Pane in H12 has been set up to view operators based on performance rather than execution order.

but...

The older preH12 method of generating performance output based on the second pass top-to-bottomdisplay/render-flag is still possible to get to and very useful for seeing which nodes are executing in what order:

- For the Performance Monitor pane, in the View menu option, select "Event Log View" or press the "L" hotkey with the curser over this pane.

- Now press the Enable button (and remember that if this button is on, the performance monitor is running and yes there is an overhead to running this so once you finish debugging, turn enable off).

The evaluation tree is now showing you the exact order in which Houdini did the second pass evaluation of the node tree, how long each node took to cook (evaluate) and how much memory. A nice flattened evaluation of the entire Houdini scene and will pick up all nodes that needed to evaluate excluding VOPs (the node containing VOPs will report timing and memory).

I like both output formats of the performance monitor. So much so my own personal desktop has two performance monitor tabs stacked: one set to the default longest time view and a second set to "Event Log View" to see the actual execution order which tells me how Houdini resolved the dependencies inside the entire scene.

You can also easily write the Event Log View to disk as a text file. It's fun to see how some very complex networks with tens of thousands of nodes evaluate. Print it out and paste it on your walls to scare off your Maya colleagues.

Hope this helps clear things up.

[Muhammad Junaid Baig]

Wow old school! That was really a motivation. Yes I had this fear that larger forked node-trees takes more memory and so on. You cleared my concepts real well. Love the way performance monitor works.

And also thanks for some nice tricks in the end as well!

Best regards,