Apple's Choice: USDZ over Other 3D File Formats like GLTF

apple chose it because it's a good format. it is also open source and extensible, i don't see how gltf is more flexible. also i never ran into any 3d program that focuses on it. usd also allows for cross discipline collaboration on the same file at the same time. you can have artists, sound designers, programmers etc all working on the same file at the same time.

security had nothing to do with.

there aren't any limitations.

Anyone who regurgitates the definition of the format as it being 'good' and 'flexible' and touts its 'versatility' probably not even using it in their own work and they're just reading a description of it from Wikipedia.

It's a format that sounds good on paper but in actual use for your typical 3D artist can be a pain. Don't get me wrong, it can be powerful. It requires a lot of organization. NVIDIA's Omniverse is the only platform I think that is recently trying to forcibly adopt it, however, you can author models in FBX/OBJ/GLTF and bring them into USD in that software. But again, that's in that context. I only seeing it being useful to large animation studios with proprietary software pipelines, where large-scale organization is absolutely needed across hundreds or thousands of individuals who will have a hand in something. But imagine the file size...

In a strictly Augmented Reality context, I can think of several limitations and headaches the format provides.

GLTF/GLB is a far better 3D format for web usage. Apple has repeatedly refused to play ball with everyone else on the web. Just look at how poorly Safari is supported, and most developers use Chrome.

GLTF has had far more extensibility. KHR extensions and Draco compression higher fidelity and smaller file size models to be viewed with a model-viewer and augmented reality. Things like glass refraction, sheen, etc, and other fancy shaders can be seen on models on the web, packed in an easy-to-transfer format, across multiple devices. Artists can use multiple UV channels for specialized maps like Ambient Occlusion and Normal Maps, and tile detail maps on another channel for optimized use of texture resolution. USDZ does not allow any of this. Not only that, but USDZ isn't even compressed despite being a 'zipped' format. How useless.

So once again, Apple has decided to keep a stagnate walled garden. It is incredibly frustrating. If I'm creating AR models/products for clients, they appear vastly differently across iOS and Android devices because of Apple's limitations. This should not be the case. There's no point in having what you would call a 'standardized' format when it cannot be used as standard across different devices.

@Umbra: I completely agree with you on this. Working with USDZ for iOS AR experiences is incredibly time-consuming and frustrating for our company. We frequently find ourselves reverse-engineering problems and issues specific to the USDZ format that simply don't exist with GLB.

Let me provide an example: We create high-quality 3D product models for web and AR applications. These can be compressed to 4-12 MB as GLB files. However, maintaining the same quality in USDZ format often results in file sizes of 60 MB or more. This leads to frequent crashes in iOS Safari or excessively long loading times in AR, making it impractical to offer to customers.

Consequently, we're forced to adopt a dual approach: high-quality models for Android AR cases and lower quality for Apple devices. This clearly contradicts Apple's mission of providing superior user experiences.

Furthermore, we're reliant on unpolished software like "Reality Converter," which seems to be in perpetual development with virtually no communication from Apple. We resort to downloading it monthly just to check if there's been a version update.

It's challenging to comprehend Apple's strategy here. With Vision Pro and the iPad and iPhone positioned as excellent AR devices, the obstacles they're creating are baffling. I believe that dedicating a team to USDZ development, or even just assigning 5 staff members to the task, could make a world of difference.

We use an USDZ-first workflow that tries to keep meshes using Quads and Ngons as long as possible. The standard USD(Z) in fact is older than GLTF2. It was Google who decided against a common standard and forces users and developers for years to depend on Chrome and complex WebApps per every single use case. GLTF2/GLB can only use high poly triangle meshes to achieve smooth surfaces. That's why a conversion of those crippled meshes to OpenUSD becomes bigger.

The best way to achieve smooth, compact but still animatable surfaces is to use SubD patches (supported by iOS18+).

The main difference between glTF and USDZ is IMHO:

• glTF is limited to single assets, great for eCommerce.
• USDZ can either contain a single asset OR it can contain one or many complex interactive scenes with many assets, even sounds.

There's even a new 3D web platform that natively loads and renders openUSD files in all browsers I know about: cloudzeta

Most of the 40+ KHR_ extensions have not been added to the ISO standard and Google just recently abandoned SceneViewer, their equivalent to Apple's AR Quick Look to force developers and users into relying on WebXR. Update: They abandoned it several years ago by not adding support for any KHR extension. But recently they forbid download from the Playstore mentioning "not supported any longer on this device"