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.
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
BIM requirements are very different to 3D graphics and animation requirements.
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.
Since its an existing standard hasn't this already been done, at least to a decent extent?
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.
Disclaimer: I worked for Allegorithmic and now work for Adobe.
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.
I left https://news.ycombinator.com/item?id=36962294 out because it has actual interesting information about the project.
bullshit
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..
But in terms of "common format which different systems can read", then yes, sure.
As opposed to the United States dollar that became public after 2013?
I mean, seriously: OpenUSD sounds like a cryptocurrency "stablecoin" token name.
It’s ok for jargon and acronyms to be confusing to people who are not at all in the field.
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?
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.
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.
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)"
UNISD? UNIversal Scene Description
At least better than Universal Scene Specific (USS)
> 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]
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...
Also, USD supports USDShade and MaterialX material (shader network) definitions, and I imagine there will be full round-tripping support for that?
Trust me, it’s about programming. Not snake horror dystopias.
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
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.
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.
If we're just gonna make up statistics...
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.
I don't know. You can stream Unity to mobile with the service I've authored (https://appmana.com/watch/theheretic for an example).
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.
You created Appmana?
> Just order out bro.
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.
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.
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.
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.
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.
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").
If anyone finds an AI that can do reasonable SVGs, please do let me know.
long live sidefx
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.
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.
I feel like there's never been a 3D counterpart to standards like Midi for audio.
Even Autodesk is backing USD so presumably even they have given up on the long term prospects of FBX.
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.
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.
Edit: it’s actually not just meshes that are supported. But the usual CAD/CAM surfaces are still not supported.
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."
“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 Wētā 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
USD has the most traction in the offline rendering world, but it's creeping into gamedev workflows too as a replacement for FBX.
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_...
there it is https://allaboutstevejobs.com/videos/misc/nextstep_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.
There should be several hundreds active corporate alliances now.
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 :)
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...
What information does the OpenUSD format carry?
It seems like a great format so far, but I'm skeptical based on Adobe, Apple, Autodesk track records for "open" formats.
"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."
https://www.amd.com/en/technologies/radeon-prorender ("A Pixar® USD™ Hydra™ render delegate...")
They already made a universal scene description standard.
USD has more layering and referencing capabilities
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.
(I mean as a universally accepted format that just works everywhere, not literally a JPEG on H.264 inside a scene)
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.
Or maybe glTF and other interchange formats already satisfy that need.
"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.
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.
All the plugins that used to be needed to display VRML online are gone now, but you can still display VRML 2.0/97 files online using JavaScript library called X_ITE [1]. I used it recently to view some old VRML I had saved but could no longer view. Works great.
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>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
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.
That was my initial thought also.
> Although X3D is a bit more verbose
The USDA file format reminds me a lot of the pre-XML VRML 97 file format, with the curly bracket C-style syntax, #comments, and 'def' everywhere.
https://openusd.org/release/spec_usdpreviewsurface.html#usd-...
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,…).
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.
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.
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.
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.
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.
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.
I have an iPhone 13 Pro and a decent internet connection and if I came across that I would bounce out immediately.
I tried a bunch of keyboard commands and nothing happened. Can I test drive the car?
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.
Thanks!
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?
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.
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.
but then you loose the human readability / "understand-ability at a glance" advantage, so it sort of depends what the use-case is...
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.
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.
Having to do any form of interpretation (even scientific notation is not ideal in some cases), is not great for many users.
Most OOP languages have a "debug print" or "shell inspect" method that the programmer can override, where by default the method will print something that's valid language syntax, but where the overrides aren't required or expected to be such, and instead should concisely describe the object at the expense of being reloadable. These same languages usually also have support for custom serializers for text-based serialization formats like JSON. The serializer implementation for JSON, and the serializer implementation for "shell inspect", are rarely identical.
I think what a CG/VFX artist would want here, isn't that the canonical textual file-format "for import" gives them decimal-serialized floats; but rather that they have the option to "inspect" the project, resulting in a view that looks like e.g. https://www.tonymacx86.com/media/ioregistryexplorer.187440/f... — an hierarchically-expandable "shell inspect" of the project. It makes perfect sense for the floats in such a read-only debugging-oriented view to be rendered in decimal (esp. if a raw canonical binary-data representation is given in parentheses beside the rendered value.)
If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse. If that means implementations have to ship their own float formatter and parser than so be it - no one is tied to whatever comes with their libc, package manager or no package manager.
But it isn't just about undefined behavior, it's more about the culture of C and how it approaches package management and sharing (or in this case, doesn't). Even if C has Rust level correctness checking it would have the same issue.
>If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse.
Well I guess we have our answer in the case of seriousness. I'm guessing it didn't matter enough for the implementers, or it did matter but could never actually get it implemented. The reasons for this are numerous, contextual (with context we'll never have), and probably not rooted in technical reasoning.
We are talking about the domain of animation and games, after all. Not mission critical code. There's more wiggle room, especially for the complexity of media around when the format was being developed.
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.
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.
Projects that want leaner dependencies, like everything on the web, don’t yet have a good way to work with USD.
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.
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).
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.
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...
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.
Even GLB, the binary glTF format, is very sub-optimal for runtime. It even has chunks of JSON embedded in it.
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.
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.
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.
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.
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.