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.

The progress updates with a percentage that are printed out are enabled by the "Use Alfred Progress" or "Alfred Style Progress" toggle on the ROP node. The ROP Geometry TOP enables that toggle automatically while the task is cooking -- in your case, you'll need to either set the parm as enabled in your script or save your scene file with the parm enabled. Most ROP nodes should have that toggle to enable progress messages in the output log.

For tasks that run on services there isn't a separate log file per work item -- there's a single log for the whole service client. However, the individual log data for work items that ran on a service client is available through the pdg.WorkItem.logMessages property, which is basically just a string buffer containing the log data that was produced while that work item ran. That's also where log data is written for any in-process work items that call addMessage, addWarning or addError as part of their script code.

You can determine the name of the service client that ran a particular task using the pdg.WorkItemStats object returned from the pdg.WorkItem.stats(..) method. That object contains the various cook time durations for the work item, as well as the name of the service client that ran the work item if applicable:

You can access the active work item using pdg.WorkItem() in a Python Expression, and use that to look up the index, attribute values, etc. There's an example in the documentation for the PDG Python module: https://www.sidefx.com/docs/houdini/tops/pdg/index.html#functions [www.sidefx.com]

The next release also has a top-level pdg.attrib(..) function that mirrors the HScript equivalent.

PDG can't parse the special path tokens used by the bake texture node when determining expected outputs for the work item. If your bake texture output path has tokens like %(CHANNEL) or %(UDIM) then there's going to be a mis-match between the expected files on the work item, and the output files actually produced when the ROP cooks. That'll cause the message you're seeing -- it's a warning though, not an error. It just means that caching won't work because PDG can't tell what the outputs are ahead of time before it cooks the ROP.

When you say the file is created and then deleted, do you mean the texture file on disk itself is deleted?

The exception itself is coming from Maya. It looks like the API has change slightly in the last few versions. You should be able to replace the last two lines of the script with:


instead of:

JonasSorgenfrei
Another thing, when i change the Server Type from Shared Server (deprecated) to Service i get the issue
cmd command not found.

Does anyone has an working example of services with maya ?

Current PDG does not support running Maya as a service out of the box, although the plan is to have that finished for H20.5. It would technically be possible to write your own custom Maya-based service and use it with the block in H20, which is why the option is still available on the block.

I haven't seen this happen before on either Windows or Linux. Can you provide a higher resolution image that actually shows the title bar/command line for the popup window -- the gif is too low resolution to tell what it's actually running. Additionally, please attach a Houdini info.txt (Help -> About Houdini -> Save). You can also log that as a bug with support instead of posting it on the forum if you prefer.

Can you attach a .hip file demonstrating the issue you're seeing? The Bake Texture ROP cooks as expected for me, and lists output files on the work item.

The warning occurs because PDG needs to be able to determine the work item's output paths before cooking, and the Bake Texture ROP doesn't follow the standard output parameter naming conventions. You can either specify a custom path list or add vm_uvoutputpicture# as a custom output parm.

That's covered by the ffmpeg documentation: https://ffmpeg.org/ffmpeg.html#Main-options [ffmpeg.org]

-y (global) Overwrite output files without asking.

papsphilip
that didn't work unfortunately.
added hou.parm('/obj/EXPORTS/camera_to_points1/renderme').pressButton() as a pre-render script
but still when the TOP cooks the workitems the output images are all the same, from the same frame.

Your script is in the pre-render parameter, which runs once per render on the first frame of the render. It sounds like you want to have it in the pre-frame script instead, which runs once a frame.


Regarding the the reload parameter option on the ROP Fetch itself, the button specified in that parameter should be pushed every frame even when using a batch.

The script parameters on the ROP Geometry Output are on the underlying Geometry ROP itself, and are just promoted onto the TOP node. If you want to run a pre/post script with a ROP Fetch you'll need to put them in the pre/post script field(s) of your ROP.

Nuke doesn't work with services yet in H20, and probably won't until H20.5, which is why the Nuke block still defaults to using shared servers.

The Venv Path parameter is intended to be used with environments created using the Python Virtual Environment TOP, which uses Python's built-in venv module to initialize the environment. It currrently does not work with virtual environments that require initializing a custom shell environment, e.g. Conda.

When running out of process or using services, the script runs in a separate process that doesn't have access to the original .hip file. There are no nodes or scene at all -- just the script code and the work item data.

How are you cooking your graph? If you're pressing the Submit button on the Deadline scheduler, that submits your entire scene file as job to the farm. If you want to cook interactively you should first set your Deadline scheduler as the default, which you can do by Right-mouse clicking on it and finding the option in the list. Then you can cook normally by using Shift+G on RMB->Cook Node on your output node.

If you're using Python, you can use the Python API instead of HScript. There's an equivalent function in Python for all of the things available in HScript, for example: https://www.sidefx.com/docs/houdini/tops/pdg/WorkItem.html#inputFilesForTag [www.sidefx.com]

So for example from a Python parameter expression, you can use pdg.workItem().inputFilesForTag("file") to get a list of all input files, or pdg.workItem().inputFilesForTag("file/image") for all input image files.

If you're using a Python Script node, which already has the work item stored to a work_item local variable, you can use: work_item.inputFilesForTag("file").

In that case, pdginputvals(..) returns the list of all inputs as a space-separated string: https://www.sidefx.com/docs/houdini/expressions/pdginputvals.html [www.sidefx.com]

And, you can also use pdginputsize(..) to get the actual number of input files with a particular tag: https://www.sidefx.com/docs/houdini/expressions/pdginputsize.html [www.sidefx.com]