Live data from Hacker News

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

apple.com

241–250 of 271 posts

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

#241
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 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:

No post body was provided.

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

#242
post #122
post #117

Earlier quoted context omitted.

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?

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.

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

#243
post #182
post #117

Earlier quoted context omitted.

Just finished writing [0] about Blender's USD import issue. [0] - https://news.ycombinator.com/item?id=36947946

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.

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

#244
post #178
post #168

Earlier quoted context omitted.

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.

Possibly. Do you have a link to the PR handy?

I don't think a PR is ready. My solution does not fully solve the problem. It requires more thoughts. Thanks.

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

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

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

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

#246
post #20

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 am truly disappointed that these companies have not started an open-source alliance to counterfeit United States currency.

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

#247

Earlier quoted context omitted.

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

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.

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

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

#248
post #20

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.

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

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

#249
post #30

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

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.

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

#250
post #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.

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

Post reply on HN