Hi,

I am trying to get this sop otl node that I am working on to behave differently based on the display flag's value. All I want to do is to have the input param in a switch node change based on the parent display flag. However, I haven't figured a proper way to do this.

I know I can do hou.pwd().parent().isDisplayFlagSet() in a python expression, but that is not doing the trick, since the network doesn't actually switch paths. The only way I've managed to get this to work is by forcing the network to be time dependent, in which case the aforementioned works. Obviously, I'd rather don't do that if I can avoid it, which is why I was looking into callbacks that I could potentially use when the display flag changes, if I could catch that event that would give me a hook to do exactly what I need. Unfortunately, I haven't found anything resembling a “onDisplayFlag” event.

Any ideas?

Thanks beforehand!!

Cheers

I don't think doing something like this is a good idea in the first place as it works against general Houdini conventions. Why do you want to do this? What is your usage scenario?

Hey edward, thanks for your reply.

I can see what you mean. I initially prototyped the node's behaviour using a toggle parm. The reason because I am trying to achieve this via the display flag is ‘just’ for the sake of usability.

My scenario is as follows: my node A performs some operation in its input geometry and outputs the result. There can be multiple, many, of these nodes and their outputs will be merged at a later stage. However, this proves to be very inefficient compared to what it could be if the heavy computation is performed in a unique place (this all happens in a time dependent part of the network) taking advantage of parallel computation in vex. What I am doing instead, for the sake of performance, is to have the A nodes prepare the data for computation (which they can do and remain time independent) and pass it down to another node (B) which collects, merges and performs the time-dependent operation described by the parameters on the A nodes. This is so much faster and works really well but, of course, harder to work with if the user needs to make sure toggle parms are properly set up all the time. And here is where I thought the display flag could come into play, if display flag is on, an A node should be able to compute the result so the user gets to see exactly what they are doing, instead of relying on having the display flag enabled further down the network and having to see all the geometry instead of just what they are working on. Does that make sense? Any suggestions or alternative approaches welcome but usability and performace is key.

When you refer to “general Houdini conventions”, is there any comprehensive reference doc somewhere with best practices, things to avoid, performance considerations, and so forth?

Thank you beforehand.

Cheers
Ruben

I'm not sure exactly how this would work, but maybe your B node could have a menu parameter that let you choose whether it “Merges all Inputs”, or selects a single input to cook. Then your display flag is on B all the time, but you can quickly switch to viewing the result of a single A node? I feel like this should be possible inside the B node with a Switch node where the first input is a merge of all A nodes, followed by direct connections to each of B's inputs?

Hi,

Yes, that would work. Thanks for the suggestion. It is just a lot less intuitive I would say.

Rubs
When you refer to “general Houdini conventions”, is there any comprehensive reference doc somewhere with best practices, things to avoid, performance considerations, and so forth?

Going back to that… anyone?

Thanks!

I still not sure this is a good idea but in any case, I think you might be able to do something like this by calling hou.Node.addEventCallback(hou.nodeEventType.ChildSwitched, callback) on your object node (ie. the parent node of your SOP nodes). You're going to need to work out the issues on ensuring that you only have one callback handling all this logic, and then you'll need to dirty all the appropriate nodes when the display flag changes so that they recook to a different result. To dirty the nodes, maybe try calling hou.Node.setGenericFlag(hou.nodeFlag.Bypass, True) and then False again.

On the topic of a reference of best practices, I don't know of any really. The performance profiler is helpful and each major release has seen more multithreaded improvements. On the practice side, Houdini's nodes are “functional” in nature and so side effects during cooking is a big no no.

make 2 outputs on your node A
output direct result into first output
and use second output to output geo for the further processing downstream

when user displays node A it will show first output geo, so he can see direct result
but when node B input stream evaluates node A it will evaluate second output which will return just prepared data

The second output is something I've considered, indeed. I'll play with the different options.

Thank you very much for your replies!