Pressing the cook button on the TOP triggers a non-blocking cook, which mean the cook runs in the background. This is typically not suitable in a headless session because nothing will wait on the cook to finish, and it'll be canceled when it reaches the end of your script and Hython exits.

If you're triggering a cook programmatically in a script you should use one of the various hou.TopNode methods to do so, and pass in the block=True argument. That way your script actually waits for the cook to complete. For example: https://www.sidefx.com/docs/houdini/hom/hou/TopNode.html#cookOutputWorkItems [www.sidefx.com]

pdg.Graph has all of the same methods as pdg.WorkItem for adding/setting attributes. For example, in a Python Script. you can use the following to create a global string attribute named "example" that appears in the MMB menu on the TOP Network itself:

If you want the global attribute to be deleted when the work item that created it is deleted, then you should create the attribute using the Graph (Bound) type instead of the Graph (Global) type as described here: https://www.sidefx.com/docs/houdini/nodes/top/attributecreate.html#stringscope [www.sidefx.com]

Truly global attrbutes are saved as part of the graph if the Save Graph Attributes to .hip toggle is enabled on the network manager node. The purpose of unbound global attributes is provide a persistent place that work items can score key/value data, for example if you wanted to output file versions between multiple consecutive cooks of the same TOP network.

Global attributes are supposed to appear in the MMB window on the TOP Network manager itself, but it looks like that was broken with the introduction of the new MMB info window across all contexts in Houdini. Please log a bug for that.

The ROP Fetch TOP looks for an output file parameter on the target ROP in order to determine where the ROP writes its files. That's necessary for e.g. caching support, so that TOPs can know what outputs already exist before cooking any of the work items.

When the ROP Fetch isn't able to determine which parameter on the ROP defines the output path(s), it issues a warning. It is just a warning though -- not an error -- and TOPs will still cook the ROP. It just can't providing caching functionality or output file reporting since it doesn't know what file paths are going to be produced.

If this used to work before, and doesn't in newer versions, it sounds like the Vray ROP has changed it's parameter interface and renamed the parameter it uses to define output paths. By default, TOPs checks the ROP node for any of the following file parameters: vm_picture, sopoutput, dopoutput, lopoutput, picture, copoutput, filename, usdfile, file, output, outputfilepath, outputimage, outfile#.

You can explicitly tell TOPs which parameter on the ROP node defines the output file path by setting the Output Parm Name on the ROP Fetch TOP, as described in the docs here: https://www.sidefx.com/docs/houdini/nodes/top/ropfetch.html#customoutput [www.sidefx.com]

I don't have Vray installed, so I can't check myself. But double check the name of the output parm on the Vray ROP, and set that as the Output Parm Name on the TOP node.

That should be possible, e.g. by having the ROP Fetch evaluate the frame parameters on the ROP and use the values found there. Please log an RFE.

tamte
I'd still be nice to know why the ROP Node Config creates just a single workitem for the whole range

That mode exists specifically for use with ROPs like the FBX, Alembic and sometimes USD where the frame range isn't known until the ROP actually cooks. For example, the FBX ROP can be setup to load a frame range from an FBX file. In that case the only thing TOPs can do is create a single task that cooks the target ROP exactly as-is, and waits for it to cook over what frame range it wants.

For ROPs with frame ranges defined statically using parameters it's possible to use a ch-ref.

You'll have to have some way to know which work item to actually select. If necessary, you can search through the list of work items in the node and check to see if a given work item is the one you want, and then select it by ID. For example, to select a work item by it's frame value:


The underlying PDG node returned from the TOP node has a property called workItems that contains all of the work items in that node: https://www.sidefx.com/docs/houdini/tops/pdg/Node.html [www.sidefx.com]

There isn't a method to get all work items in the whole graph since it would difficult to provide a thread safe implementation.

If your attribute is a string, you need to use pdgattribs with an 's' on the end. The one without an 's' expects to retrieve the value of a numeric attribute.

Can you attach a .hip file?

Array brackets don't work like that for PDG attributes. You should use the function version instead so you can pass in the index: https://www.sidefx.com/docs/houdini/expressions/pdgattrib.html [www.sidefx.com]

You can select a work item using hou.TopNode.setSelectedWorkItem(), as described bere: https://www.sidefx.com/docs/houdini/hom/hou/TopNode.html#setSelectedWorkItem [www.sidefx.com]

You'll need to pass in the unique ID of the work item -- not the index of the work item in the node. A work item's ID can be retrieved using it's ID property, e.g. pdg.WorkItem.id.

The issue in the new file is that the Geometry Import is wired in after the ROP Fetch doing the render. The Geometry Import will overwrite the output file list, so the downstream Overlay Text doesn't see the input images.

You can set this up with an attribute copy to copy the specific attribute data you need from the Geometry Import, without overwriting anything upstream. Also, from what I can tell, it seems like you only actually only need to run 5 geometry import tasks. The values for the detail attribute seem to be the same for all frames, so they don't need to be imported 100 times.

I've updated the file so that the Geometry Import is wired directly into the wedge, an Attribute Copy is used to copy the attributes onto the renders.

One other thing to note is that you can inspect the inputs/outputs of a given item by Ctrl+MMB-ing on that work item. So for example on one of the Overlay Text work items, the MMB should show some sort of image file in the Inputs section.

It's failing because your Overlay Text doesn't have any input images. The Overlay Text TOP expects the incoming work items to have existing image outputs on them, and it overlays text onto those existing images. That's why I added an OpenGL ROP in my version of your .hip file.

Actually, as a followup, I've made some further changes to the file. Rather than trying to use a multi-line Python parameter expression, it's probably easier to just use a Python Script TOP. I also updated the code to use the new attribute API introduced in H18.0 onward.

For Python expressions you can use the pdg.workItem() global method to access the current active work item: https://www.sidefx.com/docs/houdini/tops/pdg/index.html#workItem [www.sidefx.com]

One caveat with this is that if you're evaluating the expression in the Houdini UI, i.e. not during a cook, there will only be an active work if you've actually selected one in the user interface. pdg.workItem() will be None in a fresh Houdini session for example, until a work item dot is selected in a TOP node. It'll always be set to the active task during the scope of a cook, either in-process or out-of-process.

If you're writing a Python expression that uses that method to access the active work item, you'll need to check if it's None and return some sort of default value in that case if you want your expression to work interactively. This isn't required for HScript expressions like @attrib because they internally default to returning 0 or empty string if there's no active work item in the evaluating thread.

In your file, you have other errors in your script that are causing the task to fail. After selecting a task to use for evaluation, the COP has the following Python evaluation error:


Your Python code is also not returning a value. The last line in your expression should be a return statement -- instead of print(attribs) you should use return attrib so the expression knows what the actual result is.

Finally, the Overlay Text COP expects to overlay text onto some kind of input image. It does that by loading the output file of the parent task, and applying COP nodes to write text onto the images. In your file there are no input files, so the Overlay Text fails to cook because it can't load anything. In order to get it working I added an OpenGL node as an input that renders the scene.

The attached file should cook/overlay the text values correctly.

Yes, the Virtual Environment node works. It's used internally by the ML Regression Train [www.sidefx.com] node that ships with H20.5, as well as the ML terrain [www.sidefx.com] example in the content library that works in both H20 and H20.5.

The virtual environment node creates an environment using Python's venv module -- it does not work with other venv solutions like Conda. It creates the appropriate directory on disk and installs a list of packages to the environment with pip.

It does not, however activate the environment or run any code in the environment. It's still up to you to actually use the venv for something, for example by configuring a Python Ssript TOP to execute in that environment. You can do that by setting the Python Script's Cook Type to Out of Process, and changing the Python Bin parameter to virtual environment. Tasks in the Python Script node will then run using the interpreter in the virtual environment.

The virtual environment cannot be used with in-process Python Script TOP tasks, or other nodes like the Python SOP or Python Snippet COP because all of those nodes run their code inside of Houdini. They can therefore only use the Python interepreter/packages that are emebedded inside of Houdini.

I've attached an example scene file. If you cook the Python Script node and inspect the log for the task in that node, you'll see a print-out showing that the imported module was from the venv's package path.

You can change the render delegate from Karma CPU to Karma XPU on the USD Render Files node, on the Husk Options tab. Note that in H20.5 there were some changes on the karma/LOPs side of things:


Which means that you'll need to explicitly choose the render delegate in TOPs, even if your .usd file has a "engine" render setting.

You can register a custom function that gets invoked each time a graph is cooked, and can return True/False to allow/reject the cook to continue based on the state of the graph: https://www.sidefx.com/docs/houdini/tops/pdg/TypeRegistry.html#registerPreflightHandler [www.sidefx.com]

The documentation for that function includes a reference to a page that describes how to write and install custom handlers. Typically they're placed in the PDG search path and loaded when Houdini starts.

Try middle clicking on a work item itself -- that's the typical place to look for output files. I'm not sure why it's not showing up on the node MMB, but a work item is created for each file so I suspect the files will be listed on the work item attribute panel.

Alternatively, it's also possible you configured the File Pattern node to write the file to a string attribute instead of as an output file -- that will also show up in the work item MMB panel.