# Known file size limitations for usdzip? **URL:** \ **Category:** USD\ **Created:** [May 4, 2025, 10:21pm UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424 "2025-05-04T22:21:58Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![wave](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/wave/32/51_2.png) [@wave](https://forum.aousd.org/u/wave)\ **Post date:** [May 4, 2025, 10:21pm UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/1 "2025-05-04T22:21:58Z")
Consider the Animal Logic ALab asset. If you isolate the “stoat” character thusly: `usdcat --flatten -o stoat.usd --mask /root/stoat/body_M_hrc entry.usda` You get a file that renders fine in `usdview` and is almost 16GB (15,989,302,502 to be precise). If you then try and `usdzip` that file, not even considering all the materials, just the animated geometry thusly: `usdzip stoat stoat.usd` You end up with a 3GB file (3,104,400,780 to be exact). `usdzip` doesn’t report an error, and if I do the same steps from C++ checking for errors, I also don’t get any. `usdview` throws an error if I try and view it. Is there something obvious I’m missing here (I do that a lot…)? If there’s not, I’m happy to try and dig into the code and see where the error is getting missed… I seem to remember this coming up before (with `usdcat`?) but searching the obvious places didn’t turn anything up. - wave ---
**Author:** ![nporcino](https://avatars.discourse-cdn.com/v4/letter/n/3d9bf3/32.png) [@nporcino](https://forum.aousd.org/u/nporcino)\ **Post date:** [May 4, 2025, 10:31pm UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/2 "2025-05-04T22:31:22Z")
According to the spec, [Usdz File Format Specification — Universal Scene Description 25.05 documentation](https://openusd.org/release/spec_usdz.html) usdz is an uncompressed zip archive, and it doesn’t say it’s zip64. So that means a limit of 65535 files in the archive and a 4gb limit to the archive size. Methinks the tools should report when limits are exceeded, rather than generating a corrupt archive. Have to double check the code to see if it is actually zip64, but I don’t think so. ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [May 5, 2025, 12:04am UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/3 "2025-05-05T00:04:27Z")
There’s some nuance here. Reference my issue here [USDZ and Zip Compliance · Issue #3424 · PixarAnimationStudios/OpenUSD · GitHub](https://github.com/PixarAnimationStudios/OpenUSD/issues/3424) that I’d filed when we’d last discussed this internally. But essentially usdz is zip32 only. Our core specification will call this out explicitly. However, the zipfile reader doesn’t read the table of contents when parsing a usdz, and instead reads all the individual file listings sequentially. This has the confusing effect that as long as each individual file within a usdz is less than an unsigned 32bit int range , you can go above the zip32 total file size limit. But your file is now an invalid zip. I consider this a flaw in the zipfile reader, and we should really fix the zipfile IO to be more valid. The core specification will specifically say the files must be zip32 compliant. Anyway, I put up a PR for this [Make Zipfile.cpp validate content length for zip32 by dgovil · Pull Request #3618 · PixarAnimationStudios/OpenUSD · GitHub](https://github.com/PixarAnimationStudios/OpenUSD/pull/3618) ---
**Author:** ![spiff](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/spiff/32/22_2.png) [@spiff](https://forum.aousd.org/u/spiff)\ **Post date:** [May 5, 2025, 11:41pm UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/4 "2025-05-05T23:41:42Z")
I suspect, though, that studios and others’ internal use-cases for usdz will eventually be unhappy with the 4Gb limitation… are we against broadening the spec to include zip64 when needed? ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [May 6, 2025, 4:49am UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/5 "2025-05-06T04:49:32Z")
I think we’d all be fine with extending to Zip64 in a follow up spec version, unless Pixar feel that it’s something worth landing in 25.8 or the like? It’s a fairly trivial change imho but also not one I think folks are clamouring for immediately . We’d agreed to put Zip32 in the first version of the spec since it’s what all USD apps can support today. ---
**Author:** ![nporcino](https://avatars.discourse-cdn.com/v4/letter/n/3d9bf3/32.png) [@nporcino](https://forum.aousd.org/u/nporcino)\ **Post date:** [May 7, 2025, 12:47am UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/6 "2025-05-07T00:47:53Z")
If we went over 4gb would there be repercussions? Part of the original motivation for the address space size was to accommodate memmap limitations that affected platforms of the time. ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [May 7, 2025, 12:52am UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/7 "2025-05-07T00:52:08Z")
This would be very platform dependent. There’s platforms that would already not be fine with a 4GB file being memory mapped, but they’re also ones that wouldn’t be receiving such large files regularly. I think it would be better to document that large files may not work well, but let people create it if necessary ---
**Author:** ![wave](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/wave/32/51_2.png) [@wave](https://forum.aousd.org/u/wave)\ **Post date:** [May 8, 2025, 7:49pm UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/8 "2025-05-08T19:49:53Z")
Personally, I love the power of clear encapsulation that putting at least an asset in a USDZ gives you. I would totally want (as evinced by my question above) to be able to large assets with many variants in USDZ that was larger than 4GB. ---
**Author:** ![guidoq](https://avatars.discourse-cdn.com/v4/letter/g/cab0a1/32.png) [@guidoq](https://forum.aousd.org/u/guidoq)\ **Post date:** [August 25, 2026, 10:07pm UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/9 "2026-08-25T22:07:04Z")
Would be nice to revisit this, we are having issues regularly with the size of usdz and if it’s not resolved we will have to abandon USDZ and come up with something like USDBIGZ in our USD build. ---
**Author:** ![nporcino](https://avatars.discourse-cdn.com/v4/letter/n/3d9bf3/32.png) [@nporcino](https://forum.aousd.org/u/nporcino)\ **Post date:** [August 26, 2026, 3:20am UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/10 "2026-08-26T03:20:29Z")
I think allowing zip64, as suggested early in the thread, as an available format solves all around? ---
**Author:** ![spiff](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/spiff/32/22_2.png) [@spiff](https://forum.aousd.org/u/spiff)\ **Post date:** [August 26, 2026, 6:47pm UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/11 "2026-08-26T18:47:31Z")
Let’s concentrate any need/timing discussion on [this GitHub Issue](https://github.com/PixarAnimationStudios/OpenUSD/issues/4201) . I am curious about the severity and mitigations for this concern: > [@dhruvgovil](#): > > This would be very platform dependent. There’s platforms that would already not be fine with a 4GB file being memory mapped, but they’re also ones that wouldn’t be receiving such large files regularly. > > I think it would be better to document that large files may not work well, but let people create it if necessary @nporcino , I don’t think we can leverage profiles to facilitate dynamic responses since you’d need to first open the file. But maybe it’s as simple as a file-size check before opening? Can we typically determine file-size prior to (e.g. in a web delivery context) downloading the file? ---
**Author:** ![nporcino](https://avatars.discourse-cdn.com/v4/letter/n/3d9bf3/32.png) [@nporcino](https://forum.aousd.org/u/nporcino)\ **Post date:** [August 26, 2026, 7:12pm UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/12 "2026-08-26T19:12:59Z")
the response header from a HEAD or GET request usually includes (is expected to include) a `Content-Length` field. If the file is compressed, ie gzip(foo.usdz), the length will be the compressed length. ---
**Author:** ![guidoq](https://avatars.discourse-cdn.com/v4/letter/g/cab0a1/32.png) [@guidoq](https://forum.aousd.org/u/guidoq)\ **Post date:** [August 31, 2026, 8:06am UTC](https://forum.aousd.org/t/known-file-size-limitations-for-usdzip/2424/13 "2026-08-31T08:06:48Z")
Basically we need an “atomic” format for USD that carries geo/textures etc. Most common use case is upload/download. Yes, we could user another package system and call it something else but it seems reasonable to just lift this limitation. For platforms not capable of dealing with these files sizes, a warning/exit seems a reasonable option that applied for situation where even 4GB is too big.