Official Import Activity Window (2021.2.0a19 and up)

It looks super interesting, but we're not in a position to try to update a big project that would need it right now.

 

Looks amazing to be honest

 

Would it possible to have this as a package, and use it in older (LTS) releases? Because this looks like a life saver.

 

Hello. I have some feedback.

Would be nice to copy asset info fields (like GUID, Path, etc).
Also, need more info about Duration 23 ms (-50%). It is not clear where this -50 % came from.
I didn't find the option to hide Editor Assets from the Import Activity assets list.

 

Thanks for the reply.
Yes. I want to only see assets under the “Assets/“ folder.

 

The reason is the most interesting part to me. Once the project reimported everything after we updated TextMeshPro package. Would've been interesting to see why Editor decided to do that.

 

Makes sense, Possibly either had one and got removed or added one. It shouldn't have reimported everything, but I guess that's a limitation of the meta-data kept for imported assets to avoid reimporting them.

 

Is this information accessible via editor scripting API too?

 

Hi Javier, no offense to you directly, but Unity has along history of putting out cool tools that don't scale well and are super non performant.

Can you set this up in a way that it doesn't take forever to load the screen, handles 120,000 assets gracefully (NO MASSIVE SCROLL BARS), doesn't memory alloc the entire application to death and repaints efficiently?

 

I'd organize it by folder, at least when ordering by name.

Using UI Toolkit for everything (not just *some* things) and virtualizing the asset list should do it. Hell, it seems that most leaf nodes in this window are `IMGUIContainer`s. There should be misleading advertisement penalties for companies that don't use their own products.

 

IMGUIContainer

is a unity "product"...

 

Is that a joke that I don't get? The quotes make it seem so.

 

No joke. There is no meaning behind what you said. They are using a unity made tool on a way they intended it. IMGUIContainer is a tool in a big, complex set of tools which allows us (and them) to use code made a while ago play along with the new system while everyone rewrite their systems to use the new one. It's software engineering 101. You don't migrate everything at once, especially not in a complex software like unity. But you already know all of this, why do I have to spell this out?

 

UI Elements was added as experimental in 2017.1 and released in 2019.1, it seems. If they've updated their Mono fork in a few months, they can rewrite the Console window with UI Toolkit in 2 years. Different teams, but you get the idea. Console, Project, Hierarchy, Game, Lighting... all still pure IMGUI. The longer they keep piling changes up on the old codebase, the worse an eventual rewrite gets.

I'm sure that you get the sentiment: Acme releases this product that's gonna fix everything and it's utterly broken because they haven't felt the pain of using it for any serious project.

 

Hi @Unity_Javier ,
this new feature looks great. I could not try it out yet but I am curious to ask the following:
Does the Import Activity Window highlight any activity that is related to Unity Accelerator (upload to, download from, etc.)? It would be a great benefit once we upgrade our project to stable 2021.2 in the future.

 

Hi Javier, some more feedback after trying this out:

- some filenames (e.g. all package.json imports) are truncated in the middle, and only show the path on hover. There's more than enough space.



- especially the dependencies list could benefit from another splitter, there's tons of space and a tiny window to scroll through them right now



- would be great if "SourceAsset/MetaFileHash/xxx", "SourceAsset/HashOfSourceAssetByGUID/xxx" and the actual source asset would be grouped (or these typical things in a foldout) - hard to see what belongs to what otherwise

- right now it seems the _actual_ import time isn't visible, e.g. when you have URP in the project there's
- "Decal.shadergraph" which takes 130ms and has 195 dependencies
- "SpeedTree8_PBRLit.shadergraph" which takes 7120 (!) ms and has 222 dependencies
I can only assume the bulk of that import time is the shader compilation but I'm not sure.
A similar issue for e.g. "Mono.Cecil.Pdb.dll" (1885ms) and "Newtonsoft.Json.dll" (1033ms) where I can't actually see the reason why these take so long – if it's possible to show more there that would be great.

- for Custom Dependencies it would be great if their current value and the value on import would be visible


Otherwise I agree with other voices here that performance would probably benefit from VisualElements, and that some hierarchical view would be great as well. Thanks for a great tool, please keep improving it

 

Hey @Unity_Javier. This is looking awesome. I remember at the start of this year debugging some frequent asset reimports with you, and this looks like it'll be amazing for it. Can't wait until the 2021 LTS release comes and we can upgrade our projects for this!

 

Hey @Unity_Javier , with the 2021 LTS release earlier today, we've started the process of upgrading our projects. I'm definitely looking forward to digging deep into the remaining few assets that get frequent reimports at seemingly unrelated times.

One quick question I have, with the dependency list, is there an easy way to convert the various hashes into a human readable format? I'm aware of AssetDatabase.GUIDToAssetPath. In the screenshot below there is what appears to be three GUIDs, one in Dependency Name, two in Dependency Value. The one in Dependency Name matches the GUID of the asset in the field above the dependencies list. If I was to input the two dependency values into an editor script that invokes GUIDToAssetPath and outputs the value to the debug console, would I then get the asset paths of the assets that depend on the asset that was just imported?

If the answer to this is yes, a follow up question is will this functionality for easy lookup be included in a future release?

Thanks!

 

Does the Import Activity Window only cover the first iteration? Often there are issues where an asset gets stuck in "importing (iteration 2)" for minutes at a time but this doesn't seem to be reflected in the Import Activity Window so we can't debug it.

 

@Unity_Javier yeah, been a while. Just devving away.

Awesome. I should be able to make an editor script from this info that'll output in human readable form what the dependencies are, so that we can analyse if they're correct (eg, Prefab A depends on Mesh A) or incorrect (eg Prefab B depends on Mesh A due to it previously containing Mesh A, but doesn't any longer). As well as figure out if we have any objects that have interdependencies that maybe can be broken, preventing reimports when one of the dependencies changes.

Also Nyphur is a colleague of mine. The question he's asking is not so much, why is this asset being reimported multiple times (which is what I was asking), but why is an asset taking what feels like unnecessarily long to import. The duration tab is fantastic for figuring out which assets take the longest to import at a glance, but it still doesn't give much insight yet into why it's taking an FBX file say 244ms to import (eg Chicken_1.FBX in your image)

It's also unclear right now if that 244ms is the full time it takes that asset to pass through the pipeline (eg if Chicken_1.FBX is the only asset being reimported, then from when AssetDatabase.ImportAsset or AssetDatabase.RefreshAsset is invoked, to when AssetPostprocessor.OnPostprocessAllAssets is invoked), or if its only representative of what the blocking Import progress bar calls "iteration 1". As for example, in the image below this particular material has at least two import iterations.

 

Yeah, specifically I have two main issues:

• The import activity window shows me a series of materials that have been imported, and we happen to know there's a bug causing each of them to be imported 24 times in a row. When I go into the import activity window, it shows only the last import and there are no previous versions listed and no reason for import.
• As SideSwipe9th pointed out, the import duration numbers in the window don't seem to match the real time spent importing. Each one of them shows import times from 2ms to 5ms, but in reality I can see that it's only importing about 2 per second. It looks to me as if it's not counting the time spent in "Iteration 2" when importing, which is by far most of the import duration and the part we would want to diagnose.

If there are many circumstances under which the window discards previous import data, and if it can only account for iteration 1 when importing, that does limit the tool's usefulness. Are the further import iterations usually waiting on third party assets doing something, or is this still the base Unity engine?

 

It does!

The bugs Nyphur was referring to in his last post were in Digger and MicroSplat. Digger has an integration with MicroSplat that hooks into its terrain sync events. Here's a brief rundown of the bugs, both are now fixed in their respective assets.

The bug in MicroSplat was that on scene save, each MicroSplat terrain was forcing every other MicroSplat terrain to sync. This resulted in a the number of sync events being the square value of the number of Microsplat terrains in your scene; eg 4 terrains = 16 sync events.

The bug on Digger's side was that, every time MicroSplat invoked a sync event, Digger would resync itself. Because of the bug in MicroSplat, Digger would receive a number of sync events equal to the square value of the number of terrains plus the number of terrains. Eg, 4 terrains = 20 Digger syncs. As part of Digger's sync, after doing some cleanup it would subscribe a function to EditorApplication.delayCalls. That function forced the Asset Database to re-import (using ImportAssetOptions.ForceUpdate) the material variant, of the MicroSplat material, that Digger uses for each terrain it is attached to. It would do this regardless of whether there were any underlying changes to the MicroSplat material. And because EditorApplication.delayCall seems to be executed sequentially, as the number of terrains with MicroSplat and Digger in your scene increased, there would be an exponential increase in the number of assets being sequentially reimported.

When it came to the ImportActivityWindow, you've already identified that because the same asset was being reimported multiple times, and the window doesn't detect when this occurs, it would only show the results of the last of those imports. And because of this, I now understand why we'd see the same material being imported 24 times, as we had 24 terrains in our scene, each with MicroSplat and Digger, but only see a single result in the activity window.

This was a particularly frustrating bug for us and our sanity. Because of the high number of terrains, we'd see total save times (ie, time from when save is pressed to when we can interact with the editor again) in excess of five minutes, on machines that are fairly powerful; in my case a Ryzen 5900X with RTX3090. Thankfully fixed now though