Alembic for Unity: a package for simulation caches between DCC tools

What the package is for

Alembic is a data format mainly used in the VFX industry to store very large vertex cache data such as complex cloth and fluid simulation results, or complex animation rigs. The Alembic for Unity package is the bridge that lets that data move between a simulation package and the Unity editor.

The main features of the package are Alembic file import and export, and the README frames the two directions clearly. One direction lets you use Unity as a rendering or compositing tool, which is what a studio does when the simulation is done elsewhere and Unity is where the shot gets finished. The other direction lets you perform various simulations in Unity and pass the results to other DCC tools.

That second direction is the more interesting one for a game studio. It means a simulation that used to require leaving the engine can run inside the engine, with the result written back out in a format the rest of the pipeline understands.

The package is developed and distributed by Unity and is also open to user contribution, with the contribution instructions in a CONTRIBUTIONS.md file. It ships as a Unity package, com.unity.formats.alembic, with the C# and native plugin code built into it.

Why the repository is not the recommended install path

The Before you start section of the README is a single emphatic note, and it is the first thing to internalise.

It says to use this repository only if you need to build the Alembic for Unity package from its source. Otherwise, to use Alembic for Unity, you should install its latest available official version from the Unity Editor through the Package Manager, with a link to the package documentation.

This is a different shape from most open source projects, and it changes how you evaluate the repository. You are not looking at a library you add to your project dependencies. You are looking at the source of a package that Unity builds, signs and distributes, and that you install from the editor's package manager. The repository is where you would go if you needed to change the package itself, for instance to add a feature that Unity has not shipped, or to build a version against a different Alembic SDK.

That framing also tells you what the repository is not. It is not a place to file issues about using the package, and the support section says as much. Bugs while using the package should be reported directly inside the Unity editor with the Bug Reporter tool, and any other questions or issues should go to the official Unity Forum, in the virtual production category.

For most teams the honest answer is that you will never need to build this, and you should spend your time on the Package Manager route instead.

Building it: submodules, CMake and a platform compiler

If you do need to build the package, the requirements are specific and the process is three steps.

The Unity Editor versions supported by the latest official build from this repository are 2019.4 and later, with 2019.4 and later recommended, and the supported platforms are 64-bit desktop systems: Microsoft Windows on x86-64, macOS on x86-64 and arm64, and Linux on x86-64. That platform list is the practical constraint, since it rules out older macOS Intel laptops outside x86-64 and anything that is not a desktop.

The external dependencies for the build itself are CMake 3 or later and a C++ compiler, which is Visual Studio 2017 or later with the C++ toolchain on Windows, Clang from Xcode 12.3 or later on macOS, and GCC 7 or later on Linux.

The steps are: clone the repository, check out the submodules with

git submodule update --init --recursive

which the README notes is only required the first time, and then run the build command for your platform, build.cmd on Windows or build.sh on macOS or Linux.

The result of the build, including the package, the C# code and the native plugin code, is stored at com.unity.formats.alembic in the tree. Debug variants of the build exist as separate scripts, buildDebug.cmd and buildDebug.sh, which is a hint about how the native plugin is developed.

What the repository layout tells you

The tree is the clearest description of how the package is put together.

There is a CMakeLists.txt at the root, a cmake/ directory for the build configuration, a Source/ directory, an External/ directory that holds the third party sources the build pulls in, and a com.unity.formats.alembic/ directory that is the package itself, with the C# and native plugin code that the build drops there. TestProjects/ holds Unity projects used for testing, Tools/ holds helper scripts, and Screenshots/ holds the example image the README shows.

The presence of a .gitmodules file and the External/ directory is the important structural fact. The Alembic implementation and its dependencies arrive as submodules, which is why the submodule checkout step exists and why the build needs network access the first time. It also means the version of the Alembic SDK being compiled against is decided by a pointer in the repository rather than by the package manager, and that pointer is the thing you would update if you needed a newer SDK.

There is also a set of files that reveal how Unity ships this internally: .repoconfig for the internal repository configuration, .yamato/ for the build system, appcollector.yaml, fdgRulesets/ for the rule sets the internal tools enforce, and windows_codesign_list.txt, which lists the binaries that get code signed for Windows distribution. Those last two are the reminder that a Unity package is a shipped, signed artefact, not a script you run from a checkout.

Release tags and the contribution path

The release record is unusual and worth reading before you draw conclusions from it. The tagged releases are named by date rather than by version, with 20180413 dated 2018-04-13, 20180320 dated 2018-03-20 and 20180222 dated 2018-02-22. Those are the tags a Unity package build would derive its version from.

That tells you how the package is versioned, not when it stopped changing. The last push to this repository was on 2026-10-14, so the source is being worked on well after those 2018 tags. The gap between the tags and the branch head is the normal shape for a repository whose published artefacts come from an internal release pipeline rather than from its own tags.

Contributions run through the CONTRIBUTIONS.md file, which the README asks you to read, and the project states that it is open to user contribution while being developed and distributed by Unity. The contribution route is therefore a pull request into a repository owned by the vendor, which is a different dynamic from a community owned project, and worth factoring in if you are considering maintaining a fork.

The repository also carries .buginfo, an .editorconfig, a .gitattributes, an .ignore and a .gitlab-ci.yml, which is a reasonably complete house style for a repository that feeds an internal build system.

Where the Alembic package is the wrong tool

Three cases point elsewhere.

The first is a project that needs to exchange ordinary scene geometry rather than simulation caches. Alembic's strength is the vertex cache, a format built to hold the output of a simulation over time in a way that other tools can read. If your requirement is a mesh, a rig or a level, the interchange formats your pipeline already uses will serve better, and this package will add a large dependency for a narrow job.

The second is a case where the format's scale is a liability rather than a feature. Very large vertex cache data is exactly what Alembic is designed for, and the same property means the import can be slow and memory hungry for a small file, since the format does not have a cheap mode.

The third is a team that needs a supported path. This package is distributed by Unity, and the README routes bug reports to the Unity editor's Bug Reporter tool and other questions to the official Unity Forum. If you need a contractual support commitment, that is a conversation with Unity rather than with this repository, and a self built package carries no support relationship at all.

There is also a licensing point to resolve before you build. No licence is recorded for the repository, while the Alembic implementation it vendors has its own terms, and the Unity package you install through the Package Manager carries terms separate from both. Check each of those before you redistribute a build of your own.

Editorial conclusion

Adopt Alembic for Unity if you are a studio that receives Alembic caches from simulation and needs them inside Unity, or if you need to push simulation results computed in Unity back to other DCC tools. Do not adopt it as a general interchange format for everyday geometry, and do not build it from source unless you have a specific reason, since the README says to install the official package from the Unity Package Manager otherwise. Verify three things first: that your Alembic files carry the data you need, since the format is built around vertex caches rather than around a scene graph; that your Unity Editor version is 2019.4 or later and your platform is one of the listed 64 bit desktops; and how you handle builds, because the package contains native plugin code and the repository carries a Windows code signing list. No licence is recorded for the repository, the tagged releases are date named from 2018, and the last push was on 2026-10-14.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Unity-Technologies/com.unity.formats.alembic on GitHub