Is setting properties within an unlocked OTL valid workflow?

[GeordieM]

Hi all, I've been prototyping a system where a COP SOP does image processing (Reads in height maps and renders out normal maps) for a terrain object.  The height maps I need to read are in a variable sized grid so I need to be able to iterate over multiple height map textures before the SOP can continue to generate the terrain.

 

What I would like to do is have a Python SOP that sets parameters on the COP SOP nodes (images paths etc) and then tells the COP to render the normal map.  All this has to be in a single OTL (can reference sub OTLs) for Houdini Engine.

 

Is it valid work flow to save my OTL with "Save Contents as Locked" disabled so nodes can set properties on each other within the OTL?

 

Or will someone shoot me for doing this.

 

I did get this working setting and getting custom parameters on the base OTL but my COP node will be several layers deep in nested OTLs and my OOP spidy-sense was tingling doing this.

 

TNKS!

 

G

 

 

[magneto]

Hi,

 

I am not exactly sure what you are doing but you can promote the parameters you are changing to the asset level and then set these using your script. Generally you use the editable nodes approach for things like Paint SOP inside where it needs to be editable with the OTL.

[GeordieM]

Thanks for the reply!

 

For example if I have:

obj/OTL_A/OTL_B/OTL_C/COP_SOP/ROP_Render

obj/OTL_A/OTL_B/OTL_C/Python_SOP

 

Functionality I'd like:

1. Python_SOP sets the render path on ROP_Render

2. Python_SOP calls ROP_Render.parm('execute').pressButton() to render 

 

Because I have 3 levels of nested OTLs, if all the OTL levels are locked then the only place I can put settable parms (that I know about) is on the top level OTL (OTL_A).  This works but then I'm creating a design dependency between OTL_A and OTL_C.  So I then couldn't use OTL_C in any other graph. Also if you later put OTL_A inside another OTL and that one was locked the functionality would also break.

 

However if OTL_A (and OTL_B and OTL_C) are unlocked, I can directly set parms on ROP_Render from Python_SOP.  This keeps all functionality internal to OTL_C.

 

I guess what I'm asking is is it dangerous to directly set parms on one node from another without using linkage to/from custom parms on the top level OTL? eg Could this create threading/timing issues?

 

If keeping OTLs locked is simply a workflow convention and nothing to do with technical constraints then I can live with it.

 

TNKS!

 

G

[edward]

Is it dangerous? Absolutely yes. Houdini's cooking engine is more like a reactive programming model instead of "imperative". Behaviour for setting parameters while cooking is not well defined.

A better way to do something like this might be to set up a ROP network with dependencies. So you have a Composite ROP that cooks your COP network out to files, which then outputs into a Geometry ROP for taking those files to generate geometry from them. The tricky bit is that your "iteration" now needs to be expressed in terms of "frames" but that's usually doable.

[GeordieM]

edward, thank you!

 

As I suspected I'm thinking about the problem the wrong way.  I thought maybe I could get away with it since the COP network I have doesn't resolve out to anything unless a rop render node is called.  I also tried setting detail attribs in a Python SOP and then referencing them from OP nodes but this gave me weird dependency errors.

 

Yes I suspected a ROP network might be the way to go but since I'm a noob I can't find much info on ROPs.

 

Another option I was contemplating was programatically building a COP network in Python then executing it, but this looks like overkil:

http://sidefx.jp/doc/hom/cookbook/composite/index.html

 

If I can build a ROP network that ensure COPs are executed before SOPs I'm good.

 

TNKS!

 

G

Edited March 6, 2015 by GeordieM

[GeordieM]

So I guess semi related question:

 

How do manager nodes fit into the reactive programming model?  Does a SOP COP manager get evaluated at SOP level creation time?  Or are they only evaluated when a node in the SOP network has a reference to them? 

 

Do you think it would be ok to package my COP network into a OTL then programatically build a COP network with an instance of the COP OTL per input image?

 

PS:

Hmmm I'm starting to understand what you were saying about rendering a sequence out.   I could add multiple file input into a COP manager with Python and feed them all into a switch node. The switch node's index would already be bound to $F so then just need to render a sequence.  Good tip that one!!

Edited March 6, 2015 by GeordieM

[edward]

Nodes in general evaluate when some requests its data. Most of the time, things seem to cook as soon as you change parameters only because you have a viewer pane open that will re-request the data when the things it's viewing has been changed. If you maximize the parameter pane say, and then change parameters, then nothing will recook.

 

For the ROPs (aka "output" nodes), they only evaluated when you hit the render button. Perhaps I'm missing something, but why do you need to programmatically create anything at all? Set up your network with all the proper connections and let the user hit the render button on your HDA to generate to everything.

[GeordieM]

Cool thanks again for more points to think about!

 

I guess I'm just trying to work out how to think in terms of how Houdini likes to do stuff.  I'm coming over from developing Maxscript/C#/SDK tools.

 

The main problem I'm trying to work out is how to completely encapsulate all of my logic inside an OTL, and have that OTL work inside other OTLs with no changes or dependencies on the top level OTL.  I understand that setting parms directly on nodes from other nodes is bad, I need to pull data rather than push it.  I'm trying to think of my COP SOP as a function I can call from a Python SOP, but I can't set data on the COP nodes, I need Python to set attributes/globals/ top level parms and then have the COPs get them, which in normal programming terms seems bad, feels like I'm setting a global variable then accessing that global in a function instead of passing data to the function directly.  Again, trying to unlearn what I have learned

[edward]

What's the role of your Python SOP? It sounds to me that it's kinda redundant. Set up the values you need on parameters, and have the COP network reference them.

[GeordieM]

Yup I've almost come full circle, I now have expressions on the COP file and ROP nodes to pull in the file names over time and then render a sequence.  I then just call pressButton() from my Python SOP.  I have another issue with that but I'll start a new thread.