USD format?

Specific Domains Visualization
1

Are there any current packages around that support USD in some form?
https://graphics.pixar.com/usd/docs/Introduction-to-USD.html

Looks like it’s becoming the way to exchange 3D scenes between applications.

I’m interested in sending 3D data from julia over a socket to be visualized/edited on a client. I’ve been making due with my own simple format, but would eventually like to support something standard. Visualization directly from julia would also be handy.

I was kinda pulling for glTF as it’s a “tighter” format, but I’m happy that consensus on a single format appears to be forming.

4 Likes
2

I wanted to ask if anything has happened on that front.

Omniverse seems to grow (with NVIDIA warp also digging into more traditional computational domains like FEM). Also, USD could be used for applied research as a quite powerful layer to describe/store scenes.

I’m thinking of wrapping some bits of GitHub - PixarAnimationStudios/OpenUSD: Universal Scene Description as I have a project involving NVIDIA warp for which a Julia bridge would be great.

[But I don’t want to raise expectations. I still struggle to make proper time besides my other research and there are a few other Julia things I really would like to work on.]

2 Likes
3

I / We would love OpenUSD support!

4

Welcome! FYI: Since you’re new here. It seems to me you could use OpenUSD already with Julia. You can call (C++ and/or) Python, i.e. with PythonCall.jl. That’s my standard answer for Python software. I do not see an exception to using this Python/C++ software from Julia.

I might be wrong. E.g. it’s unclear to me you need this:

  • PySide6 or PySide2
  • PyOpenGL

What I do not see as a hindrance is quote the “open source” license:

Note: The Tomorrow Open Source Technology License 1.0 differs from the original Apache License 2.0 in the following manner. Section 6 (“Trademarks”) is different.

It’s not OSI approved. But it gives you more rights than MIT, e.g. patents, but less than Apache, i.e. not trademarks.

Julia insists on open source for registering packages, meaning (to simplify knowing if for sure open source), an OSI approved license.

If you make software from scratch you can do that, but if you port software, you usually use the same license (porting it would be derived, just using the format would be less clear).

Software using this license would not be automatically approved for registration as a package, but I would argue for an exception. A wrapper for this, could be OSI approved(?), should mention license of what it’s wrapping.

Note also for a different dependency (same license, didn’t confirm same exact modification):