USDZ File Format Specification [pdf]
graphics.pixar.com
graphics.pixar.com
USD and USDZ were designed to exchange source art assets in the content pipeline of a film studio. They are fantastic for that use case, but they were never designed for the needs of real-time client-side rendering applications like Apple is promoting it for.
Adopting USDZ as the preferred runtime distribution format feels like a decision made by a manager who lacks serious experience in high performance real-time client applications.
(that's not a perfect analogy since USD is open and PSD isn't, but "open PSD" would still be a terrible runtime format)
Apple being Apple I didn't expect them to adopt Khronos' glTF format, but they could have at least designed something similar.
If you look at another technology that started out on the pro side and eventually dominated the consumer landscape, it's Adobe's PDF format.
To quote wikipedia (sorry): "In the early years PDF was popular mainly in desktop publishing workflows, and competed with a variety of formats such as DjVu, Envoy, Common Ground Digital Paper, Farallon Replica and even Adobe's own PostScript format."
I think those key words suggest that Apple is being farsighted here. In 10 years, the idea that computers will want anything less than a professional model will be quaint.
Remember, your iPhone now has the power to render Toy Story [1].
[0] https://en.wikipedia.org/wiki/PDF [1] https://twitter.com/ID_AA_Carmack/status/766989221961748480
As other posters have commented here, glTf is the current best practice for runtime delivery formats (and, by extension, glTf would be a terrible choice for author-time DCC Data exchange, for exactly the same reasons as why USDZ is better suited to authoring than delivery).
Moore’s law and computers getting faster won’t make USDZ a good runtime format. glTf will remain the better runtime format and USDZ will remain the better authoring format, because that’s what they were designed to do well. As someone else observed, it doesn’t matter how fast your browser gets, no one is going to recommend you populate your website with PSD images, because PSD is an authoring format not a delivery format (and likewise PDF is an equally terrible authoring format but a great delivery format)
1 - look at the people onboard the USDZ format (pixar, adobe, autodesk, epic, etc.). This is geared towards getting designers to bring in high quality 3d from the the first step of the pipeline.
2 - Just because apple uses the format doesn't mean they don't optimize it for display. I have no idea what happens behind the scenes, but if they could make PDF work well for a desktop, then I have faith in them. Look a this link [1] and the video [2] from a YEAR AGO. It seems to support my thoughts (via the Unreal Engine). The second paragraph is the key.
I understand your concerns, but I truly believe that in two years, you will look back on this and say, "yeah, they figured out how to get this to work well." Of course, I am wrong occasionally, too :)
[1] - https://www.cinemablend.com/games/1631230/why-two-disney-fil...
[2] - https://www.polygon.com/2017/3/1/14778602/epic-gdc-finding-d...
The example you given is actually irrelevant for consumer use cases. For consumers, loading speed matters. They are interactive apps. They can't spend too much time loading. While for film studio, they are batch rendering scenes. Loading speed is a lot less important.
That is technically true, but in the same sense ENIAC could have rendered Toy Story. Realistically there's a lot more to it than just transistor count.
It's also a strange comment, because in all three cases (the original render farm, iPhone, or ENIAC) it would (or did) take months of real time to render the whole thing.
https://github.com/KhronosGroup/glTF/tree/master/specificati...
Apple stands out from the rest of those industry players by historically having much longer range architectural vision. They have also been investing heavily in their devices for many years to support that vision. The processing power of the typical iPhone outruns average competitor by multiples.
Which makes sense, because this is what glTF was designed for.
https://forums.unrealengine.com/development-discussion/conte...
Thankfully, some quotes from Epic Directors can prove me right....
https://uploadvr.com/epic-games-unreal-engine-april/
To quotes the Technical Director from Epic:
“We will increasingly use USD here. Hopefully, we will keep working with Pixar to make it awesome for every use case we can imagine. ”
And,
“The cool thing here is that we don’t need any other separate tools to go from USD to what you’d see on screen with this demo”
It is true that there are several more software layers in USD between file-open and mesh-data-extraction, but to the earlier "forward looking" comment, what you get for that are built on features for allowing clients to select variations with smart/sparse updating, and serious scalability features, for larger scenes. These are all features that have been added since USD's release, and there is still quite a lot of development underway.
No knocks on glTf, which does a great job at what it's designed for. But maybe Apple is looking at a different future?
Pixlet didn't take off because it was yet another non-standard codec in a market that was converging towards video standards that could be accelerated in hardware.
The argument made by jsheard about gITF's design being better suited for GPU acceleration is very important IMHO.
If you stored resources compressed, memory usage likely would go up, as you would need (part of) the compressed and the uncompressed resource in memory.
Traditionally, that would be offset by decreased disk usage and faster I/O, but disks are a lot larger and a lot faster nowadays.
Presumably, you would still download these files compressed (e.g. using http compression)
Edit: further Dow, that page is clear that that’s the reason for not compressing chunks:
”A key consideration for efficient direct consumption of usdz files is that, given an archive already held in heap storage (possibly arriving over a network) or as a single file on disk, we be able to use the most direct API's available in USD for accessing the data contained within the archive, without extracting files to disk, or allocating more heap storage. If we allowed either compression or encryption in usdz archives, we would need to violate one or both of the preconditions that allow, for example, the usda and usdc formats to access their data via direct memory access (typically via mmap).
We do not believe the lack of zip compression will be a serious concern for data size. Most image formats themselves allow internal compression schemes, and the usdc format is quite compact, particularly as you collect more data into a single file; although we do not yet have an end-user tool for doing so, USD now contains all of the core features we require to aggregate an arbitrary composition's worth of usd files into a single file, without removing any composition features from the scene.”
If you know of a 3D file format that understand all types of geometry: Nurbs, solids, polygons AND physics based material shaders, AND understands whole scenes: lighting, cameras, and animation. Well I'd like to know of another one.
Also this format adds futher concepts from a pipeline, things that are interesting to AR like late stage lighting, effects, composition, and overrides
"OpenSubdiv is a set of open source libraries that implement high performance subdivision surface (subdiv) evaluation on massively parallel CPU and GPU architectures. This code path is optimized for drawing deforming surfaces with static topology at interactive framerates.
OpenSubdiv is an API ready to be integrated into 3rd party digital content creation tools. It is not an application, nor a tool that can be used directly to create digital assets."