Search Unity

Texture2Ds with no Native Object Name

Discussion in 'Profiler Previews' started by gecko, Oct 13, 2020.

  1. gecko

    gecko

    Joined:
    Aug 10, 2006
    Posts:
    2,176
    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!
     
  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,558
    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.
     
    anonymous-vae likes this.
  3. gecko

    gecko

    Joined:
    Aug 10, 2006
    Posts:
    2,176
    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)....
     
  4. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,558
    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.
     
  5. gecko

    gecko

    Joined:
    Aug 10, 2006
    Posts:
    2,176
    I'm still seeing these after upgrading to 0.2.6, though most have RefCount of zero....are those using memory or not?

    upload_2020-12-20_15-54-10.png
     
  6. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,558
    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.
     
    anonymous-vae likes this.
  7. gecko

    gecko

    Joined:
    Aug 10, 2006
    Posts:
    2,176
    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.
     
  8. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,558
    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.
     
  9. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,040
    Unless it ships the code in the form of a DLL.
     
  10. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,558
    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
     
  11. gecko

    gecko

    Joined:
    Aug 10, 2006
    Posts:
    2,176
  12. anonymous-vae

    anonymous-vae

    Joined:
    Jul 12, 2019
    Posts:
    1
    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!
     
    MartinTilo likes this.
  13. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,558
    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
     
    Last edited: Oct 22, 2021 at 10:57 AM
unityunity