This is a big deal. I used to work at Autodesk, trying to build software that made 3D blueprints available to everyone, everywhere. Rendering things on mobile is hard, in part because you need to writer bespoke renderers, and in part because the data formats for the assets are not aligned.
Pixar developed USD, and it should really help to standardize 3D tech. In particular, I hope that USD can help make it easier to build high-performance rendering tech for a variety of applications that might not receive so much attention from the 3D graphics people (this is one thing video games do quite well, from a CS approach!)
Having some big names behind the standard should help, but of course, the proof will be in the pudding as to how meaningful their contributions are, and how much their involvement pushes the adoption of the standard.
Looks nice. However the issue with all 3d streaming I've ever tried is latency. It's great if you're near the server. Terrible if you're far away.
It's hard so say what the input latency is for the head demo you shared. I guess about 100ms, which is totally fine for a mostly static scene with simple orbit controls.
However I also tried out the Lebron James vs Father Time game. Input latency is over 1 second so it's not playable. Any time I touch the screen it freezes for a second then jumps to the new location.
While of course I want latency to be as low as possible, the difference between 100ms and 500ms of latency doesn't register in the engagement metrics for these experiences. For millions of laypeople, it doesn't seem to matter that much. However, going from 670ms of time to first image (this service) and 2.5s (worst case) increases bounce rates by as much as 5 percentage points. PureWeb, which typically takes 35s to load, isn't suitable for any mass audience at all.
So imagine downloading a USDZ file for some AR thing. It's real, it's something people try to do. But the bounce rates on those experiences are insane, I don't know why Niantic funds them, there isn't anything you can do about it. There isn't a future for "it takes a while to load" on phones. That's the real constraint.
OpenUSD has a plaintext encoding mode, which by convention gets saved as .usda. The standard OpenUSD SDK contains two command line utilities `usdcat` and `usdedit` to do plaintext editing, but most programs using the SDK have better editing functionality by directly using the C/Python SDK.
The ASCII (plain-text, .usda file extension version) absolutely.
For large scenes/models, the normal .usd binary/compressed version is often used for efficiency reasons (and proper round-tripping of float values for xforms, etc), but you can convert between the two with the 'usdcat' util and the python/c++ apis for debugging.
Why do so many (all?) textual data serialization formats represent floats in base-10 scientific notation, anyway?
If we wanted floats that are 1. human-editable but 2. bijective with IEEE754, wouldn't floating-point hexadecimal (and "e" notation representing a base-2 exponent) be a better idea?
I mean, depends on the human. Most don't know hexadecimal, but know what 3.14 means.
The real issue is why do so many float parsers and printers fail to do exact round tripping? Designing a good algorithm for this was a bit difficult, but these days this is a solved problem.
If I had to take a slightly snide guess: because these are low level tools, so there's a 90% chance that these parsers/prints are written in C, or ultimately depend on C implementations. As any C programmer would know, C loves to throw "undefined behavior" at any problem it doesn't bother to document. Which is a lot.
That combined with almost zero package management for retrieving things that were solved decades ago means we keep coming into this issue, partially
because of the mindset of C programmers.
This is just "hur dur C undefined lol" level of a comment.
If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse. If that means implementations have to ship their own float formatter and parser than so be it - no one is tied to whatever comes with their libc, package manager or no package manager.
But it isn't just about undefined behavior, it's more about the culture of C and how it approaches package management and sharing (or in this case, doesn't). Even if C has Rust level correctness checking it would have the same issue.
>If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse.
Well I guess we have our answer in the case of seriousness. I'm guessing it didn't matter enough for the implementers, or it did matter but could never actually get it implemented. The reasons for this are numerous, contextual (with context we'll never have), and probably not rooted in technical reasoning.
We are talking about the domain of animation and games, after all. Not mission critical code. There's more wiggle room, especially for the complexity of media around when the format was being developed.
The best of both worlds, at least in my opinion, would be to write a float as a polynomial in two parts (where either part alone is still a float): an integer part with an optional scientific-notation exponent; and a fractional part, where the fraction's denominator is always a power of two.
So 5e3 is a float; 3/8 is a float; and 5e3+3/8 is a float. Each cleanly and exactly representing particular IEEE754 values, while also being readable as a base-10 polynomials.
Maybe fractions of arithmetically-specified powers of two could also be allowed, for really big denominators. 3/2**26, for example.
That's not particularly user-friendly though: at least for CG/VFX software (where USD came from and is designed for), non-technical (at least in terms of understanding IEEE floats) people like artists often want to look at the values to verify stuff for 'debugging' (i.e. is the software tool I'm using actually exporting the correct values I selected in the UI params panel).
Having to do any form of interpretation (even scientific notation is not ideal in some cases), is not great for many users.
This would seem to point to a fundamental impedance mismatch between textual dump formats used as debugging aids; vs textual project file formats which are human-readable for the purpose of permitting the use of text-based tools to process low-level data structures of the project before it's loaded back in.
Most OOP languages have a "debug print" or "shell inspect" method that the programmer can override, where by default the method will print something that's valid language syntax, but where the overrides aren't required or expected to be such, and instead should concisely describe the object at the expense of being reloadable. These same languages usually also have support for custom serializers for text-based serialization formats like JSON. The serializer implementation for JSON, and the serializer implementation for "shell inspect", are rarely identical.
I think what a CG/VFX artist would want here, isn't that the canonical textual file-format "for import" gives them decimal-serialized floats; but rather that they have the option to "inspect" the project, resulting in a view that looks like e.g. https://www.tonymacx86.com/media/ioregistryexplorer.187440/f... — an hierarchically-expandable "shell inspect" of the project. It makes perfect sense for the floats in such a read-only debugging-oriented view to be rendered in decimal (esp. if a raw canonical binary-data representation is given in parentheses beside the rendered value.)
FWIW, well-implemented round-to-nearest conversion routines (e.g. Python and IIRC Glibc, although MSVC is historically bad about this) will roundtrip IEEE>decimal>IEEE if you use the correct number of digits (at least 9 for singles and 17 for doubles), for reasons of mathematics and not implementation. (The other way around also works, barring exponent under- and overflow, but for at most 6 and 15 digits respectively, so I wouldn’t call bijective, strictly speaking.)
The conversions are not even that hard ... unless you want to deal with arbitrary (and arbitrarily long) decimal representations and not just those that arise from IEEE numbers. Essentially the only choice to make is whether the conversion to decimal will emit all the digits all the time (simpler) or the shortest number of digits that will round to the requested IEEE float when read back (less liable to be mocked in webcomics[1]).
Of course, using hex floats is much simpler than even the simplest implementation of the above; I just want to point out that IEEE floats are perfectly roundtrippable through decimal.
I’ve been happy with what modelviewer.dev offers me; someone with very little experience with 3D on the web. It’s basically a wrapper for three.js to view glTF files quickly and easily. It lets me load very small files and interact with them with JavaScript.
It’s perfect for my needs as an educator and I know just enough to be able to show other educators how to create and deploy their own learning materials.
I do remember VRML. I read a book about it and spent some time playing around with it in the mid-90s. I didn't follow it closely enough to know when it died off (I'm assuming it died off since I haven't heard it mentioned much in decades).
VRML is still around — it became X3D. It's a different file format but the semantics are much the same.
All the plugins that used to be needed to display VRML online are gone now, but you can still display VRML 2.0/97 files online using JavaScript library called X_ITE [1]. I used it recently to view some old VRML I had saved but could no longer view. Works great.
Sounds like you are looking for react-three-fiber, which looks just like this!
The examples, demos, and development experience are great, but since it's based on web tech hasn't made a big splash yet with the bigger 3D content businesses.
There was a company in Sweden that built a system that used VRML and extended like that where you could define what the nodes were and reference and re-use them. The system also enable Python to script behaviour.
It also used the PHANToM for haptic feedback and used a 3D stereoscopic display
USD will be great for animators, but I think the biggest beneficiaries will be AI's. The question of how and at what layers AI could interact with 3D art and still give the final aesthetic decision to humans with a true artistic eye left a big gap in willingness to use AI for 3D projects.
If, essentially, they are speaking the same language as humans, this curation becomes trivial and the cost of incorporating AI becomes purely artistic in nature rather than a technical or organizational cost. There will be no downside for a 3D artist to tell the servers "render this scene, but generate a few different versions if you finish before I get back to work tomorrow" in the worst scenario it is electricity used, in the average scenario it can inspire new ideas, and in the ideal scenario it creates something usable.
> but I think the biggest beneficiaries will be AI's
It's just another 3D file format, calm down ;)
There have been quite a few "standard" 3D file formats in the last 30 years (COLLADA, FBX, glTF, to name a few of the more popular ones, check here for a more complete list: https://github.com/assimp/assimp/tree/master/code/AssetLib), USD isn't anything special except that Apple is involved (which means you probably shouldn't put too much hope into the "Open" prefix, or at least expect that Apple jumps ship as soon as the first cracks start to show in the "alliance").
I don't think we'll have 3D AI art anytime soon. Most if not all AI for 2D works on a pixel basis. 3D is more like SVG, except there is a whole third dimension to contend with. There are AIs that manage to produce SVGs, but I have yet to see a clean one where the objects are actually properly grouped and not just a bunch of random shapes thrown together to do a vector approximation of pixels.
If anyone finds an AI that can do reasonable SVGs, please do let me know.
nvidia uses usd as standardfileformat in its omniverse 3d suite. They are starting to integrate AI into it, for example to convert an image into a 3d scene.
It's a standardized file that describes a 3D scene (with references to assets, transforms, etc). It makes asset pipelines easier to spin up and iterate on, but I don't think anything about USD specifically will further enable AI art projects more than they actually do.
I find it slightly odd that SideFX aren't part of this. They have worked very closely with Pixar on integrating USD into Houdini in a new subsystem/type of network called 'Solaris' / Lops. It is a very deep and powerful integration too: You can edit USD data using the Python Lop (pxr.Usd API) or even with Vex/Vops (a SIMD-focused language that can be 'written' using 'Vop' nodes that compiles to bytecode and runs (fast) on LLVM.) Makes sense considering how much Houdini gets used to create assets (including at Pixar and for many AAA games as well.) Hopefully the alliance don't make things harder for Solaris! (Autodesk is a direct competitor because of Maya).
I couldn't agree more, and that's from much experience working in VFX on tools/code and contacting SideFX support a lot (mostly by email) It's just been some astoundingly good support! I hope they last forever, and if they ever do have to pack it in, I hope they release the source so that Houdini can live on.
Solaris (in Houdini 18 I think?) was my introduction to USD and a pretty deep rabbit hole for a few weeks.
Although its functionality is way beyond a solo hobbyist's needs, the whole time I was thinking about how cool it is to have a standardized format, and how much it must benefit teams working together on a project.
Excited to see this potentially integrated into FreeCAD. It is already very good at utilizing assets from other applications like Blender, and producing assets that can be used in other applications.
It would really help smooth out some wrinkles in the building industry if we could freely interoperate with each other while using different applications. I can't afford (stomach) anything but FreeCAD for my building projects. All the engineers I work with use autocad.
I didn't submit the PR yet, but opened an issue which has not been picked up. Maybe most of the USD files used in Blender do not trigger the O(N^2) behavior.
Interesting. Since the list is sorted, is the insertion still a linear search (O(N)) or now a binary search (O(log(N))? Or did I misunderstand something? Also, why is it not a hash table (almost O(1))?
Good point, I have the same doubt. Even if it is sorted, you still cannot do binary search on it unless using some skip list ideas. In fact, the code right now is doing linear search to find the ID given a name.
TBH, I don't fully understand how the ID linked list is utilized in Blender and why it needs to be sorted by names. It seems some other data structure could also work, unless I missed something.
Blender could in theory join the Alliance, but a lot of the companies in the Alliance do already contribute for USD support in Blender as well as other features. NVIDIA and Apple do quite a bit.
I see lots of off topic comments, but I'd like to ask as someone who played with fbx and similar formats supported by Autodesk and large parts of the gaming/CG industry what does OpenUSD provides exactly over different formats.
I feel like there's never been a 3D counterpart to standards like Midi for audio.
For one the reference implementation of USD is open source, unlike FBX where you have to depend on Autodesks binary blobs and are at the mercy of whatever jankiness comes with them. Such as the fact that the FBX SDK still isn't thread safe in TYOOL 2023 so you have to take a global lock whenever you touch it.
Even Autodesk is backing USD so presumably even they have given up on the long term prospects of FBX.
glTF is actually pretty good. It just's fairly minimal and lacks support for an entire scene description, lacking important features such as LODs.
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.
Yeah, working with OpenUSD in Rust is difficult. There's been a bit of work on Rust bindings but it's not ready at the moment (https://github.com/vfx-rs/usd-bind). I believe you need the c++ code base locally for the bindings, which adds an extra barrier for development.
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.
That gives me serious collada vibes. I've been out of the space for ~6 years but I recall that collada was the thing that was supposed to solve all of this, looks like it didn't really take off.
>Projects that want leaner dependencies, like everything on the web
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.
glTF is really single-asset only: that's not what USD is - USD is designed for entire scenes with scene graph hierarchy, and layers of overrides / additions (it's essentially a mini-evaluation engine internally). It's very powerful, but also quite complicated, and not just a file format.
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).
GLTF supports scene graphs. But given what domain creates and primarily uses it, most of its usage in projects will inevitably treat it as if it's an FBX substitute. We're still far from the days where Unity/Unreal Engine will export an entire scene into a hierarchy of gltf files with one master file to organize them.
They serve different roles, glTF is intended to be an asset delivery format that aligns with how GPUs work so it can be loaded onto one with fairly minimal overhead. USD is intended to be an interchange format for moving assets between editors and renderers. They're kind of analogous to JPG/PNG and PSD respectively, if PSD were an open standard.
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.
> glTF is a Khronos standard and Apple refuses to work with them
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.
They used to work with Khronos but things have developed since 2008 - Apple has completely abandoned OpenCL and OpenGL, won't support Vulkan alongside Metal, and during the development of WebGPU one of their representatives let slip that there's a legal dispute blocking any further interaction between Apple and Khronos.
> 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.
Interesting. I thought it was simply a matter of Apple wanting full vertical integration of its hardware, as usual. Since all these rumblings really started rolling right before the M1 chip was announced. Didn't know those tensions evolved into a full on legal battle.
glTF is not a very optimal runtime format, and IIRC it even started out originally with the statement that it was 'purely for interchanging models between programs' and that engines would/should still use their own format (hence the Transfer Format in the glTF name.)
Even GLB, the binary glTF format, is very sub-optimal for runtime. It even has chunks of JSON embedded in it.
glTF wouldn't be my first choice for a runtime format but it's hard to see the intent behind it as anything but a runtime format, there's a very distinct mapping from glTF concepts to OpenGL concepts. The first version didn't even have a standard material definition, the asset just had an inlined GLSL shader to render it with. They even use the same enum values so that you can plug the values in the glTF file directly into an OpenGL call if you want to.
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.
Vulkan requires everyone to be a driver writer before they can even think about drawing a triangle, while at the same time already beating OpenGL with spaghetti extensions at the rate it is getting new ones every month.
And it is only a GNU/Linux and Android thing anyway, not the main API on PlayStation, XBox, Apple, Windows and Switch.
WebGL took a decade to be fully adopted, WebGPU has at least another decade ahead of it until it becomes fully widespread, and even then it will be targeting 2015 hardware capabilities.
>Vulkan requires everyone to be a driver writer before they can even think about drawing a triangle
No different than DX12/Metal. these new APIs were made because driver writers need more power. But that means the usage will be niche, either for top companies who can throw money to find driver writers or hobbyists who invest in the future (or become headhunted by said top companies).
>And it is only a GNU/Linux and Android thing anyway, not the main API on PlayStation, XBox, Apple, Windows and Switch.
To be fair, OpenGL was never the main API for Xbox/Apple/Windows to begin with. And it's been several generations since Playstation/Switch really endorsed OpenGL. I wasn't expecting Vulkan to change that overnight.
That said, Nintendo does seem to welcome Vulkan more warmly than Sony has. So that's one more major player.
> No different than DX12/Metal. these new APIs were made because driver writers need more power. But that means the usage will be niche, either for top companies who can throw money to find driver writers or hobbyists who invest in the future (or become headhunted by said top companies).
The BIG difference is that DX12, Metal, LibGNM(X) and NVN come with productive SDKs, documentation, IDE tooling, frameworks, in a big support package.
> To be fair, OpenGL was never the main API for Xbox/Apple/Windows to begin with. And it's been several generations since Playstation/Switch really endorsed OpenGL. I wasn't expecting Vulkan to change that overnight.
OpenGL was definilty the main API on Apple platforms after OS X was introduced with its NeXTSTEP roots, and if it wasn't for Apple endorsing GL ES on the iPhone, no one would have cared.
Symbian did support it, but it wasn't until Asphalt on N95, that it mattered, given that it was doing software rendering on most devices.
> That said, Nintendo does seem to welcome Vulkan more warmly than Sony has. So that's one more major player.
While the Switch supports GL 4.6 and Vulkan, it is NVN, what most studios actually use.
>The BIG difference is that DX12, Metal, LibGNM(X) and NVN come with productive SDKs, documentation, IDE tooling, frameworks, in a big support package.
well of course. they are closed off (in both source and general tribal knowledge. Hell, the docs for GNM/NVN aren't available without a license), locked down to one platform each, and their customer base is overwhelmingly enterprise. And each has a dedicated full time team to consult with. It's no surprise they can give more focused suites when their job is more or less to wrap you into their respective ecosystem.
If you are fine focusing on one platform, or relying on a huge library/framework/engine to abstract all these APIs for you (which remember, you need to provide some license for, except DX12. So another barrier), you can get a bit more convenience. But if you can't use those and/or want to target Linux/Android, you lose some of that for a more flexible, agnostic API (and probably some small performance hitches on the highest end. Vulkan can't assume 2-3 configurations like Gnm/NVN after all).
>if it wasn't for Apple endorsing GL ES on the iPhone, no one would have cared.
Well, Apple at the time basically made people care about mobile graphics at all, so you are technically right. But they could have raised Glide from the dead and made that matter for all the early control they had.
Apple certainly does have a rich history with OpenGL, but we all know how that eventually ended up. It was a long time coming but the breakup was much more spontaneous than I ever would have guessed. Definitely seems to be more than technical shortcomings behind that story.
> what does OpenUSD provides exactly over different formats
USD is to scene authoring what FBX is to 3D object authoring (though it also can do 3D object authoring).
USD adds complex shading, lighting and cameras, state-of-the-art multi-level instancing workflows, and most importantly, a very flexible way of referencing/layering assets and performing per-scene or per-shot overrides, plus tools (payloads) that enable extremely large scenes to be opened and authored in minutes instead of hours.
It really is pretty groundbreaking and has a ton of momentum.
The other hugely helpful component is USD has a very high-performance rendering architecture written in C++ called "Hydra" that allows for both interactive and non-interactive rendering backends to be developed and switched between at runtime. I can't think of a single commercial renderer that either hasn't already built a Hydra delegate, or isn't planning to.
It's just a simple text file but it supports 3D objects and materials and is supported by pretty much everything. A complete novice can write code to generate it.
Seen Autodesk here, which might - or might not - mean that the standard is also applicable for 3D engineering artifacts. However I see no explicit mention of this in the article by the link. Can this standard be well used for, say, designing a model for a 3D printer?
For professional CAD/CAM use cases? No. Those do not use meshes but more sophisticated and computationally expensive 3D modelling techniques. For hobby use? Sure. Most of that stuff uses meshes already.
Edit: it’s actually not just meshes that are supported. But the usual CAD/CAM surfaces are still not supported.
With a brief look at the example, it looks like they represent form with formulas instead of meshes, enabling fabrication from the form, for example. This is one of the reasons BIM software like Revit is so unhelpful for fabrication as they don't use formulas to represent the form so you can't get high enough accuracy.
Not sure what example you are referring to. I see meshes and some built-in geometries.
On closer inspection they do support subdivision surfaces! Just not the usual NURBs. So you could probably use this for professional modelling it just won’t be compatible with the industry standard software.
I doubt it - for 3D CAD there are STEP/IGES etc. Most of the 3D printing issues are from triangulation/voxelization of analytical surfaces rather than interchange format.
Autodesk is huge in ’visual’ pipelines that are not directly related to engineering. Maya etc.
This is very litle about manufacturing, except you can of course always convert a model to 3D mesh for visualization etc. That is quite common, and in that workflow usd is as good as any other ’mesh plus material’ format.
The output of engineering design software usually is:
1) Shop drawings for building the whole thing or sub-assembly
2) CNC machine compatible presentation
3) 3D meshes for visualization
4) conversion to some other engineering format
You can always more or less export a 3D mesh, wich can then be 3D printed. So - printing, yes. But adds nothing to any other visua format in that workflow (stl,obj,…).
I look forward to USD & USDZ being supported more consistently. The same file can look quite different even within the Apple ecosystem, as these screenshots from a few monthes ago show: https://twitter.com/mrdoob/status/1654494500230778887
The issue actually turned out to be three.js itself in that case, so the poster himself was at fault. The way it writes out materials and texture coordinates was wrong because it doesn’t use the USD API.
Different apps had different tolerances for correctness leading to that mishmash.
That’s not to say USD support can’t be improved, but that post is actually a bad example.
Apple's USDZ viewer didn't support true independent second UV channels and multiple texture transforms per material, rather it makes a bunch of assumptions that are much more restrictive than the USD format.
That is why that example is messed up I understand.
For example these caveats which screw things up tremendously:
"RealityKit supports a single UV Set in iOS 15 and macOS 12. In iOS 16 and macOS 13, it supports two."
"RealityKit supports only a single packed texture per material. You can, however, reference multiple scalar channels within a single texture."
"RealityKit supports USD texture scaling except for normal map textures."
"RealityKit supports a single UsdTransform2d per material. If a material contains multiple UsdTransform2D instances, the renderer will use the first one it finds."
Standardization is desperately needed here - Apple is out in the wilderness doing their own thing. Trying to import the USD files their software generates into other tools is a nightmare. Most people I see, my own team included, ends up writing a deserialization tool that just parses the raw data they generate because working with their wonky USD files is too much of an annoyance.
“Unity is committed to the continued adoption of USD standards. AOUSD is an important step forward to delivering a common foundation for content creation, collaboration and interoperability. We are excited to be involved in the alliance and to help shape the future of USD.” - Allan Poore, Senior Vice President, Unity Wētā Tools
"Epic Games recognizes the significance of USD in establishing standards for 3D content, virtual worlds, and the open metaverse. Pixar has demonstrated exceptional leadership in the open source community over the last decade, and we are excited to witness the formation of the Alliance for OpenUSD, which will propel the technology to new levels of standardization." - Marc Petit, VP Unreal Engine Ecosystem, Epic Games
Gltf isn’t very popular outside of web development. It’s intentionally quite limited to appeal to that demographic, but as a result isn’t as flexible as FbX or USD.
Unity and Epic are both already members, just not at the founders level. The title lists the founders, but there's several more companies at the general level just a little bit lower down the aousd.org page
Unity supports USD -- also Unity isn't technically a content creation tool (well...in the sense of what Adobe and Autodesk tools are). It is way bigger deal for the content creation tools to be aligning on an export format than consumers of said content (i.e. Unity) to align on importer.
I spent a ton of time in 2022 looking for people adopting USD for game development and came up with nada. It's popular in vfx but nobody in gaming seems to be adopting it in any way I could find. Has that changed since?
USD isn't usable as a last-mile format, so many game engines still use internal formats that facilitate fast edit-time to last-mile format conversion and compression, mainly as a point of pragmatism. There is some slow adoption of USD, but given that the main drivers of the format are from VFX, it's understandable that it will take some time for game devs to embrace USD fully.
RealityKit (iOS & visionOS AR/VR/3D library) makes use of USD. Native apps and games for the Vision Pro will also use USD, alongside their new implementation of Entity Component System (ECS).
Yes, but using .reality files is better for stuff like games in RealityKit. For example it would contain a GPU-ready texture instead of a jpeg (and a lot of other differences), so it's more in-line with how assets are typically loaded in games.
Epic has started the work to implement it into Unreal Engine and various tools have started adopting it as well. All this within the last two years or so
I remember when Jobs was introducing later version of Next he was asked about lack of OpenGL support and replied that Next will use Pixar developed scene description 'something' (already had some early shaders, maybe used by renderman?). You could say Pixar has been preparing for this for almost 40 years :)
"one of the other things that we've done with NeXTSTEP release 3.0 is we've actually built in some three dimensional graphics. We have built in Pixar's RenderMan photorealistic rendering software, which can produce the most photorealistic rendered images from 3D models. In addition to that, we've built in some real time 3D graphics, interactive RenderMan. We've taken photorealistic RenderMan and made a version that will run interactively on the screen."
OpenUSD is Steve Jobs laughing from the grave, once again he got his way.
Something I've always wondered about: All of these alliances for this and that format/standard/whatever - do they end up hiring some secretarial staff in some office for several decades?
There should be several hundreds active corporate alliances now.
As far as I know: no. It’s people like you and me from the involved companies that are largely responsible for moving things forward (most often in addition to their regular engineering work!) through Working Groups (WG) or Task Sub-Committees (TSC).
I did also happen to find small comment about the name from an interview:
> Just a little fun an anecdote, the original name ... And we were looking at the extension for the file. Technically when I do something that says layered scene description. But the extension LSD we thought it was a little too trippy, so we decided that we couldn't go in that route. So that's why the universal came, because it feels a little too far, but technically it was supposed to be a layered scene description. But anyway, we couldn't use that.
This is pretty neat to see Apple involved in a standard. They don't like to back everything that comes along. What is very interesting though, is that Meta isn't involved. Maybe because they're backing another horse, namely OpenXR [0].
It probably helped that Pixar was the developer of the technology. I'm sure Tim Cook & Apple writ large think very fondly of tech developed by a company run by it's old CEO.
USD is at a higher level of abstraction than gltf (IMO). It was created to ease things such as scene graph LOD (levels of detail) for example. It's made for very large scenes. It was created as a file format to exchange very large scenes for 3d animated movies. Inside of a USD file you can point to many other files, for example GLTF, OBJ files etc.
It seems like a great format so far, but I'm skeptical based on Adobe, Apple, Autodesk track records for "open" formats.
"Well-known file formats for interchange in the VFX industry like OBJ, FBX, and Alembic primarily deal with interchanging flat/cached geometry, with no facility for assembling assets or editing the data directly. USD does serve the role of an “interchange file format,” more comprehensively than previous public efforts, because it already interchanges not only geometry, but also shading/materials, lights, rendering, linear-blend skinning and blend-shape animation, rigid body physics, and is extensible along numerous axes."
The fact that these major players in the industry are joining forces to develop a common platform for sharing and editing 3D content is a testament to the importance of collaboration and interoperability in today's creative landscape.
Apple worked with Pixar on USZD back in 2018 (making a file format around USD). This initiative is simply making an open consortium to guide the evolution of USD.
Apple has been preparing for the VisionPro for a long time. LIDAR makes zero sense on a smartphone, but was foundational. ARKit was foundational. A lot of their scene technologies were clearly targeting a headset, and smartphones were just a temporary kickoff.
It's pretty explicit at this point, the visionOS AR app model is centered around handing off content to a centralized renderer provided by Apple, and they've settled on USD and MaterialX as the ingest formats for that renderer.
> So, can we finally say a "JPEG" or "H.264-in-MP4" for 3D content is coming?
Both of those are generally considered distribution formats, where my understanding is that USD is an authoring/interchange format. In that case, somewhat more analogous file formats might include TIFF and PSD for images. or Motion-JPEG and ProRes for video.
USD is very complex, mainly because it includes an interchange format as well as workflow features. I wonder if it would make sense to split the standard into layers to expand the target audience beyond the major production houses.
Or maybe glTF and other interchange formats already satisfy that need.
"Well-known file formats for interchange in the VFX industry like OBJ, FBX, and Alembic primarily deal with interchanging flat/cached geometry, with no facility for assembling assets or editing the data directly. USD does serve the role of an “interchange file format,” more comprehensively than previous public efforts, because it already interchanges not only geometry, but also shading/materials, lights, rendering, linear-blend skinning and blend-shape animation, rigid body physics, and is extensible along numerous axes."
Basically, glft is primarily designed for sharing individual 3D geometry, while USD is designed for sharing whole 3D scenes and is designed in a way that lots of different departments can collaborate on different parts of the same scene at the same time.
It is yet another Khronos format, by committee, instead of something Hollywood designed for their workflows.
Additionally Gltf only became a thing thanks to Microsoft changes that originated Gltf 2.0. Initially it was designed as a format specifically for WebGL.
I'll be genuinely surprised if Autodesk doesn't act like a bad actor w.r.t. an open format standard.
It doesn't fit their displayed principles/ethics/concept/mission from the past 30 years whatsoever, so i'm probably just not clever enough to see what their scheme is yet.
For entertainment, there has been MVR - My Virtual Rig - specification. The My Virtual Rig file format allows programs to share data and geometry of a scene for the entertainment industry.
I think this is the biggest mental shift to make when considering OpenUSD.
It allows splitting the data representation from the render pipeline.
On the data side, OpenUSD can support BIM just fine:
• Can store the geo representation, will render as long is there is a plugin written to render it (for systems that don't, the geo is still available to query)
• Can store additional information either on the same file, referenced in a different referenced file (ex.: In-wall pipe layouts can be referenced from the main construction file to keep it small)
• Can 'layer' additional information and resolve conflicts according to a well-defined resolution method, allowing multiple authors.
No, there is an implementation but not a formal specification.
Albeit parts of the implementation are well defined enough that they are a good basis for a specification, many behaviour specifics are only existent in code.
A specification would need to be implementation independent.
Adobe acquired Allegorithmic in 2019. Allegorithmic were the makers of Substance Designer, Substance Painter and many other 3D tools that are de facto standards for digital texturing. They’re _widely_ used in the video games, film and design industries (among others).
Disclaimer: I worked for Allegorithmic and now work for Adobe.
Adobe makes many 3D tools that are able to import and export USD files. For instance, you could import a USD scene into Substance Painter, paint some objects and export it again in a lossless manner.
As with many joint development groups, there’s ongoing membership inductions. Intel or AMD may join in the future. The initial set of companies isn’t representative of anything other than who founded it.
Stub for arguing about what "USD" means. These comments were originally at the top level but the offtopicness was choking the thread so I'm moving them here.
I'm in the field but don't actually use USD so when I heard some colleagues talking about it I googled to try to figure out what they were talking about... but was unable to find anything that wasn't talking about currency. Even if I Google something like "USD format converter"I tend to get a bunch of currency converters. it is kind of a pain in the ass.
Any old BOB or RON can use USD as part of their work. I sometimes work with Autodesk and I, personally, prefer CAD. Don't let this RUB you the wrong way. Don't get MAD. Don't call a COP. Don't declare an SOS. For those that use PHP, consider SVC or plain old PEN.
Its simply not ok -- pure consonant acronyms obfuscate and conflate meaning and dilute inter-communication. They are a relic of the pre-internet. It would be better to either eliminate usage, or move to richer abbreviation practices which include vowels (like 'SemVer' for 'Semantic Versioning')
Yes i'd like to complain. But then Apple is involved, and they don't test their devices outside a California air conditioned and dust free office anyway. Why would they test their names...
USD is the US Dollar currency everywhere. Even americans who have dabbled with forex know. Apparently though, no one in the management of 5 large american tech companies.
Will they sue every currency exchange shop in the world for using their acronym?
Edit: and how are they going to make their format popular when all search engines are just going to give them the currency converter pages?
I doubt the name's an issue cause acronyms and names are reused all the time and this is a pretty specialized area (3D content rendering).
Everyone working in 3D content rendering will know what OpenUSD is, and then whenever it gets exposed to broader audiences, we'll get small confusion from people who don't work in 3D rendering.
I am no longer into stuff like USD, and probably it is
useful and a good thing. Adobe and Autodesk etc. will have
an interchangeable structure. But I used to work for
both of those companies indirectly and ..
They want closed systems as much as possible, only
open standards etc. when forced to do so, because of
course they want all the business and all the money. So
USD probably good, but they will wield it against
competitors (are there any anymore?)
as much as possible.
If it's OK to just use acronyms that are already really just their own thing, I expect the next lot of technologies to come from these guys to be USA, USSR, NASA, NORAD, FBI, CIA, LOL, WTF, MILF and SNAFU.
I came across a saying once that proved itself apt after a brief stint working for the government:
Always spell out acronyms upon first use in any discrete communication.
The reason this is so apt in government work is because workers become so familiar with lazily throwing around acronyms that they forget what those letters represent. I've witnessed first hand a person confidently throwing around acronyms as if they knew all about it, only to find out that they knew pretty much nothing about it aside from the letters that comprise the acronym.
In the fine article above, the acronym was clarified upon first use, and so all is well:
"Alliance to foster global collaboration for Universal Scene Description (USD)"
Even just OpenSD would be a vast improvement. Presume the "open" replaces "universal" (which isn't a 1:1 mapping, but still works as a branding exercise) and you DON'T have what literally 100% of the non-graphic-artist HN commentariat thought: that they're weirdly doing a stablecoin.
Stable Diffusion isn't a familiar term outside a very niche audience. Probably over 50% of the earth's population is familiar with checking 'USD' exchange rates.
This isn't something regular people care about though.
People working in computer graphics absolutely know what stable diffusion is.
I would also that at least a third of the US adult population doesn't know that USD is the abbreviation for symbol for US dollars. The average American never travels internationally.
The tech we buy is often USD-denominated and exchange risk is something we all deal with constantly for basic purchases, in business and personal life.
Open Universal Scene Description -> ScenDes.
If you must:
Open Universal Scene Description -> OpenScenDes.
Uttering "universal" whenever something is referenced is pretentious and unwieldy. Save the pretense for the press release.
Naming is indeed hard for these people. Some products have a different problem -- where they are unusable as acronyms -- like this proto-name from Microsoft: "Azure Smart Spaces".
Pixar has been using USD for years, OpenUSD is the rebranding of it as an open format.
> Universal Scene Description (OpenUSD) is an extensible framework and ecosystem for describing, composing, simulating, and collaborating within 3D worlds. Originally developed by Pixar Animation Studios, USD, also referred to as OpenUSD, is more than a file format. It’s an open-source 3D scene description used for 3D content creation and interchange among different tools. [1]
When Toy Story 3 was almost finished in 2010, they needed to convert some assets from Toy Story 1. Ed Catmull called an urgent meeting and instructed the software team to write a USD converter. The team came back 3 weeks later and demo'd their new USD converter, which they proudly announced could handle Euros, Pesos, Rupees, and 20 other currencies. The team was immediately fired, and went on to found Paypal.
Seems to me that there is no shortage of better names available.
It's so easy to fix... why not call it, say, a "Universal Scene Description Package" (USDP) or a "3D Scene Description" (3DSD) or "Layered Universal Scene Description" (LUSD) or "Modern Scene Description Format" (MSDF) or "Universal Scene Description Format" (USDF) or "Kronos Scene Description" (KSD) or "Kronos Universal Scene Description" (KUSD) or...
