New Asset Import Pipeline

The new Asset Import Pipeline is available with Unity 2019.3. If you have an existing project, you can upgrade to the new Asset Import Pipeline using the Project Settings Window in the Editor:

Selecting Version 2 will tell the editor you now want to use the new Asset Import Pipeline together with this project, and restarting your project will re-import it using the new Asset Import Pipeline code. This essentially has the same effect as deleting your Library folder, but without deleting it. When switching to use Asset Import Pipeline V2, the Import Results from the original Asset Import Pipeline are not deleted as V2 creates its own folder structure to store its Import Results.

Projects that you’ve created in Unity 2019.2 or older will still use their original Asset Import Pipeline by default. When opening such a project in Unity 2019.3 for the first time, you’ll get an option to upgrade to the new Asset Import Pipeline. If you decline, your project will continue using the original Asset Import Pipeline. Furthermore, the selected version is stored in the EditorSettings.asset file of your project, so it can be version controlled.

New Projects created with the new Asset Import Pipeline

When creating a new Project with Unity 2019.3 or newer, the new Asset Import Pipeline has become the new default way to work. All new projects you create will be using it.

Behaviour changes to the New Asset Import Pipeline 

Multiple versions of the same asset are cached in the Library folder

Up until Unity 2019.2 (with the original Asset Import Pipeline), the Library folder was comprised of the GUIDs of Assets being their filename. Thus, switching from a platform to another platform would invalidate the Import Result in the Library folder, causing it to be re-imported every time you switch platforms.

Asset Import Pipeline V1

If you had to switch back and forth between platforms multiple times per day, this could easily take up hours, depending on your project size.

Some of you have figured out workarounds for this, such as having a copy of your project per platform on your machine, but that doesn’t scale very well.

With the new Asset Import Pipeline, we’ve removed the GUID to File Name mapping. Since dependencies for a particular Asset are tracked, we are able to Hash them all together to create a revision for the Import Result of an Asset. This allows us to have multiple revisions per Asset, which then means that we are no longer bound by a GUID to File Name mapping. Not having this requirement allows us to have Import Results which work across different configurations. For Fast Platform Switching, we could have an Import Result per platform, so that when you switch platforms back and forth the Import Result is already there, thus making the platform switch many orders of magnitude faster than with the Asset Import Pipeline V1.

Asset Import Pipeline V2

Caching and the Unity Accelerator

Most of the importers have had significant work done to them in order to improve their determinsm and have a positive effect on caching. This means that if the Unity Accelerator is used, the import result will be uploaded to a centralized storage where other machines can connect to and benefit from the work done for the same Asset on a different machine. Assets with dynamic dependencies can be cached now (e.g. nested prefabs, shaders, etc.). For a more comprehensive list of Importers and their associated files, check out the new AssetDatabase Manual page

Caching of Scripted Importers:

ScriptedImporters and importers with registered dependencies were not cached with the old Asset Import Pipeline.

Old Behaviour

With the old Asset Import Pipeline, the switching of platforms invalidated all imports as the Import Result was GUID based, thus switching a platform would overwrite the import result every time.

New Behaviour

In the new Asset Import Pipeline, switching platforms does not invalidate imports as the File on disk representing the import result is a hash of its own contents, thus ensuring that when switching platform the contents are different and result in a new file, thus keeping both versions of the Import Result around and simply switching between one or another, without having to import anything.

Number of Calls to OnPostProcessAllAssets:

In the old Asset Import Pipeline, the number of calls to the OnPostProcessAllAssets function was non-deterministic. Meaning that this function could be called once, or multiple times, for the same changes. With the new Asset Import Pipeline, there will be a single call to OnPostProcessAllAssets for detected Script changes (.cs files), and one for non-script changes (think .png, .fbx, .wav files). 

Synchronous Script Compilation:

In the old Asset Import Pipeline, one could trigger a compilation and chain going into play mode while a compilation was happening. This was a big time saver in certain situations, having non-synchronous compilation could lead to non-deterministic results. With the new Asset Import Pipeline, this has been changed so that the Asset Import Pipeline drives the majority of Script Compilation, and as such it requires a deterministic approach, thus locking up the editor until Script Compilation completes.