[HN Gopher] Pixar, Adobe, Apple, Autodesk, and Nvidia form allia...
___________________________________________________________________
Pixar, Adobe, Apple, Autodesk, and Nvidia form alliance for OpenUSD
Author : anaclet0
Score : 645 points
Date : 2023-08-01 18:51 UTC (1 days ago)
(HTM) web link (www.apple.com)
(TXT) w3m dump (www.apple.com)
| th0ughtcr1me wrote:
| timely
| pitaj wrote:
| Odd to see Nvidia and Apple working together on anything
| pier25 wrote:
| Both are also members of the Kronos group.
| [deleted]
| latchkey wrote:
| I'm more wondering where AMD is in this. "Open" isn't very open
| without all the major GPU players involved.
| jsheard wrote:
| AMD isn't directly involved with the alliance, but they have
| embraced USD:
|
| https://www.amd.com/en/technologies/radeon-prorender _( "A
| Pixar(r) USD(tm) Hydra(tm) render delegate...")_
|
| https://gpuopen.com/learn/amd-usd-hydra-blender
| latchkey wrote:
| Good to know, thanks! Would be nice to see them join the
| standard too.
| danwills wrote:
| 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).
| danwills wrote:
| Ah, I see SideFX are there as a "General Member"! Cool!
| agumonkey wrote:
| pretty cool indeed
|
| long live sidefx
| danwills wrote:
| 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.
| lvncelot wrote:
| 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.
| hiidrew wrote:
| Unity and Epic seem like two glaringly omissions from this.
| colinthompson wrote:
| 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 Weta 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
| jsheard wrote:
| 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.
| namrog84 wrote:
| I thought gltf or something was gaining traction to be the
| replacement for fbx in gamedev?
| raincole wrote:
| In _open source_ gamedev yes. Otherwise barely.
| dagmx wrote:
| Gltf isn't very popular outside of web development. It's
| intentionally quite limited to appeal to that demographic,
| but as a result isn't as flexible as FbX or USD.
| treyd wrote:
| As well as the Blender Foundation.
| fgeahfeaha wrote:
| Game engines usually have their own runtime formats and just
| have an importer
| zirgs wrote:
| It's fairly easy to load gltf at runtime in UE 4/5.
| dagmx wrote:
| 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
| kriro wrote:
| USD is supported in Unreal engine. I'm using it in some
| projects, mostly for reinforcement learning scenario building
| sort of things.
| 9erdelta wrote:
| 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.
| kaveh808 wrote:
| 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.
| cubefox wrote:
| Didn't Meta and a few others propose something similar a few
| months ago?
| coldtea wrote:
| Does anybody know if the Blender project is involved / working
| towards this in any capacity?
| erichocean wrote:
| 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.
| dagmx wrote:
| SideFX are a member. They're listed on the main site under
| General Members.
| erichocean wrote:
| Should have looked first. Blender should buy in at that
| level too.
| [deleted]
| zitterbewegung wrote:
| They support USDZ (Blender includes support for USD export.[6]
| Import support from version 3.0. )
| dagmx wrote:
| 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.
| bssrdf wrote:
| Just finished writing [0] about Blender's USD import issue.
|
| [0] - https://news.ycombinator.com/item?id=36947946
| panzi wrote:
| 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))?
| bssrdf wrote:
| 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.
| coldtea wrote:
| Wow, thanks!
| dagmx wrote:
| That improvement sounds great. Any chance that's up as a PR
| to blender?
| bssrdf wrote:
| 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.
| dagmx wrote:
| Possibly. Do you have a link to the PR handy?
| bssrdf wrote:
| I don't think a PR is ready. My solution does not fully
| solve the problem. It requires more thoughts. Thanks.
| datavirtue wrote:
| 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.
| Vt71fcAqt7 wrote:
| This was a great read, thanks for sharing.
| pnw wrote:
| 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?
| ninepoints wrote:
| 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.
| asutekku wrote:
| 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
| joeyrideout wrote:
| 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).
| ladberg wrote:
| 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.
| dagmx wrote:
| 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.
| edflsafoiewq wrote:
| What would you use USD for in gamedev?
| jsheard wrote:
| It's early days for USD in gamedev, but Remedy is using it:
| https://www.youtube.com/watch?v=FI2pyzTOvaQ
| pnw wrote:
| Interesting find, thanks!
| raincole wrote:
| USD and FBX/glTF serve very different purposes and can't
| replace each other.
| nottorp wrote:
| Currency hijack aside, will this be usable without paying
| royalties? Adobe and Autodesk are involved...
| ruuda wrote:
| How does USD compare to Collada?
| Oarch wrote:
| 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.
| omershapira wrote:
| 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.
| gjvc wrote:
| name collisions "They're too common to be interesting"
|
| bullshit
| serf wrote:
| 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.
| pier25 wrote:
| Surprised to see Adobe here. Maybe they're working on some new 3D
| tools?
| rallyforthesun wrote:
| Adobe owns Substance, a material painting tool for 3d character
| and other assets, often used in game and movie industry
| pier25 wrote:
| But how is a texture/material generator related to a scene
| description standard?
| pixelesque wrote:
| 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?
| franzb wrote:
| 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.
| franzb wrote:
| 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.
| sammorrowdrums wrote:
| The have Aero and Substance 3D Apps
| https://www.adobe.com/products/aero.html
|
| https://www.adobe.com/creativecloud/3d-ar.html
| elif wrote:
| 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.
| rallyforthesun wrote:
| 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.
| flohofwoe wrote:
| > 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").
| rcarr wrote:
| This was my immediate thought. I reckon this will be one of the
| early steps in getting to automated movies.
| ferrumfist wrote:
| 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.
| zgluck wrote:
| 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.
| franzb wrote:
| 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).
| zgluck wrote:
| 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 :)
| dagmx wrote:
| It's people who work for the Linux Foundation. Basically
| they offer this kind of organization standup as a service.
| [deleted]
| CodeCompost wrote:
| Doesn't the Linux Foundation take care of all that?
| LASR wrote:
| Reading between the lines, is Apple making moves in preparation
| for VisionPro?
| echelon wrote:
| Apple wants to own spatial computing. They've been building
| LIDAR into their phones for some time.
| stalfosknight wrote:
| Only some of them.
| jsheard wrote:
| 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.
| llm_nerd wrote:
| 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.
| [deleted]
| pbreit wrote:
| I thought this was going to be some sort of US Dollar-based
| stable coin. Interesting naming.
| itishappy wrote:
| 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_...
| knapcio wrote:
| I find that my confusion primarily arises from the
| utilization of "USD", an abbreviation denoting the United
| States Dollar which exists since 1792 :)
| rasz wrote:
| 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/nextste
| p_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.
| diogenescynic wrote:
| I assumed this was some sort of stablecoin and was thoroughly
| confused.
| [deleted]
| schoubey wrote:
| Why have they created yet another alliance, isn't Khronos group
| which standardizes similar things(APIs, 3d model standards such
| as GlTF etc) enough?
| cubefox wrote:
| Seems indeed to compete with https://www.khronos.org/openxr/
| thrillgore wrote:
| Apple is currently in litigation with Khronos
| https://news.ycombinator.com/item?id=22538214
| rkagerer wrote:
| _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?
| dagmx wrote:
| 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.
| hospitalJail wrote:
| What a list of anti-consumer companies. Natural allies. What are
| the odds that its Open, like OpenAI is open?
| [deleted]
| TheMagicHorsey wrote:
| How is this different from Collada from Kronos group?
| https://en.wikipedia.org/wiki/COLLADA
|
| They already made a universal scene description standard.
| lattalayta wrote:
| 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
| [deleted]
| caycep wrote:
| wait, Apple and Nvidia in the same room together?!
| CSMastermind wrote:
| 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.
| PoignardAzur wrote:
| Can someone ELI5 how this is different from glTF?
|
| What information does the OpenUSD format carry?
| beiller wrote:
| 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.
| dagw wrote:
| 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."
| avmich wrote:
| 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?
| jahewson wrote:
| 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.
| gibsonf1 wrote:
| 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.
| jahewson wrote:
| 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.
| danwills wrote:
| 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.
| cobbal wrote:
| I suspect, but have no evidence, that it's the Maya side of
| AutoDesk
| LightFog wrote:
| I doubt it - for 3D CAD there are STEP/IGES etc. Most of the
| 3D printing issues are from triangulation/voxelization of
| analytical surfaces rather than interchange format.
| bsimpson wrote:
| When Pixar launched USD, the release included a Maya plugin.
| That's a totally reasonable assumption.
| fsloth wrote:
| 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,...).
| epolanski wrote:
| 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.
| jsheard wrote:
| 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.
| OmarShehata wrote:
| What about glTF?
| jms55 wrote:
| 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.
| kettlecorn wrote:
| 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.
| johnnyanmac wrote:
| >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.
| kettlecorn wrote:
| By lean I mean the OpenUSD Wasm binary is over 10mb, last
| I checked.
| kevthecoder wrote:
| 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.
| vvanders wrote:
| 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.
| dagmx wrote:
| Colada was really under specified and support was super
| fractured. It never really gained traction as a result
| outside of very specific pipelines
| pixelesque wrote:
| 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).
| johnnyanmac wrote:
| 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.
| jsheard wrote:
| 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.
| GeekyBear wrote:
| > 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...
| jsheard wrote:
| 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.
| johnnyanmac wrote:
| 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.
| GeekyBear wrote:
| Interesting. Thanks!
| slimsag wrote:
| 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.
| jsheard wrote:
| 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.
| pjmlp wrote:
| > 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.
| johnnyanmac wrote:
| >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.
| pjmlp wrote:
| > 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.
| johnnyanmac wrote:
| >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.
| [deleted]
| erichocean wrote:
| > _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.
| Keyframe wrote:
| Pretty much a next-gen RIB. FBX itself was always weird child
| ever since Kaydara days (untill bought by Autodesk).
| mrguyorama wrote:
| 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.
| TigerTeamX wrote:
| Standards are good, but I am a little weary about this. Is this
| another embrace, extend, extinguish moment?
| [deleted]
| 2OEH8eoCRo0 wrote:
| Is this like HTML for 3D scenes?
|
| Sidenote- OpenUSD sounds like a crypto currency.
| khazhoux wrote:
| 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.
| petercooper wrote:
| _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..
| zengid wrote:
| 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/
| [deleted]
| HPMOR wrote:
| 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.
| andrewstuart wrote:
| 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.
| pjmlp wrote:
| As if Intel and AMD don't have lock-in and monopoly-like
| behavior of their own.
| dagmx wrote:
| As with many joint development groups, there's ongoing
| membership inductions. Intel or AMD may join in the future. The
| initial set of companies isn't representative of anything other
| than who founded it.
| MAGZine wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| Can I open an OpenUSD file in a text editor and read it?
| pixelesque wrote:
| 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.
| derefr wrote:
| > 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?
| mananaysiempre wrote:
| 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
| andyferris wrote:
| > 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.
| johnnyanmac wrote:
| 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.
| pixelesque wrote:
| 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...
| Daub wrote:
| I love that a Nuke file can (usually) be passed around
| using no more than copy/pasted text.
| derefr wrote:
| 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.
| pixelesque wrote:
| 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.
| tsuru wrote:
| Is the plain text diff-able? Easy to resolve merge
| conflicts? I consider xml(collada?) not to be diff
| friendly.
| franzb wrote:
| Yes, absolutely.
| [deleted]
| GoofballJones wrote:
| 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.
| omershapira wrote:
| 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.
| wilg wrote:
| Here is an example file for the curious: https://github.com
| /PixarAnimationStudios/OpenUSD/blob/releas...
| knolan wrote:
| 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.
| doctorpangloss wrote:
| > 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).
| weird-eye-issue wrote:
| Yikes the performance is terrible. You are not proving the
| point that you think you are
| froggit wrote:
| streaming != rendering
| esperent wrote:
| 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.
| doctorpangloss wrote:
| 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.
| weird-eye-issue wrote:
| Couldn't bother waiting for this to load unfortunately
| [deleted]
| sbarre wrote:
| 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?
| Osiris wrote:
| Worked for me. I clicked drive and then drove around.
| charrondev wrote:
| 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.
| andsoitis wrote:
| > with the service I've authored
|
| You created Appmana?
| andersa wrote:
| Cool, who is going to pay for it? This isn't rendering things
| on mobile.
| gdtfmaster wrote:
| 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
| dang wrote:
| 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.
| nottorp wrote:
| 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?
| TacticalCoder wrote:
| > 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.
| [deleted]
| khazhoux wrote:
| 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.
| Phrodo_00 wrote:
| I use USD as part of my work... in fintec, so this confuses
| the heck out of my brain
| KMnO4 wrote:
| 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._
| khazhoux wrote:
| I'll reply to your comment, but first I need to look into
| this dump I just took.
| alanpearce wrote:
| > 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
| uglycoyote wrote:
| 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.
| whycome wrote:
| 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
| waffletower wrote:
| 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')
| serhack_ wrote:
| > Alliance to foster global collaboration for Universal Scene
| Description (USD)
|
| UNISD? UNIversal Scene Description
|
| At least better than Universal Scene Specific (USS)
| disillusioned wrote:
| 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.
| Closi wrote:
| Or better yet - 'Open Scene Description'. For the extra two
| syllables they can say what it is.
| TylerE wrote:
| Then it sounds like AI.
| depereo wrote:
| 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.
| TylerE wrote:
| 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.
| NavinF wrote:
| > 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...
| depereo wrote:
| 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.
| bsimpson wrote:
| As an outsider, OpenSD sounds more like a disk format
| than anything to do with AI.
| Racing0461 wrote:
| Sounds like a crypto coin at first.
| tukajo wrote:
| Wait, it's not?
| johnalbertearle wrote:
| 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.
| savolai wrote:
| dang: This seems to have accidentally landed in the naming
| stub?
| khazhoux wrote:
| 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.
| gjsman-1000 wrote:
| 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...
| throwaway104782 wrote:
| what a terrible name, I thought this was some kind of USD
| stablecoin
| jrflowers wrote:
| I am so glad that they picked an acronym so obvious so as to
| not confuse anyone.
| moffkalast wrote:
| Can someone clarify what the conversion ratio between OpenUSD
| and OpenEUR will be though?
| codyb wrote:
| 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.
| xbiitx wrote:
| is this about stablecoin ?
| waffletower wrote:
| I am truly disappointed that these companies have not started
| an open-source alliance to counterfeit United States currency.
| waffletower wrote:
| 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".
| nektro wrote:
| OpenUSD is an atrocious name, thought big tech was getting
| together to make a crypto
| rafaelturk wrote:
| USD: I thought this was instant payments initiative similar to
| Brazil's OpenPix...
| sanitycheck wrote:
| 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.
| emmjay_ wrote:
| My dyslexic arse thought this read OpenBSD for a brief second.
| dyingkneepad wrote:
| OpenUSD sounds like something bitcoin-related. The USD acronym
| is so known for being for US Dollars, why would they want to
| overload it...
| jshreder wrote:
| 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
| ninepoints wrote:
| As someone in and out of the USD ecosystem for years
| (starting around 2014 or so), this comment is especially
| hilaruous.
| jimbob45 wrote:
| Maybe this is the new anti-crypto meta - we proactively take
| away the best acronyms that the crypto community would want
| to use.
| theogravity wrote:
| I also thought this was crypto related and felt it was odd
| Adobe, Pixar, and Autodesk were involved.
| moffkalast wrote:
| Yeah at first I thought it was some kind of store payment
| crypto they were introducing.
| dumpsterdiver wrote:
| 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)"
| therealmarv wrote:
| for a second I've thought they are creating a new crypto stable
| coin oO
| tukajo wrote:
| Why is the JDF (Japanese Defense Force) backing a new crypto
| coin (OpenUSD) with Apple, Pixar, Nvidia and Adobe?
| FrostKiwi wrote:
| How is this different from glTF? Are we getting another XKCD
| #927?
| can16358p wrote:
| 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)
| CharlesW wrote:
| > _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.
| habibur wrote:
| Anyone remembers VRML?
| gyf304 wrote:
| 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
| vxNsr wrote:
| Not all surprising that X3D uses xml and of course OpenUSD uses
| some form of python/json thing
| irrational wrote:
| 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).
| khazhoux wrote:
| 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: <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>
| JayStavis wrote:
| 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
| cubefox wrote:
| That's way too high level and ambiguous. Something could look
| okay in one browser and totally crap in another.
| johnnyanmac wrote:
| >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.
| datavirtue wrote:
| <surface orientation=x name="south wall" rotation=-125 .../>
| sien wrote:
| 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/
| ComodoHacker wrote:
| We had to wait 20 years until some entity interested in
| interoperability became powerful enough that vendors started
| listening to them.
| bschwindHN wrote:
| I remember VRML. Unfortunately KiCAD still uses it for 3D
| models (though thankfully it supports STEP files too)
| dang wrote:
| 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
| inconfident2021 wrote:
| My only question, why aren't they using gltf? What is the issue
| with gltf? It supports most of the things?
| dagw wrote:
| 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.
| strix_varius wrote:
| OpenUSD solves a very different problem than gltf.
| pjmlp wrote:
| 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.
| zokier wrote:
| 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...
| suierklepye wrote:
| 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.
| wildpeaks wrote:
| 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
| samplatt wrote:
| I can't tell you how much I'm looking forward to seeing assets
| distributed in USDZ format. Specifically: nuts.
| meindnoch wrote:
| Something is broken with your texcoords. The whole texture
| atlas is misaligned.
| bhouston wrote:
| The issue is that Apple doesn't support multiple texture
| transforms per material, rather it only supports one.
| dagmx wrote:
| 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.
| bhouston wrote:
| 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."
___________________________________________________________________
(page generated 2023-08-02 23:02 UTC)