Search - User list
Full Version: changing parms from a external process
Root » PDG/TOPs » changing parms from a external process
orr
Hi All,

I am trying to execute a pdg graph from a external process. I do something like this…

hou.node("/obj/topnet1/ropgeometry1").parm('sopoutput').set(geopath)
hou.node("/obj/topnet1/").dirtyAllTasks(False)
hou.node("/obj/topnet1/").executeGraph(False, True, True, True)
hou.node("/obj/topnet1/ropgeometry1").getPDGGraphContext().cook(True)

This code runs several times with different geopath values. It works well.
However, once geopath is changed in the external process, and the graph is executed again, it'll still save to the location that was given the very first time. So, I assume I am not getting something here or the parm values are cached somewhere. Any help would be much appreciated.


Thanks,
chrisgreb
Could you clarify what your setup is:
What ‘external process’ do you mean?
When you say the code runs several times do you mean one process in a loop or sequentially in different processes?
orr
chrisgreb
Could you clarify what your setup is:
What ‘external process’ do you mean?
When you say the code runs several times do you mean one process in a loop or sequentially in different processes?

Yes of course. The external process is a python script loading hou through rpc to communicate with an open houdini instance, which usually works well. I see that the parameter is set by the script and it works for any other PDG nodes (for example csvoutput), but it in this case during cooking it's just ignored. The above code is running in the script in a loop where geopath changes every iteration.

If I set the parameter through the script above and cook it manually (shift+V) in houdini, everything works and the files are written to the right location given by the parameter.
coleclough
Hello there. I seem to be having a similar issue, possibly with the same underlying cause.

I have made a topnet inside of my HDA that cooks textures. Parameters from the topnet are promoted to the HDA interface however cooking from the HDA interface (using hou.TopNode.executeGraph(1,0,0,0)) doesn't update the parameters on the top nodes, leading the graph to always cook with the same parameters as your first cook that session, unless you shift+v.

Forgive me if I am missing an obvious function. I have tried cooking using hou.TopNode, pdg.GraphContext and pdg.Node, all of which yield the same results. I have also tried hou.TopNode.dirtyTasks/AllTasks(0/1) and pdg.Node.dirty(0/1)

This is a big issue as it really hinders the usability of my HDA.
orr
coleclough
Hello there. I seem to be having a similar issue, possibly with the same underlying cause.

I have made a topnet inside of my HDA that cooks textures. Parameters from the topnet are promoted to the HDA interface however cooking from the HDA interface (using hou.TopNode.executeGraph(1,0,0,0)) doesn't update the parameters on the top nodes, leading the graph to always cook with the same parameters as your first cook that session, unless you shift+v.

Forgive me if I am missing an obvious function. I have tried cooking using hou.TopNode, pdg.GraphContext and pdg.Node, all of which yield the same results. I have also tried hou.TopNode.dirtyTasks/AllTasks(0/1) and pdg.Node.dirty(0/1)

This is a big issue as it really hinders the usability of my HDA.

Hey. Interesting. For me some parameters do update and some don|t. A workaround for me is to set the attributes in the top network through a csv file and then use those attributes as parameters for the other tops. Maybe that helps.
tpetrick
I think the problem in your case is that need to save the .hip after setting the parms. The parm you're setting is on the ROP node targeted for the cook, not on the TOP node itself. The parms on that ROP are not evaluated by PDG, but by ROPs itself when the job is cooking out of process. E.g.:

  1. PDG generates a ROP work item to cook the node “/obj/topnet1/ropgeometry1”, and sets the target hip to $HIP
  2. The job is scheduled locally/on the farm
  3. The job starts hython, loads the specified .hip file, and cooks the ROP

So if the .hip is not saved, the parm change won't be available.

The reason it works when you change the parms in the current Houdini session is that Houdini will normally pop up a graphical dialog prompting you to save you .hip before cooking the TOP network. There's a button on that dialog to “Do this every time”, which makes the saving happen automatically, but that option is stored as part of the dialog system. In a non graphical session, it doesn't enter the code path to check if the .hip file needs to saved.

I think we can fix it so that it always saves the .hip before cooking the TOP network in a non-graphical session, but in the mean time you can do that through hou.HipFile.
orr
tpetrick
I think the problem in your case is that need to save the .hip after setting the parms. The parm you're setting is on the ROP node targeted for the cook, not on the TOP node itself. The parms on that ROP are not evaluated by PDG, but by ROPs itself when the job is cooking out of process. E.g.:

  1. PDG generates a ROP work item to cook the node “/obj/topnet1/ropgeometry1”, and sets the target hip to $HIP
  2. The job is scheduled locally/on the farm
  3. The job starts hython, loads the specified .hip file, and cooks the ROP

So if the .hip is not saved, the parm change won't be available.

The reason it works when you change the parms in the current Houdini session is that Houdini will normally pop up a graphical dialog prompting you to save you .hip before cooking the TOP network. There's a button on that dialog to “Do this every time”, which makes the saving happen automatically, but that option is stored as part of the dialog system. In a non graphical session, it doesn't enter the code path to check if the .hip file needs to saved.

I think we can fix it so that it always saves the .hip before cooking the TOP network in a non-graphical session, but in the mean time you can do that through hou.HipFile.

I see. That makes sense. Thanks so much for clarifying.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB