What is Asset Database v2

Unity Engine
1

What is asset database v2 and what improvements, features, changes, etc are contained?

I cant find any info on it anywhere and it sounds like it could be anything from an amazing rewrite of the underlying asset system and how everything imports (which would naturally get the reaction of OMFG), all the way to just a simple api refactor (yawn)

2

Asset Database v2 landed as experimental in 2019.2 beta. You can take a look at the description here: Asset Pipeline Version 2?

3

Some info here:

1 Like
4

more details will come soon (documentation + benefits)

6 Likes
5

Any more details, please?

6

We have some more in depth documentation coming, but right now we’ve just released a blog post about the new Asset Import Pipeline: Unity Blog

2 Likes
7

Thanks, although it seems its mostly for people who pay for some sort of service? So essentially this is pay to speed up your import times?

If not then please excuse me, but the talk about unity accelerator within the blog post makes me think this is essentially pay for a speed boost.

8

Hey @MadeFromPolygons_1 , the Accelerator can be hosted locally on a machine you already own: Unity - Manual: Unity Accelerator

In that page there is some setup info on how you can Download it for your preferred OS:

Setup
If you do not have Unity Teams Advanced, you can download and install Unity Accelerator directly and uncheck the registration token during installation:

Then other work stations can connect to it and reap the benefits.

9

I hope this new version includes the ability to bundle assets at runtime; I still don’t understand how we don’t have this ability to this day, it’s as if dynamic asset generation is frowned upon.

10

It used to be called cache server, same thing

11

@Unity_Javier , I’ve run into a regression with AssetDatabase V2 that’s been around since the start. I’ve reported a bug (1378230), but I’m wondering if this is a fundamental change to how things work that I need to work around on a permanent bases. Sorry for pinging you, but I really don’t know where else to ask about this.

Here’s a very simplified version of the issue, from an editor script:

[InitializeOnLoadMethod]
private static void SimplifiedExample() {
    var asset = AssetDatabase.LoadAssetAtPath<AssetType>("Assets/Asset0.asset");
    Debug.Log(asset == null);
}

Since the method is marked with InitializeOnLoadMethod, it runs (among other times) during startup of the project.

If the file Asset0 has been changed externally when Unity was closed, the asset return by LoadAssetAtPath will be null in V2 when the project is opened again. In V1 (confirmed by checking Unity 2018 and 2019 with V1), the asset will be loaded correctly.

I assume what’s happening here is that due to some asynchronous stuff, the file isn’t ready yet when you load the code. You might also have made a change to deal with the possibility of updated importer versions.

Anyway, what I’m wondering is:

  • Is this likely to get fixed, or do I need a permanent solution?
  • If it’s not likely to get fixed, is there some other entry point I can use to load assets needed for edit mode things?
12

Answer I got ~1.5 years ago from support:

13

Hi @Baste ,

To answer your questions directly:
Short term - hook into EditorApplication.Update EditorApplication.delayCall inside your InitializeOnLoad code.
Medium & Long term - You can safely use the new variant of OnPostProcessAllAssets which @volblob73 added recently: Unity - Scripting API: AssetPostprocessor.OnPostprocessAllAssets(string[] importedAssets, string[] deletedAssets, string[] movedAssets, string[] movedFromAssetPaths, bool didDomainReload) as this issue is present in many places (bug link: Unity Issue Tracker - Calling LoadAssetAtPath during DomainReload returns null asset if asset is in modification list as well as a script)

Now, I want to explain why AssetDatabase V2 returns null and ABDV1 does not.

The issue at hand here is consistency. In the scenario you describe, InitializeOnLoadMethod gets called when the editor is booting up. This is analogous to:

  1. Modifying a C# script
  2. Modifying an asset
  3. Calling refresh so both changes are picked up.

So, if we do try that out using ADBV1, in 2018.3, I can show you the biggest problem.

In this case, I have a texture (test_texture.png) and its dimensions are 256x128 pixels
If I:

  1. Modify a C# script
  2. Change the Dimensions to be something else (i.e. 256x256)
  3. Let Auto-Refresh run

You can see that inside the InitalizeOnLoad call, the dimensions get printed and they’re not what’s on disk!!!

This is because the asset has not been imported yet, and so the last known version of the asset is what ends up getting loaded. This can cause a large number of issues, since you’re essentially getting out-of-date data back.

In ADBV2 we make sure to return NULL as a way to tell you that the asset is not available and we know its modified, thus preventing out of date data from being returned until it has been imported.

This is definitely a behaviour change, but for the sake of consistency we chose to do this when ABDV2 was designed.

I’ve attached a little GIF showing this off in 2018.3

8380110--1104963--out_of_sync_data.gif

3 Likes
14

Hi!

Thanks a lot for all the details! Consistent behavior is a lot better than not consistent :stuck_out_tongue:

So, follow-up questions:

This should be equivalent to EditorApplication.delayCall, right? I’ve generally just used delayCall as a generic “EditorApplication.update, but only once”, but I’m not 100% sure if that’s actually what I’m getting. Using a delayCall is what I ended up doing in this instance (2020 LTS), and it seems to be working right.

This means that OnPostProcessAllAssets with the bool didDomainReload parameter is run after asset imports are done? That wasn’t quite clear from the details.

I’m not quite sure if it’s a good fit, though. Does it get run on editor boot with no assets changed? I’m using [InitializeOnLoad] to boot an in-editor cache of some assets and some metadata about those assets, so I need to make sure it’s updated whenever 1) Unity boots, 2) the in-memory cache gets killed by a domain reload, or 3) assets of that type gets changed.

  1. and 2) is solved quite well by [InitializeOnLoad]. I tried using only OnPostProcessAllAssets for 3), but that only fires when users save, but they usually don’t hit ctrl+s for every operation they do that affects these assets, so I have to manually update the cache from the editor.

If OnPostProcessAllAssets gets called both for boot and domain reload (with what paths?), I can use that for 1) and 2). Otherwise I’ll just stick with the short term solution for the long term :stuck_out_tongue:

Finally, you should probably update the documentation for 2020 and 2019! The 2021 docs has this info, but 2020 and 2019 should probably get a “don’t do this” note.

Again, thanks a lot for the details!

15

Whoops! Yes, definitely use EditorApplication.delayCall I’ll correct my initial recommendation. Sorry about that!

It will be invoked once all imports have completed, and it’ll let you know if during this import the domain was reloaded (or not).

This variant of OnPostProcessAllAssets will be called:

  1. When assets import
  2. After a domain was reloaded
  3. When you boot up the editor
    So, its covers all 3 scenarios you described :slight_smile: I just checked that it gets called on Editor boot.

Updating old API docs is definitely not a trivial thing to do (which shouldn’t be the case right!?!)! But let me see, since I did try asking about getting the manual updated for some other stuff some months ago too!

1 Like
16

Yeah we’ve noticed! There was a lot of talk a few years ago about upscaling the docs team so the documentation situation would improve, but to the end users, it seems like the only thing that got upscaled was the amount of red tape…

Anyway, great info. I’ll switch over our code once we transition to 2021.