Search Unity

Best Practices for SpriteAtlas assets?

Discussion in 'Addressables' started by Patrick_PS, Feb 25, 2020.

  1. Patrick_PS

    Patrick_PS

    Joined:
    Sep 9, 2019
    Posts:
    154
    After running into issues with the Legacy Sprite Packer, I am testing the new SpriteAtlas asset and have a few questions:
    - Do the SpriteAtlas assets need to be marked as addressables?
    - If yes, do the contained sprites need to be in the same group/bundle than the SpriteAtlas?
    - What happens sprites contained in a SpriteAtlas are located in different addressable groups?

    Has anyone used addressables and sprite atlases together and have a dew tips to share?

    edit: I tried disabling the sprite packer and it did not lead to an increase of batches as expected but a lot of sprites were deformed or swapped with other sprites.

    edit 2: Does the addressable system remove the single sprites that are in an atlas or will I have duplicated assets?
     
    Last edited: Feb 25, 2020
    HQF, MFG-jkhoo and IggyZuk like this.
  2. Patrick_PS

    Patrick_PS

    Joined:
    Sep 9, 2019
    Posts:
    154
  3. unity_bill

    unity_bill

    Joined:
    Apr 11, 2017
    Posts:
    1,053
    that depends on how you are using it. if it's just a dependency of something else, no, if you want to load it via addressables, yes.

    do not include both. By marking a sprite and spriteatlas as addressable, you end up with your source texture and your atlas texture in the build. We actually have a check in the analyze rules for this. "Check Sprite Atlas to Addressable Duplicate Dependencies" https://docs.unity3d.com/Packages/com.unity.addressables@1.6/manual/AddressableAssetsAnalyze.html


    not sure I understand the question. To be clear, marking a sprite atlas as addressable will put that atlas in a bundle. "that atlas" means the unity object and the generated texture.

    hope that helps.
     
  4. Patrick_PS

    Patrick_PS

    Joined:
    Sep 9, 2019
    Posts:
    154
    Thanks for answering.

    I currently have the sprite atlas assets marked as addressable but I am planning to change that because I do not need to load them directly but I want to be able to load some of the sprites they contain manually.

    The analyze rule you mention currently reports a lot of the sprites as duplicates, saying they are also used in scenes that I marked as addressable. As I said I plan to make the atlases themselves not addressable so I will see if that persists.

    What I meant with the third question is: If two sprites from the same atlas are addressable and in different groups, will the atlas be duplicated and added to both groups? (lets say that the atlas itself is not addressable)

    In the same vein: If an atlas sprite is used in an addressable scene (direct reference) and is addressable itself (to be loaded in the code) and the sprite and scene are in different groups, will there be issues?

    Also some of my atlases are currently loaded twice says the memory profiler. I am I correct to assume that this is due to some of the atlas sprites being used in prefabs located in the Resources folder?
     
  5. Patrick_PS

    Patrick_PS

    Joined:
    Sep 9, 2019
    Posts:
    154
    So I have no direct references to my sprite atlases anywhere but the "check duplicate bundle dependencies" rule keeps insisting on making some of them addressables as well as a good part of their content. From what I have gathered in the forums this will lead to duplicated assets in the bundles, so why does the rule want me to do that?
     
  6. Patrick_PS

    Patrick_PS

    Joined:
    Sep 9, 2019
    Posts:
    154
    So I decided to test 3 different scenarios:
    1) atlas sprites are addressable but not the atlases
    2) both atlas sprites and atlases are addressable
    3) atlases are addressable but not the atlas sprites

    I made the test with Unity 2018.4.18, addressables 1.6.2, using the SpriteAtlas assets (not the Sprite Packer).

    Here I wrote down memory usage (total reserved) for the 3 scenarios:
    atlas_test.JPG

    I could make several observations:
    - there is almost no impact on ios
    - the (only) memory category that was impacted was Mono. This confirms my assumption (here) that the addressables system messes with heap memory allocation.
     
  7. HQF

    HQF

    Joined:
    Aug 28, 2015
    Posts:
    40
    bump.
    SpriteAtlas - NOT adresable
    sprites in atlas - NOT adresables

    but if i build my adresabbles group that links to sprites in sprite atlas - will sprites packed in to this group?
    Because looks like adresable group have link to asset that not in addresable group and by dependency its sprite need to be packed in group too, but sprite in sprite atlas... so sprite atlas gonna be packed to group too?
    [Sprite] - not adresable

    [SpriteAtlas [Sprite]] - not adresable

    [Scene with linked [Sprite]] - adresable

    [Asset bundle as DLC [??????]] - would it include Sprite or SpriteAtlas or nothing?
     
  8. Patrick_PS

    Patrick_PS

    Joined:
    Sep 9, 2019
    Posts:
    154
    The addressables system automatically adds dependencies (in this case the sprites) into the bundles.

    Because said sprites are in a sprite atlas it will also add the sprite atlas to the bundle but not 'remove' the sprite. This means you will have both the individual sprite and the sprite atlas in a bundle.

    Furthermore if assets from different groups/bundles reference a sprite in the same sprite atlas, said sprite atlas will be added to each bundle.

    My recommendation is to make the sprite atlases addressable and put them in a separate group. If you need to make a sprite addressable then remove it from the the sprite atlas. This will help avoid inflating the build size with duplicated assets as well as memory usage by not loading the same sprite atlas several times.

    Sadly I can not give you any suggestion on how to handle this with when making a DLC.
     
  9. chrismarch

    chrismarch

    Joined:
    Jul 24, 2013
    Posts:
    472
    EDIT: This was removed in verions 1.16 " Removed Analyze Rule "Check Sprite Atlas To...". This check was not actually valid. See "SpriteAtlas dependencies" section of "Memory Management" page in Addressables documentation for more information."
    https://docs.unity3d.com/Packages/com.unity.addressables@1.16/manual/MemoryManagement.html

    So, from reading this, it seems fine to address the individual sprite textures, pack them in an atlas, without addressing the atlas, and expect only the atlas texture to load at runtime. This seems to agree with what we are seeing on iOS with 2019.4.10f1
     
    Last edited: Oct 7, 2020
  10. firstuser

    firstuser

    Joined:
    May 5, 2016
    Posts:
    147
    A warning in case someone runs into this:

    I've had an annoying, ongoing, and VERY difficult to reproduce issue with Sprite Atlas (v1) and addressables. I don't have my sprite atlas marked as addressable but when addressables unload an unrelated scene sometimes the sprite atlas glitches and all the sprites are either white or have the wrong part of the sprite atlas showing.

    The only workaround has been to avoid using any sprite atlas entirely when using addressables :(