Hacker News new | comments | ask | show | jobs | submit login
USDZ File Format Specification [pdf] (pixar.com)
78 points by Tomte 7 months ago | hide | past | web | favorite | 41 comments



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.


Agreed, distributing USD assets with a 3D application is akin to distributing Photoshop PSD images with a 2D application.

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


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 [1] https://twitter.com/ID_AA_Carmack/status/766989221961748480


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.


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

https://github.com/KhronosGroup/glTF/tree/master/specificati...


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.


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?


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.


Also supported in products already by Facebook, Google, and even Microsoft. Really disappointed that Apple went their own way on this.


Apple didn't go their own way one this - they teamed up with the people who know this better than anyone, from Pixar to Epic.


Epic? As far as I can tell, Unreal Engine supports glTF import and does not support USDZ.

Which makes sense, because this is what glTF was designed for.

https://forums.unrealengine.com/development-discussion/conte...


Posting that Epic can import more than one file format does not prove me wrong.

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”


No, they made a minor change to an existing Pixar file format. Pixar who they already had a very cozy relationship with. The whole industry was standardizing onto glTF and Apple couldn't let that stand.


Your assumptions underscore your bias. Perhaps they have bigger dreams then the rest of industry.

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.


Why link to PDF instead of its dedicated web page https://graphics.pixar.com/usd/docs/Usdz-File-Format-Specifi... ?


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.


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.


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.


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

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.


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


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)


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.


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?


Uncompressed means you can mmap resources and directly use them (https://graphics.pixar.com/usd/docs/Usdz-File-Format-Specifi...: ”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.”


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


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


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


Pixar has open sourced several projects at GitHub, under the Apache license. Most significant is probably their OpenSubdiv software:

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

https://github.com/PixarAnimationStudios


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


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.


If they did that nobody would support it. That wouldn’t be very helpful.


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?


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


Honestly, because professionals don't use it.


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


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


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: