BlenderUSDZ: a USDZ export add-on for augmented reality assets

An add-on for Apple's format, not a USD interchange solution

BlenderUSDZ is a USDZ file import and export plugin for Blender that provides a simple method of moving models in and out of the formats used by augmented reality applications. It is written in Python, released under the GPL-3.0 licence, and the repository is not archived, with the last push on 2026-08-02 and no tagged releases.

The scope of the project is stated bluntly in its notes, and it is the first thing to understand. This add-on was only intended for exporting Apple's usdz files, which is not intended as an interchange format. For full USD interchange functionality, the documentation says to look into Blender's built-in USD options.

That single sentence decides who should use it. If you are producing assets for an AR application that consumes USDZ, this is the tool. If you are trying to move USD data between pipelines, you want Blender's own USD support, and using this add-on would be a detour that loses information.

The repository layout is small: an Addons/ directory with the source, an io_scene_usdz.zip at the root, a testing/ directory and the README. The zip at the root is the artefact you install, which is worth noting because there is no release page to download from and no version history beyond the commits, so the zip in the repository root is both the current build and the only build.

Installing from a zip, and the Blender version floor

The installation is a five step procedure that avoids any command line, which is consistent with the add-on being aimed at artists rather than at pipeline engineers.

You download the io_export_usdz.zip file from the root of the repository. You open Blender 4.5 or later and go to Edit, then User Preferences. In User Preferences you select Add-ons in the menu on the left hand side, and then the Install button at the top right of the window. You navigate to the downloaded zip file and select it. Finally you select the check mark next to the Import-Export: UDSZ format entry to activate the plugin.

Two details are worth flagging. The Blender version floor is 4.5, so an older Blender will not have the add-on in its add-on list in the same place, and the add-on naming in the preferences follows the older extension naming convention, which is why it appears as an Import-Export entry rather than under a shorter name.

The other detail is the file name mismatch in the README itself. The heading calls it a UDSZ add-on and the activation entry reads UDSZ format, while the format itself is USDZ and the description calls it a USDZ plugin. The zip is named io_scene_usdz.zip, which follows the Blender convention for a scene import and export add-on. Small inconsistency, no practical consequence, but a reader searching for the add-on in the preferences list should look for UDSZ as well as USDZ.

Two export paths, and a warning to save first

The export functions are reachable in two ways, and they export different things.

The first is the File, Export, USDZ (.usdz) menu. When you use the file menu export, object selection determines what gets exported, which is the familiar behaviour of a Blender export.

The second is the Exporters panel in the Collection Properties, and when you use the panel the add-on exports the items in the selected collection. That is a different selection model, and for a scene built out of collections it is the one that saves you from selecting objects by hand.

The documentation opens the usage section with a sentence that is easy to skim past: always be sure to save your work before using this tool. In an add-on that switches the render engine to Cycles to bake textures, that sentence is doing more work than it looks, because a bake is a long operation on a scene that may be mid-edit.

The import side is much quieter about its own limits, and the notes section is where that comes out. The import functionality is currently limited to simple static models with no animations, so the add-on is a one-way street for anything animated, and the export of animation goes the other way, with the active object or bone animation written into the file.

Material export, texture baking and the cost of both

The options are where most of the behaviour lives, and the dependency chain between them is the thing to understand.

Export Materials writes object materials as USD Principled shader materials, which share many of the same properties as the Principled BSDF shader for Eevee and Cycles in Blender. The limitation stated is that Mix and Add shader nodes are not supported yet in this add-on, so a material built on those nodes will not come across.

Bake Textures, when enabled, bakes any textures associated with materials out to image files that get bundled into the usdz file. The add-on automatically switches to Cycles to bake images, which the documentation says could take a significant amount of time. The option is ignored if Export Materials is unchecked, and that dependency is repeated by the other options, which is a sensible way to avoid baking work that would be thrown away.

Use Gpu Compute is enabled by default and uses Cycles GPU Compute for the baking, with disabling it falling back to CPU Cycles. So on a machine without a configured GPU compute device, the fallback is the behaviour you get, and the export will be slower.

Bake AO bakes ambient occlusion textures applied to the USD Principled shader materials, which can add a significant amount of time to the export, and is likewise ignored if Export Materials is unchecked. Samples sets the number of samples used in the ambient occlusion baking, where a higher number gives higher quality occlusion textures at the cost of export time, and it is ignored if either Export Materials or Bake AO is unchecked.

Scale is the remaining export option, and it scales the objects written into the file, which matters because the units of an AR asset are part of its meaning.

On the import side there is a single option, Import Materials, which attempts to import materials associated with objects.

The binary USD inside, and why a file can still be rejected

The most important note in the documentation is about the file format inside the container, and it is easy to miss because it is buried in the notes.

A usdz file is a package, and the USD data inside it is binary. The generated binary usd file used in the exported usdz file could potentially be incompatible with some augmented reality applications. The reason is stated next: the add-on provides a completely separate, Python only implementation for reading and writing binary USD files, and it is possible that there could be incompatibilities between this and the official implementations of the binary USD format.

That is a real limitation with a clear cause. The add-on does not shell out to the official USD libraries; it implements the binary format itself, in Python, so it does not need the USD toolchain installed and it does not inherit the reference implementation's edge case handling. The trade is convenience against exactness, and the failure mode is an AR application that refuses the file for reasons that are not visible in Blender.

For a reader deciding whether to use the add-on, the practical test is empirical: export a small scene with the settings that matter, load it in the target application, and see whether it works. The add-on is useful precisely when the target is a consumer of Apple's format, and the caveat applies to the same file.

The import side has the same shape of limitation in a different direction, since importing is limited to simple static models with no animations, so the add-on covers a real need and stops at a well defined line.

Editorial conclusion

BlenderUSDZ fits a Blender artist who needs a USDZ file that an AR application will load, since the add-on exists for exactly that purpose and the export path is two clicks from the File menu. It is the wrong tool if you need USD as an interchange format between tools, because the documentation itself points you at Blender's built-in USD options for that, and it is the wrong tool if your scene relies on Mix or Add shader nodes, which the add-on does not support yet. Before you rely on it, save your work, because the documentation asks you to, and note that a texture bake switches the add-on to Cycles and can take a long time. And if the AR application you are targeting rejects the file, the reason is probably that the binary USD inside is written by the add-on's own Python implementation rather than by the official one.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. robmcrosby/BlenderUSDZ on GitHub