Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
  3. Join us on November 16th, 2023, between 1 pm and 9 pm CET for Ask the Experts Online on Discord and on Unity Discussions.
    Dismiss Notice

Sprites, mip-maping, texture quality and optimization

Discussion in 'General Graphics' started by Aldwin, May 30, 2015.

  1. Aldwin

    Aldwin

    Joined:
    Feb 18, 2013
    Posts:
    12
    Hi guys,

    I'm finishing a small mobile 2D game, using the new Unity 5 sprite system. I'm in the optimization part and specifically on a graphics focus : my game is very small and simple but it's running around 30 fps on my Galaxy Nexus phone and when I watch the profiler, 80% of the ressources are used by the graphics.

    I use atlas packing (with Unity Sprite Packer) and my batches are mostly around 20-30 (some 40-50 spikes).

    So, here are my questions :

    1. As we first did the texture for an iPad Retina (2048x1536px), each images are quite bigs. So, my first attempt was to lower the Texture Quality to half and even quarter in the Quality settings panel. But it seamed it didn't change anything, neither visually or in terms of performances in the profiler. Then, I found out that reactivating mip-maping on texture import parameters (I deactivated it because I read it's useless for sprites), the textures were finally impacted visually and my performances increased a lot (around the expected 60 FPS) --> so, my question is what's the link between mip-maping activation and texture quality ? Obviously there's one but I never saw it mentioned anywhere...

    2. About the Texture Quality parameter, is it supposed to reduce the texture size inside the build (and so the size of the atlas generated by the sprite packer) or just the texture displayed in the game ?

    3. If the Texture Quality only affects the size of the texture displayed, I guess if you have a very big texture but displayed at the quarter of its size, draw performance is increased but not loading performance, am I right ?

    4. Still considering the Texture Quality only affects the texture displayed (but the "original" texture file is still the same), is there a way to dynamically change this parameter at the start of the application (to adapt to the target device's resolution) ?

    5. My last question is about UI : even with the Texture Quality set to quarter, my gameplay is running around 60 FPS but I go back around 30 FPS when the UI is activated. Is the new Unity UI system expensive for mobile or am I doing something wrong (I mainly scale and sometimes rotate UI images) ?

    Thanks for your help guys, and sorry if the questions were already asked and for my english.

    Yoann
     
    theANMATOR2b likes this.
  2. echo4papa

    echo4papa

    Joined:
    Mar 26, 2015
    Posts:
    158
    Yes, the MIP chain store progressively smaller textures which are sampled based on depth. It's so that never use a texture larger than what will be displayed per-pixel on the screen. For 3D objects it increases both performance and quality. Mipmaps could be useless for sprites if their depth never changed.

    Yes: http://docs.unity3d.com/ScriptReference/QualitySettings.html

    You can test based on device generation or screen res if you'd like.
     
    theANMATOR2b likes this.
  3. Aldwin

    Aldwin

    Joined:
    Feb 18, 2013
    Posts:
    12
    Thanks for you answers echo2papa.

    Reading the script reference for QualitySetting class, I found more precise answer to my first question in the masterTextureLimit member descritipion :

    (http://docs.unity3d.com/ScriptReference/QualitySettings-masterTextureLimit.html)

    So, it seems the Texture Quality setting just force the use of one mipmap, and I guess mimaps need to be generated and are in the build too. So I guess i's somehow answering my questions 1 to 4 :)

    Then it brings another more general question :

    What's the better way to deal with texture sizes for various mobile devices ? I see two main solutions :
    - Have HD textures for the "biggest" resolutions and use quality settings to lower the ones displayed relating to the device resolution (but the build size should be bigger with the different mipmap textures).
    - Have average quality textures for all devices (but it should be quite blurry/pixelated on very HD ones and maybe quite slow on very old ones).

    What do you think guys ? Did I miss another methods ?

    Thanks for your time and help.
     
  4. echo4papa

    echo4papa

    Joined:
    Mar 26, 2015
    Posts:
    158
    Personally I like your first choice. Keep the largest size and then step down based on device. I like to try dial in image size in the import settings per platform first, though, for best quality/performance(especially when it comes to memory and iOS) and then use the quality settings to step down based on specific device families.
     
    theANMATOR2b likes this.
  5. soaring

    soaring

    Joined:
    Jun 22, 2015
    Posts:
    27
    @echo4papa @AldwinWe are now looking at using Unity to build a 2D game, and are trying to figure out the best way to handle the different resolution devices. We are actively exploring this option that you took. Can you confirm if this approach ended up working for you? Specifically:

    - Where you able to set the qualitySetting at run time based on the device resolution, and still maintain sharp rendering, and keep the FPS up?

    Based on the research we have done, it appears that the quality setting uses mipmap. Our concern is what is the impact of that on texture memory usage. For example, let's say I have a sprite atlas thats 4k x 4k. I would like it to be downsized to 1k x 1k on a device with lower resolution (which presumably means the device also has less texture memory). I am concerned that MipMap will load the entire 4k sheet into texture memory, then generate the 2k & 1k versions of the sheet AND store those in memory. All of a sudden, this low end device's texture memory is completely used up, and our app dies...

    Many thanks for your time & help!