Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

apple.com

Post reply on HN
Print view View original

221–230 of 271 posts

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#221

Post by knolan »

MAGZine wrote: post #11

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…

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.

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#222

Post by johnnyanmac »

andyferris wrote: post #126
derefr wrote: post #119

Earlier quoted context omitted.

> 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?

> 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.

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.

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#223

Post by kevthecoder »

jms55 wrote: post #80
OmarShehata wrote: post #68

Earlier quoted context omitted.

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 b…

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.

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#224

Post by johnnyanmac »

cubefox wrote: post #147
khazhoux wrote: post #109

Earlier quoted context omitted.

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:

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.

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#225

Post by Closi »

disillusioned wrote: post #9
serhack_ wrote: post #4

Earlier quoted context omitted.

> Alliance to foster global collaboration for Universal Scene Description (USD) 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.

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#226

Post by johnnyanmac »

kettlecorn wrote: post #198
jms55 wrote: post #80

Earlier quoted context omitted.

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 b…

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

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.

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#227

Post by johnnyanmac »

pixelesque wrote: post #89
OmarShehata wrote: post #68

Earlier quoted context omitted.

What about glTF?

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 other…

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.

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#228

Post by johnnyanmac »

jsheard wrote: post #102
GeekyBear wrote: post #101

Earlier quoted context omitted.

> 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.wiki…

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…

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.

Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD

#229

Post by johnnyanmac »

pjmlp wrote: post #201
jsheard wrote: post #128

Earlier quoted context omitted.

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 directl…

> 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…

>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.

Post reply on HN