Texture2Ds with no Native Object Name

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.

 

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.

 

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.

 

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.

 

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

 

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