Guilherme Casagrandi

tpetrick
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.

can the virtual env be used with python processors?

joostkonemann
Sent the same questions to support and got a suggestion for a workaround:

"The HDA Processor currently doesn't have any options for controlling how .usd files are are written out. We can turn this issue into an RFE for that, but the best workaround now would be to create an instance of your HDA in your scene and use a ROP USD Output TOP to write out USD files instead. That TOP node has the same options for writing out .usd files as the equivalent ROP -- for example flattening, output processors, etc."

An RFE (#149757) is logged to add USD save options to the HDA processor.

We have a publisher in place that handles a significant amount of work on top of the incoming USDs. We have a stage inside the TOP HDA, where we cook the output layer as we prefer, typically the same way you do, without flattening. In other words, if you really need your HDA, you can embed it in another one that will do all the work.

edward
It's still on the roadmap. There was a bigger project to bring APEX into Solaris but unfortunately, we ran out of time for the H21 release.

I thought you guys would bring everything to SOPS and move away from object-level, since it's the only remaining context that is not procedural... kind of a packed camera.

Building the shot in a mix of obj and sops before moving to Solaris/USD is still valid and, for many reasons, faster and easier to manage than in the stage.