OpenUSD (pxr) library in c4d python

llealloo

Ideally, the USD/pxr library in use by c4d's native USD import/export io plugin could be loaded and used by c4d python. It is my hope that in a future version of C4D this will be possible

i_mazlov

Hi Leah,

In Cinema 2023 (as it is the last package shipped with the supported by the usd library python3.9) I quickly tried installing usd-core package using c4dpy as discussed in How to install pip and numpy for Cinema 4D 2024 on MacOS? and it haven't given me any crash.

However, regardless of that please note that according to our Support Procedures we cannot provide support for the third party libraries.

Cheers,
Ilia

llealloo

Hi @i_mazlov, thanks for your response! Did you try:

import pxr

followed by :

from pxr import Usd

I was also able to successfully "install" it, but actually loading the Usd module in the pxr lib was what gave me the crash. Thanks so much for putting eyes on this.

llealloo

Did c4d deadlock when you tried:

from pxr import Usd

So very curious. Thanks again for your help!

Firefly2021

Hi llealloo,
I installed usd-core at C4D R26 by powershell in this folder \Maxon Cinema 4D R26\resource\modules\python\libs\python39.win64.framework, and the following test code works fine and can produce the output usd file.
Hope it may give you more clue.

import c4d
import pxr
# following code from GTC_usd_introduction.ipynb------------------------------
from pxr import Usd, UsdGeom
# Create a tempory stage in memory
stage = Usd.Stage.CreateInMemory('SampleLayer.usda')

# Create a transform and add a sphere as mesh data
xformPrim = UsdGeom.Xform.Define(stage, '/MySphere')

# Set a translation
UsdGeom.XformCommonAPI(xformPrim).SetTranslate((7,8,9))

spherePrim = UsdGeom.Sphere.Define(stage, '/MySphere/MeshData')

# Get the sphere as a generic prim
sphere = stage.GetPrimAtPath('/MySphere/MeshData')

# Get the extent and radius parameters for the prim
radiusAttr = sphere.GetAttribute('radius')
extentAttr = sphere.GetAttribute('extent')

# Access the sphere schema to set the color
colorAttr = spherePrim.GetDisplayColorAttr()

# Set the radius to 2
radiusAttr.Set(2)

# Expand the extents to match the new radius 
extentAttr.Set(extentAttr.Get()*2)

# Make the sphere blue
colorAttr.Set([(0,0,1)])

# Print out the stage
print(stage.GetRootLayer().ExportToString())

# Save the resulting layer
stage.GetRootLayer().Export('SampleLayer.usda')

llealloo

@Firefly2021 this is amazing! thanks so much!

I admittedly have not tested installation of this lib on windows, only macOS. I think it very well might be a macOS issue if this is any clue:
https://github.com/PixarAnimationStudios/OpenUSD/issues/1479

Quoting from the above issue on github:

The USD library cannot be loaded twice into the same process on the MacOS (and probably Linux, not tested yet). It does work on Windows.

This is a continuation of #1341, which was the first problem we ran into. We found an acceptable workaround for the TBB deadlock.

The new problem is that when the second copy of USD gets loaded into the process, it exits the process with
FATAL ERROR: [TF_DEBUG_ENVIRONMENT_SYMBOL] multiple symbol definitions
from line 96 in pxr/base/tf/debug.cpp

What happens is approximately this:

Cinema 4D R23 loads its own USD module, a shared library that links dynamically to libusd_ms.dylib, which does its registration.

C4D loads our plugin (shared library), which loads another of our shared libraries that is statically linked to USD

The copy of USD in our shared library registers its classes, but then it also triggers the registration in C4D's libusd_ms.dylib a second time, which causes the TF_FATAL_ERROR in debug.cpp.

This seems to be related to the DYLD load callback that gets registered by InstallDyldCallbacks() in pxr\base\arch\attributes.cpp. The first copy's callback gets called for the second copy that gets loaded into the process.

i_mazlov

Hi Leah,

I have checked this on Windows platform and yes it works with actually using the library (in my case creating and saving a stage with a single xform object).

I'll have a quick look for this issue on the OSX platform once I have such opportunity, but I won't give you any promises, since as I've already mentioned to you that support for the 3rd party libraries is out of scope of our support.

Anyways, thank you for sharing your findings with the community here, highly appreciated!

Cheers,
Ilia

llealloo

Thanks so much Ilia!

I really appreciate you taking a look even though it's technically out of scope.

A lofty question... Is there any interest among developers there at maxon to expose the usd/pxr library that c4d ships with (albeit internally for USD io) natively within c4d python? That would be a most ideal scenario that I'm sure many folks starting to build pipelines with USD in c4d would love to have... Just thought I'd mention it

llealloo

@i_mazlov I noticed that the current version of usd-core supports Python <3.13! In the latest version of C4D (2025.0.2), CPython is 3.11.4

Which means... In theory, it might be relatively easy to make C4D's native usd-core available to CPython! My fingers are crossed that this message reaches the right person. This would be incredibly helpful to be able to use the native version of USD running in C4D with CPython and not have to touch external libraries.

i_mazlov

Hi @llealloo,

please excuse the delayed answers.

To the best of my knowledge in the near future there're no plans for integrating usd python bindings into c4d python system.

By the way, with the 2025.0 release internal usd library was properly updated to OpenUSD 24.08, so we expect the double loading usd issue to be solved under OSX.

Cheers,
Ilia