Isotropix Forums

Need
We would like to use USD native API within Clarisse.

Why
To use internal pipeline API relying on USD

- Usd Transforms: pxr.Gf.Rotation, pxr.Gf.Vec3f, etc
- UsdStage

How can we access to Pixar API from Python
There is usd.so in Clarisse build, but it seems that no python binding is implemented.
Should we build on our own usd and mix libraries with Clarisse at runtime ? That might brings side effects.
I would prefer option 1 for stability purposes.

Thanks for your feedback.


Alexis OBLET - CTO
The Yard VFX

Hi,

Unfortunately we are providing USD as a monolithic library (e.g. the only .so is `libusd_ms.so`, if I'm not mistaken; the `usd.so` file located in Clarisse's `module` directory is our USD integration module, not the official USD library)
And USD has ("had", at least. I haven't checked on more recent versions) issues generating Python bindings when it's built in monolithic mode.
So even if you wanted to build your own USD libs, you'd need to build them as a monolithic lib for Clarisse to be able to pick them up, and you'd probably hit the same problems of Pythong bindings failing to link. If you can fix that though, it might work (you'd need to use the same version as USD as we do, obviously, which is v22.03)

All that being said, do you have an example of why you would need to modify a USD stage from withing Clarisse specifically? (instead of modifying externally, and just reloading the reference or bundle in Clarisse?)

Regards,
Damien.

Thanks for the feedback.

The idea is to generate an USDA conformed to our pipeline rules and naming convention (internally in the structure).
This export would be based on non existing USD stage or USD stage.

Workflow
It would be:
- Import references in Clarisse (abc, usd, etc)
- Use Clarisse tools (scatter etc)
- Export USDA environment (with the choice of PointInstances or not, conform structure name)

The native usd API usage is required for the last point.

Hi,

We have some clients that have such validation done on their export from Clarisse. In their case, this is usually an external tool (which can be invoked from inside Clarisse using a bit of Python glue) which alleviate the need of having access to USD's Python API from inside Clarisse.
I'm not sure if this would be a viable alternative in your case, but it might be worth a try.

And also, if those pipeline rules are mostly related to scene structure and naming, wouldn't it be possible to validate/conform the Clarisse scene directly? e.g. using the existing Python API to modify Clarisse objects, rename them, make sure everything will be ok, and then use Clarisse's USD exporter?

Clarisse > USD > Confo
It could be done it two steps, you're right.
One advantage in this way: we handle easily recursive Combiner / Scatter instanciation.
And to abstract Clarisse internal pipeline.

Clarisse USD API export
Can we trigger USD export from python api ?
It seems only USDExportUI is publicly exposed.
./clarisse/python3/menus/main_menu/file/export_usd.py

USD Native API
I built USD with a custom namespace PXR_SET_INTERNAL_NAMESPACE and lib prefix PXR_LIB_PREFIX.
Then no collision at runtime with yours.
It works.

Hi,

Yes, the USDExportUI is intended to be usable via script. You just have to create the object, configure the attributes via script like you would via the UI, and then call the action. Something like that:

python3 code

# select the context you wish to export
ix.selection.select("build://project/final_layout")
# create and configure the export object
export = ix.create_object("export", "UsdExportUI")
export.attribute_exists("filename").set_string("D:/Document/USD/final_layout_export.usdc")
# and export.
export.call_action("export_context")

Great !
Thanks for your help Damien.