
USDZ File Format Specification [pdf] - Tomte
https://graphics.pixar.com/usd/files/USDZFileFormatSpecification.pdf
======
yodon
This does not feel like a great decision on Apple’s part.

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.

~~~
MR4D
I think that's a shortsighted response.

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](https://en.wikipedia.org/wiki/PDF) [1]
[https://twitter.com/ID_AA_Carmack/status/766989221961748480](https://twitter.com/ID_AA_Carmack/status/766989221961748480)

~~~
yodon
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)

~~~
MR4D
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...](https://www.cinemablend.com/games/1631230/why-two-disney-films-
rendered-scenes-in-unreal-engine-4)

[2] - [https://www.polygon.com/2017/3/1/14778602/epic-gdc-
finding-d...](https://www.polygon.com/2017/3/1/14778602/epic-gdc-finding-dory)

~~~
delta-v
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.

~~~
usdfan
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).

------
randyrand
My favorite format for this is Gltf. The spec is very concise, and powerful.

[https://github.com/KhronosGroup/glTF/tree/master/specificati...](https://github.com/KhronosGroup/glTF/tree/master/specification/2.0)

~~~
jsheard
And most importantly for a runtime format, glTF is _fast and easy to load_.
It's specifically designed to mirror the capabilities of real-time 3D APIs and
allow mesh data to be memcpy'd directly onto the GPU with zero processing at
load-time. On the other hand USD/USDZ doesn't even attempt to be GPU-friendly,
given it was designed as an exchange format for production.

~~~
usdfan
Although USD's native binary format compresses integer topology data, mesh
(and curve) point, normal, and uv data is laid out in arrays that can be
directly uploaded to a gpu from the file system with zero copies or
processing.

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?

~~~
jessev
I found the layer and streaming features interesting. It seems to me like
that's the big win over gltf. Correct me if I'm wrong, but it seems like USD
might support things like streaming LODs or even tiling long term.

------
ognyankulev
Why link to PDF instead of its dedicated web page
[https://graphics.pixar.com/usd/docs/Usdz-File-Format-
Specifi...](https://graphics.pixar.com/usd/docs/Usdz-File-Format-
Specification.html) ?

------
ihuman
This was announced a few minutes ago at Apple's WWDC event. iOS and Adobe CC
will have native support for USDZ objects. Since the confereance is still
going on, there's no official website with information on their support.

------
mutagen
Some interesting technical decisions in the file format, USDZ is a zip file
with no compression or encryption for zero copy / mmap the file from heap. 64
byte alignment for AVX512. Consideration given to file ordering for streaming
and LOD.

~~~
tinus_hn
I’m not sure where I’ve seen the uncompressed storage before but it certainly
isn’t a new idea. Not sure if it still relevant though, it’s a waste of space
and bandwidth and you have to make sure the tradeoff is worth it.

------
pavlov
Reminds me of the last time Apple and Pixar announced a format they developed
together, back at WWDC 2003:
[https://en.wikipedia.org/wiki/Pixlet](https://en.wikipedia.org/wiki/Pixlet)

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.

------
rambojazz
Is this a free format? I mean an open standard without patents and copyright
restrictions?

------
cwmma
If they were going to do a subset of ZIP files, then they should have
prohibited some of the weirder quirks of the format such as files being
deleted 'in place' and multiple central directories (the valid one is the last
one)

~~~
bburky
Or many of the other issues that plague archive formats: duplicate files in
the archive at the same path, symlinks in the archive or relative links
enabling directory traversal.

------
niutech
If I got it right, this is a container format as an uncompressed ZIP archive.
What is its advantage over zipped X3D, STL, DAE files?

~~~
Someone
Uncompressed means you can mmap resources and directly use them
([https://graphics.pixar.com/usd/docs/Usdz-File-Format-
Specifi...](https://graphics.pixar.com/usd/docs/Usdz-File-Format-
Specification.html): _”A usdz file can contain only file types whose data can
be consumed by the USD runtime via mmap or (eventually) pointer to memory.”_ )

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

~~~
niutech
How about other formats without compression, such as X3D, COLLADA?

~~~
taharvey
I've spent the last week trying to get good file transfer between two
applictions, just for static 3D scenes - and I don't know if there isn
existing file format. Heck, I can't even get two applications from Autodesk to
wholly share a full 3D 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

------
electricslpnsld
Given Disney's ownership of Pixar, I'm amazed this isn't a patent nightmare!

~~~
karimdag
Maybe it's due to Apple's (Steve) history with Pixar ?

~~~
porphyrogene
It's more likely because of Pixar's longstanding practice of keeping its core
technologies openly available (Blender is rife with technologies originally
developed by Pixar gurus, not the least of which is RenderMan). Disney may be
a huge company but Pixar is the only part of it that has ever won an Academy
Awards (it has about ten as I remember) except for a single award for Beauty
and the Beast. A Pixar guru also runs both Pixar and the entire Disney
Animation Studio. Jobs never had a reputation of being generous with patents.
It's also just a smart move in general, people are tired of application-
restricted file formats in this field.

------
Osmium
If I have an asset (e.g. Collada .dae), are there tools available to create a
USDZ? Or can USDZ be created programmatically via SceneKit?

------
gnoffa
Hope there will be some nice implementations for Blender too, didn't see it
mentioned in Apple's keynote.

~~~
taharvey
Honestly, because professionals don't use it.

------
dustinmoorenet
I keep reading USD as $. Would be very hard to google by itself.

~~~
djrogers
Not really. Google for USD file format - the entire first page is filled with
links to incredibly helpful and detailed pages.

~~~
jessev
But try googling for usdz conversion. Or worse, the non zip version, usd
conversion. No doubt, not the best SEO.

