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:
Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
241–250 of 271 posts
Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
#242Earlier 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?
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
#243Earlier 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))?
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
#244Earlier 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?
Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
#245Earlier 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?
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.
Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
#246Stub 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.
Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
#247Earlier 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.
Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
#248Stub 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.
Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
#249USD 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…
Re: Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
#250I look forward to USD & USDZ being supported more consistently. The same file can look quite different even within the Apple ecosystem, as these screenshots from a few monthes ago show: https://twitter.com/mrdoob/status/1654494500230778887
The issue actually turned out to be three.js itself in that case, so the poster himself was at fault. The way it writes out materials and texture coordinates was wrong because it doesn’t use the USD API. Different apps had different tolerances for correctness leading to that mishmash. That’s not to say USD support can’t be improved, but that post is actually a bad example.
Apple's USDZ viewer didn't support true independent second UV channels and multiple texture transforms per material, rather it makes a bunch of assumptions that are much more restrictive than the USD format.
That is why that example is messed up I understand.
For example these caveats which screw things up tremendously:
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."