Content directories: Beyond the AssetBundle

Sep 22, 2026|6 Min

George Ing - Unity Technologies

Senior Engineering Manager

A bit about content in Unity today

Since Unity 2.1, the humble AssetBundle has underpinned Unity content shipped outside of the Player binary. These past twenty years an extraordinary number of games have used AssetBundles as their data representation, including some of the largest titles in the world.

At a basic level, each AssetBundle is an indivisible unit for distribution, storage and loading. AssetBundles track their dependencies at a bundle level, forming a larger monolithic unit that, for efficiency, needs to be downloaded, loaded and unloaded together.

Because of this specification, how a title defines its AssetBundle layout is a primary factor in everything from its runtime performance to its download size. This is true whether using AssetBundles directly, or via the Addressables package.

Today, we’re going to talk about something different for the Unity runtime.

Introducing content directories

Content directories are a foundational, more-performant, more-granular replacement for AssetBundles. They are available today in Unity 6.6 as an alternative for AssetBundles shipped with the Player. During the Unity 7 generation, the tech stack will expand to handle full, granular over-the-air delivery (more on this later - it’s very cool).

Rather than baking assets into large loadable units, content directories provide the Unity runtime with the ability to independently identify, load, and unload individual artifacts (meshes, textures, etc.) with full saturation of hardware resources and implicit content deduplication.

Diagram showing how Unity assets are loaded from local storage into working memory. On the left, a "Local storage" panel contains nine Unity asset icons (3D meshes, sprite atlases, audio clips, and prefabs). An arrow labeled "Load individually" points right to a "Working memory" panel containing only three of those assets, with empty space below labeled "Available for other work." Beneath the arrow, a subtitle reads "Load → use → release."

Managing content in Unity projects is now easier than ever, with faster builds and fewer concerns about asset colocation and AssetBundle layouts.

The games you build are smaller, faster, implicitly deduplicating, and get access to full dynamic memory management via a new loadable reference type. For folks using Addressables for content bundled with the Player, you can switch to content directories with zero-code changes.

How did we make this happen? Let’s take a look under the hood of each stage of the pipeline.

A familiar foundation: Build

Back in 2019, we were having a discussion about what we’d want from a serious build foundation in Unity - parallel across every core, deterministic, fully cached, and able to share its build data between machines. Well, it turns out some of our colleagues had been shipping an API with exactly those properties for years, the asset import framework.

So, the content directory build process runs within the standard asset importer framework. Each asset is built individually by an asset importer, sandboxed and out-of-process. Builds are deterministic, with asset database caching, full saturation of all hardware cores, and native accelerator support for fast shared builds.

This may not be the first time you’ve heard about this build system. Some of you may remember the multi-process build pipeline we teased in Unity 2023.1. This is the same foundation.

Diagram showing how source files are converted into Unity assets via the Build Importer. Two FBX files each produce two AssetBundle objects (shown as blue and grey package icons), while two PNG files each produce a single sprite/texture asset (shown as checkerboard square icons). The branching arrows from the FBX files illustrate that a single 3D source file can generate multiple runtime assets.

The output is a loose group of highly granular artifacts, a small manifest tracking dependencies between them, and a new set of diagnostic files to make it easier than ever to understand your build.

It is incredibly simple.

A familiar foundation: Addressing

If you open a content directory build and take a look at the artifacts, you’ll notice that each artifact has a pretty odd hashed name:

c0152db4dd710be51b2decb997325f34.cf f0a44ad4a4babd121543fd44032928e7.resS 4226b5c16a50dab6eff0f08dd1253d4b.resource

Here’s what’s cool - that’s not a random hash. Instead, the content directory system uses the same content addressed storage pattern used by technologies like git. Each content-file is named and referenced by a hash of its contents. This pattern is incredibly useful to the Unity runtime because it allows it to implicitly deduplicate content as a native feature.

That being said, content-addressed storage with a true dependency graph risks high churn. Consider the simplest possible relationship between two artifacts:

A → B

Update B, and B's hash changes. Unfortunately, because A references B, A’s hash changes too. Even worse, that cascades right up the chain.

Instead, artifacts don't reference each other by content hash, they reference via stable id. The build manifest keeps a small lookup table mapping stable ids to content hashes.

With this, the runtime has everything it needs to load!

A familiar foundation: Load

In content directories, we introduce an incredibly performant dynamic loading system.

When a content directory is mounted, the loading system reads the manifest and resolves the stable id dependencies between artifacts. It lets each artifact be loaded and unloaded entirely independently, with zero pollution from co-located artifacts (remember that problem with AssetBundles - one monolithic, indivisible unit? Gone.)

To DOTS users, the underlying file-format of artifacts might also look pretty familiar. Content directories produce and load the next generation of the content file format that we introduced in DOTS in 2022, bringing the tech that's powered multi-threaded Entities loading for four years to all assets.

This is a loading system that is fully asynchronous across both read and deserialize operations. This means higher loading bandwidth and utilization of platform specific async read APIs.

Diagram comparing two Unity asset loading pipelines. The top section, labeled "AssetBundles," shows a serialized file processed sequentially: each asset goes through Read then Deserialize one at a time before a final Awake step, with GPU uploads happening only at the end. This is labeled "Sequential." The bottom section, labeled "Content directories," shows a content file using a jobified pipeline: all assets are read in parallel first, then each asset's Deserialize and Awake steps are staggered and overlapped, with GPU uploads distributed throughout. This is labeled "Jobified," illustrating the performance advantage of parallelized loading over the sequential AssetBundle approach.

Even more excitingly, the content directory foundation allows us to bring a modern loadable reference type to Unity for the first time, called Loadable<T>.

Loadable<Mesh> bodyMesh; bodyMesh.Load();

This is a real loadable-reference, built directly into the engine for content-directory based projects. Objects referenced by Loadables will be pulled into the build, but won’t be loaded until you invoke the Loadable. Coupling Loadables with the (very) familiar ScriptableObject interface allows you to organize dynamically loaded content incredibly quickly.

That's a principle that we are very excited about. With content directories and Loadables as the foundation, any asset in Unity can become an independently loaded and unloaded unit - a capability built directly into the engine - from the pieces of a character creator through to the chunks of a streamed terrain, with no AssetBundle layouts or group definitions to design around.

Building games at scale in Unity has never been easier!

Putting content directories to the test: Slime Rancher 2

Over the past few months, a few of our partners have been kind enough to let us test content directories with their games.

As an example, let’s take a look at Monomi Park's excellent game Slime Rancher 2, and some of the benefits it receives from switching to content directories. (Slime Rancher is available on Steam! Slime Rancher, Slime Rancher 2)

Incremental build time