Coincidentally, I help develop the Bevy game engine, and I was just talking to people about working on a bevy_usd library. From what they told me, USD is extremely complicated, and the "spec" is basically just the C++ source code. I was warned not to bother. Imo it would be better if glTF just got more support and extensions.
A full Rust port of OpenUSD would be very ambitious. It's quite complicated (e.g. the OpenUSD composition rules) and depends on other vfx c++ libraries.
I've been experimenting with implementating a subset of OpenUSD in Rust, but there's lots of challenges given the original codebase. E.g. the c++ code uses lots of base classes, downcasting and there's no lifetime information. It's possible to port these across, but gets ugly in the details (e.g. trying to avoid non-static downcasting in Rust). It would take a lot of effort to do a total idiomatic rewrite given the size of the codebase and how interconnected the pieces are in OpenUSD. I still think it's worth pursuing though, OpenUSD is great.
Projects that want leaner dependencies, like everything on the web, don’t yet have a good way to work with USD.
Did the web suddenly switch to WebASM overnight or do we have a different definition on "lean dependencies"? using any of the popular JS frameworks seems to bring in a few hundred dependencies alone.
USD started in the very complicated CG/VFX world where this type of complexity and flexibility is needed, however, Apple (and others) have been pushing it into other realms (VR, mobile, .usdz).
What Apple is doing with USD might have been better served by glTF, but glTF is a Khronos standard and Apple refuses to work with them for unspecified legal reasons.
Given that Apple created OpenCL and handed it over to Khronos, this seems a bit off.
> OpenCL was initially developed by Apple Inc., which holds trademark rights, and refined into an initial proposal in collaboration with technical teams at AMD, IBM, Qualcomm, Intel, and Nvidia. Apple submitted this initial proposal to the Khronos Group.
https://en.wikipedia.org/wiki/OpenCL#History
Apple just has a long history of working with Pixar. I think they've been using Pixar's USD as the basis for their AR asset file format since 2018.
https://www.techrepublic.com/article/apples-usdz-ar-file-for...
https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...
> Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework.
Since the details of the dispute haven't come out it's unclear if it has been resolved yet, but regardless they don't seem to be on good terms.
Even GLB, the binary glTF format, is very sub-optimal for runtime. It even has chunks of JSON embedded in it.
Marrying the format so closely to OpenGL is looking pretty dated now of course, with OpenGL/WebGL dead and buried by Vulkan/WebGPU. You can render glTF with Vulkan/WebGPU but the flexibility of the format and the newer APIs rigid pipeline layouts are at odds with each other - ideally you want the data to follow a consistent, rigid layout.
