This issue has nothing to do with pro or consumer. It has to do with the differences between optimizing for GPU runtime presentation vs optimizing for DCC author time modification. USD and USDZ were explicitly designed for use in DCC pipelines and the docs for the format are very clear it was not and is not intended as a runtime format.

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)

I hear you, but disagree on two counts:

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...

Due to the nature of the format, loading USDZ will always be slower than loading glTf. No matter how many smart engineers and money you throw on it, you can't optimize it faster. It's due to the nature of the data it stored inside. It takes more computation to translate USDZ than glTf to the format renderer/calculation uses.

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.

Actually, very few workflows at film studios rely on batch renders these days. Far more important to artist productivity are interactive workflows - being able to work in context at scale in and between DCC's, and therefore load speed was actually a huge design consideration for usd, and integration of USD's gl imaging system, Hydra Stream, into workflows, has been a game changer for many interactive workflows. Check out the paragraph "Maximize artistic iteration by minimizing latency" on the USD website's front page... or better yet, actually try out USD (usdview) with a modern allocator like jemalloc (since both ingestion and imaging in usd extensively leverage multithreading).

> Remember, your iPhone now has the power to render Toy Story [1].

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.