What is Asset Database v2

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)

 

Some info here:
https://forum.unity.com/threads/asset-pipeline-version-2.679366/#post-4548685

 

Any more details, please?

 

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.

 

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.

 

It used to be called cache server, same thing

 

@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:

Code (csharp):

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

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?

 

Answer I got ~1.5 years ago from support:

 

Hi!

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

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


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!

 

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.