I have a collection of 3D assets and I want to do some automated test renders of them for quality control and I'm looking into PDG for that end. These 3D assets are NOT just bgeo.sc geometry caches but a houdini OBJ subnet with a hierarchy inside of nulls and geo OBJ nodes with their own matnets.

Explicit steps from what I grasp atm would be something like:

1 - Set on template points or primitives an attribute referencing which 3D assets network will be loaded and use them to generate work items with geometryimport TOP the work items per 3D asset to be processed.

2 - Load the designated 3D asset into /obj network or an OBJ network, using Python; hou.node("/obj").loadItemsFromFile().

3 - Fit the 4 cameras (Front, Top, Side, Perspective) camera to the 3D asset. This can be done by having the cameras rigged already waiting for a subnet to be passed to then fit to its contents.

4 - Render the 4 images. (Maybe generating 4 new PDG work items per render so it can be scaled if more views are needed)

5 - Composite those 4 rendered images into a single image contact sheet probably with ImageMagik TOP


I suspect I'll find enough material out there for the last two items, but it's the first two and especially step 2 is what I'm asking for some insight.

I did a quick test (attached) and was unsuccessful to use pyhton to create simple objects from scratch and render them individually.


I'm also wondering if it would be best to convert these OBJ networks to USD and if that would make this whole goal much simpler when it comes to PDG managing the variations of the render setup.

Thanks
prb

The Python Script TOP cannot be used to edit the current scene file, since it runs on a background thread. You'll need to either run the Python Script out of process and have it operate on its own copy of the scene, or using a Houdini Command Chain block to create persistent out of process Houdini sessions that you can run multiple scripts with.

Appreciate the feedback @tpetrick , feels like a desert here

tpetrick
You'll need to either run the Python Script out of process and have it operate on its own copy of the scene

Does this mean simply running hython? Cause this would be kind of the "old way" of doing this sort of process, just for loop a hython and open the same scene and run variations in it.

tpetrick
or using a Houdini Command Chain block to create persistent out of process Houdini sessions that you can run multiple scripts with.

I assume you're talking of this: https://www.sidefx.com/docs/houdini/tops/servers.html [www.sidefx.com]
Or this: https://www.sidefx.com/docs/houdini/nodes/top/pythonserver.html [www.sidefx.com]
Do you recall this being demonstrated somewhere cause it's really going over my head

Last one, can the TOP Python Processor help in any of this?

Thanks again
prb

The Python Script TOP has an option to evaluate either in process or out of process. When it's set to out of process, it creates work items that run using Hython by default, but can also be configured to use plain Python or a custom Python executable that doesn't even match the Python version of Houdini. Your script could do something like:


The script has access to a work_item variable that it can use to report output files and attributes back to the PDG graph:


The difference between a Python Script and Python Processor is that the latter is used to generate a custom number of work items, while the former always generates one work item per input and runs a script when that work item cooks. They have same restrictions w/ regard to editing the scene file -- in process work items can't edit the current scene.

tpetrick
The Python Script TOP has an option to evaluate either in process or out of process. When it's set to out of process, it creates work items that run using Hython by default, but can also be configured to use plain Python or a custom Python executable that doesn't even match the Python version of Houdini. Your script could do something like:

import hou
hou.hipFile.load("/path/to/base.hip")
hou.node("/obj").loadItemsFromFile("some/items)
# .. etc ...
hou.hipFile.save()

The script has access to a work_item variable that it can use to report output files and attributes back to the PDG graph:

work_item.addResultData("/path/to/base.hip","file/hip", 0)
work_item.setIntAttrib("some_int_attr", [1,2,3])

The difference between a Python Script and Python Processor is that the latter is used to generate a custom number of work items, while the former always generates one work item per input and runs a script when that work item cooks. They have same restrictions w/ regard to editing the scene file -- in process work items can't edit the current scene.

Thank you, this along with the help I got on Discord I was already able to do OpenGL render of dozens of objects!

One last question here, in your example code I see, `hou.hipFile.save()` and `work_item.addResultData("/path/to/base.hip","file/hip", 0)` reading the manual I'm no really sure what ResultData is. Is it supposed to be a built-in reference to a scene file which will can be used in an abstract way by TOP nodes?

Thanks!

It was just an example I included to show how you can report an output file back to TOPs, which will show up on the work item's attribute panel. Result data is an older term for the output files listed on the work item, which can you can view by pressing the middle-mouse button on that work item in the UI.

Thanks for the detailed explanation! My TOPs hat tip!