Live data from Hacker News

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

apple.com

121–130 of 271 posts

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

#121
post #26
post #18

Earlier quoted context omitted.

Stable Diffusion isn't a familiar term outside a very niche audience. Probably over 50% of the earth's population is familiar with checking 'USD' exchange rates.

This isn't something regular people care about though. People working in computer graphics absolutely know what stable diffusion is. I would also that at least a third of the US adult population doesn't know that USD is the abbreviation for symbol for US dollars. The average American never travels internationally.

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

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

#122
post #117
post #46

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

That improvement sounds great. Any chance that’s up as a PR to blender?

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

#123
post #46

Does anybody know if the Blender project is involved / working towards this in any capacity?

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.

SideFX are a member. They’re listed on the main site under General Members.

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

#124

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.

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

#125
post #79

Earlier quoted context omitted.

What about glTF?

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

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

#126
post #119

Earlier quoted context omitted.

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.

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

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

#127

Earlier quoted context omitted.

For professional CAD/CAM use cases? No. Those do not use meshes but more sophisticated and computationally expensive 3D modelling techniques. For hobby use? Sure. Most of that stuff uses meshes already. Edit: it’s actually not just meshes that are supported. But the usual CAD/CAM surfaces are still not supported.

With a brief look at the example, it looks like they represent form with formulas instead of meshes, enabling fabrication from the form, for example. This is one of the reasons BIM software like Revit is so unhelpful for fabrication as they don't use formulas to represent the form so you can't get high enough accuracy.

Not sure what example you are referring to. I see meshes and some built-in geometries.

On closer inspection they do support subdivision surfaces! Just not the usual NURBs. So you could probably use this for professional modelling it just won’t be compatible with the industry standard software.

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

#128
post #79

Earlier quoted context omitted.

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 not a very optimal runtime format, and IIRC it even started out originally with the statement that it was 'purely for interchanging models between programs' and that engines would/should still use their own format (hence the Transfer Format in the glTF name.) Even GLB, the binary glTF format, is very sub-optimal for runtime. It even has chunks of JSON embedded in it.

glTF wouldn't be my first choice for a runtime format but it's hard to see the intent behind it as anything but a runtime format, there's a very distinct mapping from glTF concepts to OpenGL concepts. The first version didn't even have a standard material definition, the asset just had an inlined GLSL shader to render it with. They even use the same enum values so that you can plug the values in the glTF file directly into an OpenGL call if you want to.

Marrying the format so closely to OpenGL is looking pretty dated now of course, with OpenGL/WebGL dead and buried by Vulkan/WebGPU. You can render glTF with Vulkan/WebGPU but the flexibility of the format and the newer APIs rigid pipeline layouts are at odds with each other - ideally you want the data to follow a consistent, rigid layout.

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

#129
post #90

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

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

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

#130
post #36

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?

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.

Post reply on HN