Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD(apple.com)
apple.com
Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
https://www.apple.com/newsroom/2023/08/pixar-adobe-apple-autodesk-and-nvidia-form-alliance-for-openusd/
270 comments
All: if you want to argue about what "USD" means, please do that at https://news.ycombinator.com/item?id=36962507, not here. But also consider: "Please don't complain about tangential annoyances—e.g. [...] name collisions [...]. They're too common to be interesting." - https://news.ycombinator.com/newsguidelines.html
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.
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.
> Rendering things on mobile is hard
I don't know. You can stream Unity to mobile with the service I've authored (https://appmana.com/watch/theheretic for an example).
I don't know. You can stream Unity to mobile with the service I've authored (https://appmana.com/watch/theheretic for an example).
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.
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.
You might like this one more - https://appmana.com/watch/virtualtestdrive - because it's just better :)
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.
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.
[deleted]
I’m not sure what the issue is, that whole scene was rendering in what I would consider seconds per frame rather than frames per second.
I have an iPhone 13 Pro and a decent internet connection and if I came across that I would bounce out immediately.
I have an iPhone 13 Pro and a decent internet connection and if I came across that I would bounce out immediately.
It's called "virtual test drive" but is it really just a turntable of a car?
I tried a bunch of keyboard commands and nothing happened. Can I test drive the car?
I tried a bunch of keyboard commands and nothing happened. Can I test drive the car?
Couldn't bother waiting for this to load unfortunately
Cool, who is going to pay for it? This isn't rendering things on mobile.
Yikes the performance is terrible. You are not proving the point that you think you are
> with the service I've authored
You created Appmana?
You created Appmana?
> Cooking is hard.
> Just order out bro.
> Just order out bro.
streaming != rendering
Can I open an OpenUSD file in a text editor and read it?
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.
Here is an example file for the curious: https://github.com/PixarAnimationStudios/OpenUSD/blob/releas...
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.
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.
> proper round-tripping of float values
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?
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?
> human-editable
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.
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.
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.
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.
I did say slightly snide.
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.
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.
Some do (i.e. Nuke compositor .nk files in the VFX industry, which stores some float values as hex)...
but then you loose the human readability / "understand-ability at a glance" advantage, so it sort of depends what the use-case is...
but then you loose the human readability / "understand-ability at a glance" advantage, so it sort of depends what the use-case is...
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.
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.
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.)
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.)
I love that a Nuke file can (usually) be passed around using no more than copy/pasted text.
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.
[1] https://www.smbc-comics.com/comic/2013-06-05
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.
[1] https://www.smbc-comics.com/comic/2013-06-05
Is the plain text diff-able? Easy to resolve merge conflicts? I consider xml(collada?) not to be diff friendly.
Yeah, sounds kind of like the old Renderman RIB files. Does Renderman still use RIB files?
I've been so out of the loop it's insane. I learned not long ago they no longer use the original Renderman Shading Language.
I've been so out of the loop it's insane. I learned not long ago they no longer use the original Renderman Shading Language.
[deleted]
Yes, absolutely.
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.
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.
Does anyone remember X3D[1] / VRML? X3D is roughly the same concept, 20-some years ago.
Here's a hello world for X3D: https://www.web3d.org/x3d/content/examples/Basic/X3dSpecific...
And here's a hello world for OpenUSD: https://www.openusd.org/release/tut_helloworld.html#viewing-...
Although X3D is a bit more verbose, a lot of parallels can be drawn between the two, 20 years apart.
[1] https://en.wikipedia.org/wiki/X3D
Here's a hello world for X3D: https://www.web3d.org/x3d/content/examples/Basic/X3dSpecific...
And here's a hello world for OpenUSD: https://www.openusd.org/release/tut_helloworld.html#viewing-...
Although X3D is a bit more verbose, a lot of parallels can be drawn between the two, 20 years apart.
[1] https://en.wikipedia.org/wiki/X3D
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.
1. https://create3000.github.io/x_ite/
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.
1. https://create3000.github.io/x_ite/
I was tinkering in that space in the mid-90s, and always felt the file format was a missed opportunity, and wasn't taking any of the lessons of HTML.
What I wanted (but never built) was a semantic file format, something like:
What I wanted (but never built) was a semantic file format, something like:
<room style="square" id="room1">
<wall direction=north>
<picture frame="modern" src="http://foo.com/fancycat.jpg" />
</wall>
<wall direction=south>
<door room="room2" />
</wall>
</room>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.
You can actually render a gltf as a JSX tree too with gltfjsx: https://github.com/pmndrs/gltfjsx
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.
You can actually render a gltf as a JSX tree too with gltfjsx: https://github.com/pmndrs/gltfjsx
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
https://www.researchgate.net/figure/A-Reachin-Display-equipp...
The company H3D has built something similar.
https://h3d.org/
It also used the PHANToM for haptic feedback and used a 3D stereoscopic display
https://www.researchgate.net/figure/A-Reachin-Display-equipp...
The company H3D has built something similar.
https://h3d.org/
That's way too high level and ambiguous. Something could look okay in one browser and totally crap in another.
>look okay in one browser and totally crap in another.
We're talking about 3d model formats where the current industry standard is a close sourced Autodesk nightmare. This is already the default situaton.
There's not much incentive to change either because animation and game studios tend to roll their own tech.
We're talking about 3d model formats where the current industry standard is a close sourced Autodesk nightmare. This is already the default situaton.
There's not much incentive to change either because animation and game studios tend to roll their own tech.
<surface orientation=x name="south wall" rotation=-125 .../>
I remember VRML. Unfortunately KiCAD still uses it for 3D models (though thankfully it supports STEP files too)
> X3D is roughly the same concept, 20-some years ago
That was my initial thought also.
> Although X3D is a bit more verbose
The USDA file format reminds me a lot of the pre-XML VRML 97 file format, with the curly bracket C-style syntax, #comments, and 'def' everywhere.
https://openusd.org/release/spec_usdpreviewsurface.html#usd-...
That was my initial thought also.
> Although X3D is a bit more verbose
The USDA file format reminds me a lot of the pre-XML VRML 97 file format, with the curly bracket C-style syntax, #comments, and 'def' everywhere.
https://openusd.org/release/spec_usdpreviewsurface.html#usd-...
We had to wait 20 years until some entity interested in interoperability became powerful enough that vendors started listening to them.
Not all surprising that X3D uses xml and of course OpenUSD uses some form of python/json thing
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.
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").
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.
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.
This was my immediate thought. I reckon this will be one of the early steps in getting to automated movies.
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).
Ah, I see SideFX are there as a "General Member"! Cool!
pretty cool indeed
long live sidefx
long live sidefx
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.
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.
Does anybody know if the Blender project is involved / working towards this in any capacity?
Just finished writing [0] about Blender's USD import issue.
[0] - https://news.ycombinator.com/item?id=36947946
[0] - https://news.ycombinator.com/item?id=36947946
That improvement sounds great. Any chance that’s up as a PR to blender?
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.
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.
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.
This was a great read, thanks for sharing.
Wow, thanks!
Blender has USD support, but I think it would be difficult for them to contribute to OpenUSD directly. They're more of an "downstream user".
It's similar to SideFX and Houdini, which is an extremely common way to author USD scenes. SideFX isn't a member either, just a downstream user.
It's similar to SideFX and Houdini, which is an extremely common way to author USD scenes. SideFX isn't a member either, just a downstream user.
SideFX are a member. They’re listed on the main site under General Members.
Should have looked first. Blender should buy in at that level too.
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.
They support USDZ (Blender includes support for USD export.[6] Import support from version 3.0. )
[deleted]
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.
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.
Even Autodesk is backing USD so presumably even they have given up on the long term prospects of FBX.
What about glTF?
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.
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.
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.
Colada was really under specified and support was super fractured. It never really gained traction as a result outside of very specific pipelines
This is the dark secret to USD: pretty much everyone is relying on the same massive C++ project!
Projects that want leaner dependencies, like everything on the web, don’t yet have a good way to work with USD.
Projects that want leaner dependencies, like everything on the web, don’t yet have a good way to work with USD.
>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.
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.
By lean I mean the OpenUSD Wasm binary is over 10mb, last I checked.
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).
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.
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.
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...
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...
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.
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.
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.
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.
Interesting. Thanks!
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.
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.
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.
> OpenGL/WebGL dead and buried by Vulkan/WebGPU.
If only.
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.
If only.
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).
>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.
> 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.
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.
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.
Pretty much a next-gen RIB. FBX itself was always weird child ever since Kaydara days (untill bought by Autodesk).
IMO the equivalent to Midi files in the 3D world is OBJ files.
https://en.wikipedia.org/wiki/Wavefront_.obj_file
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.
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.
[deleted]
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.
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.
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 suspect, but have no evidence, that it's the Maya side of AutoDesk
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,…).
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 don't think it's gonna help with the design side of things but USD does include a volume primitive type in its 'UsdVol' section:
https://openusd.org/release/api/usd_vol_page_front.html
So it sounds like it could be possible to use USD to convey data to a 3D printer eventually once the printers have loaders for the new format.
https://openusd.org/release/api/usd_vol_page_front.html
So it sounds like it could be possible to use USD to convey data to a 3D printer eventually once the printers have loaders for the new format.
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.
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.
Are you sure?
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:
https://developer.apple.com/documentation/realitykit/validat...
"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."
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:
https://developer.apple.com/documentation/realitykit/validat...
"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."
I can't tell you how much I'm looking forward to seeing assets distributed in USDZ format. Specifically: nuts.
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 and Epic seem like two glaringly omissions from this.
From the AOUSD website: https://www.linuxfoundation.org/press/aousd-quotes
“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
“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
Unreal already supports USD: https://docs.unrealengine.com/5.0/en-US/universal-scene-desc...
USD has the most traction in the offline rendering world, but it's creeping into gamedev workflows too as a replacement for FBX.
USD has the most traction in the offline rendering world, but it's creeping into gamedev workflows too as a replacement for FBX.
I thought gltf or something was gaining traction to be the replacement for fbx in gamedev?
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.
As well as the Blender Foundation.
Game engines usually have their own runtime formats and just have an importer
It's fairly easy to load gltf at runtime in UE 4/5.
USD is supported in Unreal engine. I'm using it in some projects, mostly for reinforcement learning scenario building sort of things.
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?
It's early days for USD in gamedev, but Remedy is using it: https://www.youtube.com/watch?v=FI2pyzTOvaQ
Interesting find, thanks!
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.
Generally it never makes sense to use interchange formats for a runtime use.
Take the predominant game development format: FBX. It’s used strictly for interchange not runtime.
The use of USD is exactly the same. You’d compile it into a runtime friendly format that benefits your specific runtime.
Take the predominant game development format: FBX. It’s used strictly for interchange not runtime.
The use of USD is exactly the same. You’d compile it into a runtime friendly format that benefits your specific runtime.
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
USD and FBX/glTF serve very different purposes and can't replace each other.
What would you use USD for in gamedev?
I thought this was going to be some sort of US Dollar-based stable coin. Interesting naming.
Pixar started work on the Universal Scene Descriptor format in 2012. [0]
Larimer theorized bitUSD in 2013. [1]
[0] https://openusd.org/release/intro.html#heritage-of-usd-at-pi...
[1] https://www.steem.center/index.php?title=BitShares:Proposal_...
Larimer theorized bitUSD in 2013. [1]
[0] https://openusd.org/release/intro.html#heritage-of-usd-at-pi...
[1] https://www.steem.center/index.php?title=BitShares:Proposal_...
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 :)
there it is https://allaboutstevejobs.com/videos/misc/nextstep_3_demo_19...
"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.
there it is https://allaboutstevejobs.com/videos/misc/nextstep_3_demo_19...
"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.
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).
Of course, but who's doing the actual admin work?
Who chases the sponsors for cash, who books the events, who collects the member fees, who creates that crappy member web site?
I'm just curious :)
Who chases the sponsors for cash, who books the events, who collects the member fees, who creates that crappy member web site?
I'm just curious :)
It’s people who work for the Linux Foundation. Basically they offer this kind of organization standup as a service.
[deleted]
Doesn't the Linux Foundation take care of all that?
For people complaining about the name, USD has been already a thing publicly since at least 2013, and internally probably fair bit before that: https://www.cgchannel.com/2013/10/pixars-usd-system-the-new-...
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.
https://cesium.com/open-metaverse-podcast/the-genesis-of-usd...
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.
https://cesium.com/open-metaverse-podcast/the-genesis-of-usd...
Why have they created yet another alliance, isn't Khronos group which standardizes similar things(APIs, 3d model standards such as GlTF etc) enough?
Apple is currently in litigation with Khronos https://news.ycombinator.com/item?id=22538214
Seems indeed to compete with
https://www.khronos.org/openxr/
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].
[0] https://www.khronos.org/openxr/
[0] https://www.khronos.org/openxr/
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.
[deleted]
Can someone ELI5 how this is different from glTF?
What information does the OpenUSD format carry?
What information does the OpenUSD format carry?
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.
It seems like a great format so far, but I'm skeptical based on Adobe, Apple, Autodesk track records for "open" formats.
Quoting from the USD homepage:
"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."
"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."
Odd to see Nvidia and Apple working together on anything
I'm more wondering where AMD is in this. "Open" isn't very open without all the major GPU players involved.
AMD isn't directly involved with the alliance, but they have embraced USD:
https://www.amd.com/en/technologies/radeon-prorender ("A Pixar® USD™ Hydra™ render delegate...")
https://gpuopen.com/learn/amd-usd-hydra-blender
https://www.amd.com/en/technologies/radeon-prorender ("A Pixar® USD™ Hydra™ render delegate...")
https://gpuopen.com/learn/amd-usd-hydra-blender
Good to know, thanks! Would be nice to see them join the standard too.
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.
How is this different from Collada from Kronos group?
https://en.wikipedia.org/wiki/COLLADA
They already made a universal scene description standard.
They already made a universal scene description standard.
From the Collada wiki page:
Initial release October 2004; 18 years ago
Latest release 1.5.0 August 2008; 14 years ago
USD has more layering and referencing capabilities
USD has more layering and referencing capabilities
Reading between the lines, is Apple making moves in preparation for VisionPro?
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.
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.
Apple wants to own spatial computing. They've been building LIDAR into their phones for some time.
Only some of them.
So, can we finally say a "JPEG" or "H.264-in-MP4" for 3D content is coming?
(I mean as a universally accepted format that just works everywhere, not literally a JPEG on H.264 inside a scene)
(I mean as a universally accepted format that just works everywhere, not literally a JPEG on H.264 inside a scene)
> 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.
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.
Oddly enough, MP4 already includes a 3D content specification: MPEG-4 Part 11:
https://en.wikipedia.org/wiki/MPEG-4_Part_11
https://en.wikipedia.org/wiki/MPEG-4_Part_11
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.
Or maybe glTF and other interchange formats already satisfy that need.
My only question, why aren't they using gltf? What is the issue with gltf? It supports most of the things?
Quoting from the the USD homepage:
"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.
"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.
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.
OpenUSD solves a very different problem than gltf.
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.
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.
[deleted]
How does USD compare to Collada?
[deleted]
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.
Official repo: [1]
Current Spec: [2]
WIP for DIN Spec release: [3]
[1] https://github.com/mvrdevelopment/spec/
[2] https://github.com/mvrdevelopment/spec/blob/main/mvr-spec.md
[3] https://github.com/mvrdevelopment/spec/pull/153
Official repo: [1]
Current Spec: [2]
WIP for DIN Spec release: [3]
[1] https://github.com/mvrdevelopment/spec/
[2] https://github.com/mvrdevelopment/spec/blob/main/mvr-spec.md
[3] https://github.com/mvrdevelopment/spec/pull/153
Maybe it's a revolution, but I don't understand how one format can be all things to all types of users.
BIM requirements are very different to 3D graphics and animation requirements.
BIM requirements are very different to 3D graphics and animation requirements.
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.
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.
The alliance will develop written specifications detailing the features of OpenUSD
Since its an existing standard hasn't this already been done, at least to a decent extent?
Since its an existing standard hasn't this already been done, at least to a decent extent?
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.
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.
Anyone remembers VRML?
[deleted]
What a list of anti-consumer companies. Natural allies. What are the odds that its Open, like OpenAI is open?
Standards are good, but I am a little weary about this. Is this another embrace, extend, extinguish moment?
[deleted]
Currency hijack aside, will this be usable without paying royalties? Adobe and Autodesk are involved...
[deleted]
Didn't Meta and a few others propose something similar a few months ago?
How does USD compare to gltf?
Surprised to see Adobe here. Maybe they're working on some new 3D tools?
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.
Disclaimer: I worked for Allegorithmic and now work for Adobe.
The have Aero and Substance 3D Apps https://www.adobe.com/products/aero.html
https://www.adobe.com/creativecloud/3d-ar.html
https://www.adobe.com/creativecloud/3d-ar.html
Adobe owns Substance, a material painting tool for 3d character and other assets, often used in game and movie industry
But how is a texture/material generator related to a scene description standard?
Users will want to load USD scenes/models into Adobe products.
Also, USD supports USDShade and MaterialX material (shader network) definitions, and I imagine there will be full round-tripping support for that?
Also, USD supports USDShade and MaterialX material (shader network) definitions, and I imagine there will be full round-tripping support for that?
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.
I assumed this was some sort of stablecoin and was thoroughly confused.
wait, Apple and Nvidia in the same room together?!
timely
No Intel and AMD?
No thanks.
This is just a power play by all the companies most well known for lock-in and monopoly-like behavior.
This is not a good thing.
No thanks.
This is just a power play by all the companies most well known for lock-in and monopoly-like behavior.
This is not a good thing.
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 left https://news.ycombinator.com/item?id=36962294 out because it has actual interesting information about the project.
I left https://news.ycombinator.com/item?id=36962294 out because it has actual interesting information about the project.
> For people complaining about the name, USD has been already a thing publicly since at least 2013
As opposed to the United States dollar that became public after 2013?
I mean, seriously: OpenUSD sounds like a cryptocurrency "stablecoin" token name.
As opposed to the United States dollar that became public after 2013?
I mean, seriously: OpenUSD sounds like a cryptocurrency "stablecoin" token name.
Literally no one who uses USD as part of their work gets tripped up by this.
It’s ok for jargon and acronyms to be confusing to people who are not at all in the field.
It’s ok for jargon and acronyms to be confusing to people who are not at all in the field.
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.
Python’s fork can be used to create children. Don’t forget to kill them when you’re done otherwise their memory can leak when they become zombies.
Trust me, it’s about programming. Not snake horror dystopias.
Trust me, it’s about programming. Not snake horror dystopias.
I'll reply to your comment, but first I need to look into this dump I just took.
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.
https://www.xe.com/iso4217.php
https://www.xe.com/iso4217.php
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')
> It’s ok for jargon and acronyms to be confusing to people who are not at all in the field.
On the site itself, sure. Here, where not everyone "uses USD as part of their work", spelling it out in the title would have avoided this whole stub
On the site itself, sure. Here, where not everyone "uses USD as part of their work", spelling it out in the title would have avoided this whole stub
I use USD as part of my work... in fintec, so this confuses the heck out of my brain
[deleted]
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?
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 am so glad that they picked an acronym so obvious so as to not confuse anyone.
Can someone clarify what the conversion ratio between OpenUSD and OpenEUR will be though?
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.
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.
IMNSHO. Sorry where it offends.
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.
IMNSHO. Sorry where it offends.
dang: This seems to have accidentally landed in the naming stub?
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)"
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)"
> Alliance to foster global collaboration for Universal Scene Description (USD)
UNISD? UNIversal Scene Description
At least better than Universal Scene Specific (USS)
UNISD? UNIversal Scene Description
At least better than Universal Scene Specific (USS)
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.
Or better yet - 'Open Scene Description'. For the extra two syllables they can say what it is.
Then it sounds like AI.
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.
As an outsider, OpenSD sounds more like a disk format than anything to do with AI.
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.
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.
> at least a third of the US adult population doesn't know that USD is the abbreviation for symbol for US dollars
If we're just gonna make up statistics...
If we're just gonna make up statistics...
Maybe regular americans. Africans, Europeans, Asians, Pacific peoples and Antipodeans however...
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.
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".
My dyslexic arse thought this read OpenBSD for a brief second.
I am truly disappointed that these companies have not started an open-source alliance to counterfeit United States currency.
Why is the JDF (Japanese Defense Force) backing a new crypto coin (OpenUSD) with Apple, Pixar, Nvidia and Adobe?
OpenUSD is an atrocious name, thought big tech was getting together to make a crypto
USD: I thought this was instant payments initiative similar to Brazil's OpenPix...
OpenUSD sounds like something bitcoin-related. The USD acronym is so known for being for US Dollars, why would they want to overload it...
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]
[1] https://developer.nvidia.com/usd
> 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]
[1] https://developer.nvidia.com/usd
I also thought this was crypto related and felt it was odd Adobe, Pixar, and Autodesk were involved.
Yeah at first I thought it was some kind of store payment crypto they were introducing.
As someone in and out of the USD ecosystem for years (starting around 2014 or so), this comment is especially hilaruous.
Maybe this is the new anti-crypto meta - we proactively take away the best acronyms that the crypto community would want to use.
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.
for a second I've thought they are creating a new crypto
stable coin oO
what a terrible name, I thought this was some kind of USD stablecoin
is this about stablecoin ?
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...
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...
How is this different from glTF? Are we getting another XKCD #927?
name collisions "They're too common to be interesting"
bullshit
bullshit
Is this like HTML for 3D scenes?
Sidenote- OpenUSD sounds like a crypto currency.
Sidenote- OpenUSD sounds like a crypto currency.
Sidenote- OpenUSD sounds like a crypto currency.
This is exactly what I thought at first too. But then realized it's August 1st and not April..
This is exactly what I thought at first too. But then realized it's August 1st and not April..
No, because HTML is semantic (rendering is open to interpretation) whereas USD is explicit.
But in terms of "common format which different systems can read", then yes, sure.
But in terms of "common format which different systems can read", then yes, sure.