Texture2Ds with no Native Object Name

Is there any way to identify Texture2Ds listed in the Memory Profiler that are blank for Native Object Name? I have several that are 21mb and would sure like to know what those are in case I can reduce them. It’s puzzling that they have no name, and also that, for some of them, their RefCount is zero.

thx!

Hi,
Do these appear while capturing playmode and are you using 0.2.6-preview.1? Because there was a leak of unnamed Textures originating in the Memory Profiler UI in earlier versions, as discussed here , where I’ve also gone a bit more into the issue of unnamed Textures.

In short: If you create textures on the fly (i.e. not loading from file but maybe from the web or creating them newly in c#) you can assign a name to it via it’s .name property.

Beyond that, you can try to figure out where a texture came from by going through the Objects that reference them by licking on the Ref count. If that Ref count is 0, this texture is about to be unloaded with the next Resources.UnloadUnusedAssets.

1 Like

I was using 0.2.4 preview, capturing a build from the editor. So I’ll upgrade to 0.2.6 and try it again. Thanks!

Also, is there a way to identify what game objects are using a texture2D or mesh or whatever? You mention “going through the objects that reference them” but I’m not sure what that means/how to do it (if indeed it’s even possible)…

The tables have a column called Ref Count. Any Object that is referenced by another object will have a number bigger than 0 in blue, i.e. Link-Text. Clicking that number will open the list of objects with a reference to the object you just came from. These objects could have further objects referencing them so you can step through these lists to build some context understand around that bit of memory, including what GameObjects are associated with it. We’ll eventually release a paths-to-roots view to make this process less tedious and easier to understand.

I’m still seeing these after upgrading to 0.2.6, though most have RefCount of zero…are those using memory or not?

Yes they are. Calling Resources.UnlodUnusedObjects or a non-additive scene load will free their memory. For the ones with references to them, click on their RefCount value to see what’s holding them in memory. Also find all usages of Texture2D in your code and make sure you are setting the .name property on all of them to something sensible that will help you understand where they came from.

Since all of them have negativ instances IDs these have been created from code rather than loaded in from disk, so they have no file name to use as their name by default.

1 Like

Thanks for the quick help, I really appreciate it! Do you have any tips on how to find out more about those code-generated texture2Ds? We’re guessing it’s an asset store tool that is generating them… I’ve tried drilling down in the Memory Profiler snapshot but don’t seem to end up anywhere.

Even an asset store tool stores all relevant code in your project, so you can open your Project in your Coding IDE of choice and search for all creations of Texture2D objects and make sure that in all places, it is followed by assigning a reasonably identifying name to it’s .name property. Beyond that there is not much the memory Profiler can do to help if there are no references pointing to it. At least at this stage. Eventually we’ll implement Callstacks to go long with all Allocations to make it easier to track their origins, but that is still a ways out.

Unless it ships the code in the form of a DLL.

Oh right. Forgot some are doing that. Well in that case it leaves you to make a copy of your Project and take out these kinds of additions until the textures are gone, and then report a bug to the creator that they should fix their leaking of textures and should give them names

So we’re wondering if most of these unnamed Texture2Ds are actually the terrain normals, generated when terrain instancing is enabled. I posted about it Terrain instancing creates 10mb Texture2Ds in memory? – but hoping that maybe @MartinTilo might know or be able to find out?

You saved my life! My project has an insane 40G of memory usage when running, but just calling Resources.UnloadUnusedAssets() after each iteration of a loop, reduce it to 9G, really helpful!

1 Like

Glad the information was able to help you. Something to keep in mind when triggering the Asset GC e.g. via Resources.UnloadUnusedAssets() or scene unloading is that the Asset GC process can take a while to complete. So this is not something you’ll want to be doing too much of during runtime.

It might be worth finding out if there is any place where you are repeatedly creating these runtime created assets (e.g. Textures, Materials, etc…) that you then leave lying around for the Asset GC to collect. If you find that source, manually cleaning these objects up before you loose your reference to them with an Object.Destroy() call means your memory usage won’t continuously rise so you won’t need to call Resources.UnloadUnusedAssets() or at least not as often. This will save you that expensive call and make your memory usage more predictable