Search Unity

Unity 2021 texture import optimizations

Discussion in '2021.1 Beta' started by Aras, Nov 27, 2020.

  1. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    Heads up: we've been spending some time on optimizing texture import times. Textures typically take up majority of game assets, and usually people spend a lot of time staring at progress bars, waiting for them to import or compress. While there are things like Accelerator (née Cache Server) that can alleviate that pain, it still sounded like a good idea to invest some time in.

    So! Here's what we see in our tests, in 2021.1a7, compared to 2020.2a21. The timings below are on my PC (1st gen ThreadRipper CPU with 16 threads, SSD), importing or switching platforms on a test project with 2GB worth of various textures (400 textures from actual projects; a mix of regular textures, normal maps, lightmaps, sprites, skyboxes, mask maps etc.):

    - Importing for PC platform: 141sec -> 111sec (1.3x speedup, or "30 seconds saved"),
    - Importing for Android platform (ETC compression mode): 720sec -> 266sec (2.7x speedup, or "7 minutes saved"),
    - Importing for Android platform (ASTC compression mode): 1568sec -> 602sec (2.6x speedup, or "16 minutes saved").

    Some texture types get larger speedups in the non-compression part, e.g. lat-tong panoramic layout cubemaps are much faster to import than before, because we've optimized some heavy parts there.

    Low-risk parts of the ETC optimizations (1.4x speedup) are being backported to 2020.2b13, 2020.1.15 and 2019.4.16) as we speak.

    ASTC optimizations are somewhat more involved; we haven't decided yet whether to backport them.

    We have some more plans in how to improve texture import times further, but these are likely to be after 2021.1 version (2021.1 is in "code freeze, only stability fixes" stage already).

    Hope that helps, and you all can spend less time waiting for progress bars to finish!
     
  2. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,090
    That's fantastic news. Improving texture import performance is indeed a very necessary area. Thank you!
    upload_2020-11-27_8-37-33.png
     
    Bastienre4, stuksgens, Ruchir and 3 others like this.
  3. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    818
    Thanks a lot :)
    Please think hard to backport ASTC optimisations to 2020.2 or 2020.3 at least, so we dont need to wait for it another 1.5 years :)

    And work more on it. Accelerator is good idea but it often dont work, Unity can stall on trying to get textures from Accelerator for 15-30 minutes while just import them took about 30 seconds. Very often Accelerator just return wrong cached asset and ruin work at all. So it still not very usable in real prodaction projects even for personal use on one PC.

    Thats way Thank You Very Much for your efforts :)
     
    Ruchir and valarus like this.
  4. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,086
    Nice progress, this in combination with background compression, no more editor blocking, is going to help smooth out the workflow.
    Thanks for the optimisation work!
     
  5. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    210
    Really happy to hear this.
    We have a gigantic 2D project we sent for Case 1280527 with tens of thousands of sprites and atlases. You could use that as the ultimate benchmark ;) But it needs more than 100GB disk space just to import!
     
  6. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    Small update in 2021.1a8: mobile PVRTC compression is about 8% faster.
     
  7. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    210
    By the way, I checked again: the sprite atlas packing is insanely faster in newer versions compared to older ones (2020.1?, right now I'm on 2020.2.0b14). I don't know if this was a bug that got fixed or an actual optimization in packing or just result of more higher level asset pipeline improvements like caching the older results.
     
    Aras likes this.
  8. Neonlyte

    Neonlyte

    Joined:
    Oct 17, 2013
    Posts:
    364
    I'll take that. It's been very slow to compress iOS texture at best quality. Any improvement is a big plus.

    Context: my project contains nearly 100 1024*1024 images that are displayed as UI graphics (specifically music album jackets). Because my UI displays the jackets in big sizes and because iPads have high resolution screens, I wanted to keep the visual fidelity so I used Best quality setting.
     
  9. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    Realistically though, you could switch to ETC2 (supported since A7 chips - year 2013) or ASTC (supported since A8 chips - year 2014) formats. Yes Unity today makes that a bit hard to do, since you have to either write an asset postprocessor script to assign that format automatically on iOS, or do that manually for all your textures. I think mobile team is looking at switching iOS default format to ASTC soon.
     
  10. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    8,430
    Can you make default format switchable by users so we don't have to wait for Unity teams to switch them a few years later than when we need the switch to happen?
     
    Jes28 likes this.
  11. Neonlyte

    Neonlyte

    Joined:
    Oct 17, 2013
    Posts:
    364
    Isn't iPhone 5s not supporting ASTC, but can still be updated to iOS 12? I don't think Apple gives a way to exclude devices by texture support like Google Play does, and I don't think the team is going to bump the min iOS version supported by Unity to 13, yes?

    Good suggestions on ETC2 texture, though. I'll take a look at that.

    Append:
    I tried to use ETC2 on some of my images. ETC2's visual quality is actually quite a bit(lol) better than PVRTC at best quality settings. But the I remembered that I'm still supporting OpenGL ES 2.0.

    Though, I'm dropping OpenGL for iOS soon by going straight to iOS 11 so ETC2 will come in handy.
     
    Last edited: Dec 18, 2020
  12. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    8,430
    No. You're thinking of the iPhone 5C, which goes up to iOS 10. 5S supports metal / ASTC just fine. (EDIT: Maybe not.... let me check again)

    If you want to be able to make 64bit only, Metal only builds for iOS, requiring iOS 11 and up works fine and isn't unreasonable. (EDIT: Again, maybe I'm wrong)

    EDIT: I was right about 64bit & metal, but I missed that ASTC specifically needed another generation, so you're right.
     
    Last edited: Dec 18, 2020
  13. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    Some updates:

    - In 2021.2 we'll very likely have a new BC7 format texture compressor that is 2x-3x faster than the current one, at about the same image quality. BC7 is what's used on PC/Consoles if you pick 'high quality' compression import setting. There will be an option to use the old one if someone absolutely needs it.
    - We're thinking about having some sort of "global, per user" max texture size & compression mode texture override setting, for cases where one does not care about textures that much. I've created a separate thread about this here under graphics section -- feedback welcome!
     
    valarus, mariandev, jdtec and 8 others like this.
  14. KamilDA

    KamilDA

    Joined:
    May 21, 2020
    Posts:
    201
    Apologies if it's a stupid question, but can BC7 compression be implemented for WebGL as well? Cursory research on the topic appears to point towards BC7 being technically supported. If so, then this feature sprint might help expand the WebGL platform a bit more.

    Thank you
     
  15. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    I know nothing about WebGL, IIRC at least a few years ago none of the DX10+ desktop texture formats (BC4, BC5, BC6H, BC7) were exposed there. If they are exposed today, then yeah, if our WebGL folks would implement support in Unity then that would work. I'll ask them.

    According to https://developer.mozilla.org/en-US/docs/Web/API/EXT_texture_compression_bptc browser support table though, BC7 would only work in Firefox, and none of the other browsers?
     
  16. KamilDA

    KamilDA

    Joined:
    May 21, 2020
    Posts:
    201
    You are right. Saw it in the WebGL specs, saw it implemented in Firefox but completely missed its implementation in Chrome/Edge. Ugh.

    Again, thanks for taking the time.
     
  17. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,331
    I wonder (if it is not already) worth investing into multi thread importing such as how shader compilation work now? I can see that multiple shader compiler kicks off to handle shader compile, so why not texture importing?
     
  18. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    "Yes and no" and "it's complicated".

    So, within importing of a single texture, the importer tries to use as many cores as it can, where it can. E.g. texture compression is multi-threaded, as well as some other operations that happen during import.

    Today Unity can not import multiple separate assets in parallel. That is being worked on (and not specifically for textures, but rather "in general"), but I don't know when that will be done.

    Shader compilation is different -- during import it's still the same (shader importing happens one shader at a time). Game data builds and other places that lead to shader compilation do go in parallel, very much like e.g. texture compression goes in parallel. But it's still overall "one asset at once" today.
     
  19. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,331
    Thanks for the insight. I guess having more cores in CPU will help in today's development process.
     
  20. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    392
    What is this sorcery? I just upgraded my project from 2019.4 to 2021.1.3. My library import used to take around 14 hours. It just finished after 2.5 now.

    That. Is. HUGE!

    Thanks a lot for putting in all this effort.
     
  21. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    5,372
    blazing fast, imported an old project on 2020.2 and this new release, texture was recrunched in no time
     
  22. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    818
    Just want to say/ask about texture importers.
    For DXT textures there are GPU compressors done decade ago (GPU compressors can be 10-100 times faster)
    It is looks like Unity compress textures on CPU and there is question:

    Do Unity have plans to utilize GPU for texture compression?
     
  23. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    I actually played around with it on my vacation, and the results are "extremely mixed". For say BC1 or BC3 formats that certainly could be done, but these CPU compressors are already "blazing fast", GPU compression (once you include texture upload/download time) is unlikely to be faster.

    For something like BC7... I tried that. It's a land of "10 minutes waiting for shader to load" or "the driver crashes" or "it kinda works but only for fastest / lowest quality mode, otherwise driver crashes" or "it kinda works but does not produce the same result as the CPU". The cases that did work were either 10x slower than CPU (on one platform/GPU), or only about 20% faster than CPU (on another platform/GPU). This was my attempt: https://github.com/aras-p/bc7e-on-gpu

    I'd like to see them!

    That said, I think for DXT it does not matter. It's already compressing at speeds that are faster than reading a PNG file.
     
    JoNax97 and mahdi_jeddi like this.
  24. RogueCode

    RogueCode

    Joined:
    Apr 3, 2013
    Posts:
    228
    Is there any reason Unity doesn't seem to use medium/large projects for benchmarks? The book of the dead and Boat Attack aren't meaningful benchmarks for anyone working on a real project. Import times are hours, not minutes.
    Maybe the improvements here are linear, and it doesn't matter, but it does sometimes come across a bit like Unity doesn't understand what the editor pain points are for anything except helloworld-esque games.

    Either way, I'll happily take any improvements I can get for import time, so thank you :D
     
    Energy0124 likes this.
  25. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    948
    The fact that Unity needs to fully import all assets before being able to open the project is one of the many things that make Unity borderline unusable for large high fidelity games.

    Just imagine how long it would take to open the project for a game with 15 hours worth of The Heretic quality assets.
     
  26. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,086
    Disable compress on import helps a bit here ( if its textures that take the time )
     
  27. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    210
    Improving import times is a good thing, but making everyday tasks faster is more important. In our project changing any sprite in a sprite atlas will force it to repack, which happens all the time and not just at import time. So optimizations like this this will make everyday tasks a lot faster.
     
    stuksgens likes this.
  28. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,086
    The sprite packer can be set to be only enabled when making a build
    https://docs.unity3d.com/2017.4/Documentation/Manual/SpritePackerModes.html

    Does this help?
     
  29. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    210
    I know that, but disabling sprite packer would make the Editor slow down and make the game unplayable. So we have to rebuild the sprite atlases. The latest optimizations made the packing really fast, but we still have to wait a few seconds for Unity to check every single file to make sure that they don't need to be repacked, which wasn't an issue in 2019.x.
     
    Lars-Steenhoff likes this.
  30. hurleybird

    hurleybird

    Joined:
    Mar 4, 2013
    Posts:
    106
    It's not just the slow speed of imports, it's that oftentimes the editor will decide that it needs to reimport things (textures and otherwise) for no good reason.

    Any difference in the saved editor version will trigger the upgrade process, even if going from, say, 202x.x.y to 202x.x.y+1 wouldn't ever require code changes. Instead of a blanket assumption, maybe set and check for flags to tell if there are changes between versions that require the check. Or, at the very least, prompt the user to allow them to opt out of the upgrade process when it's only a minor version change.

    The most massively frustrating thing I can think of is adding or subtracting to the list of supported rendering APIs in Player -> Other Settings. These reimports can take hours and trigger automatically for each item added or removed. At a minimum, the editor should allow you to change multiple items before triggering the reimport and also should prompt the user for confirmation considering one can easily and inadvertently waste a large chunk of one's work day by changing this setting without realizing the cost of its execution.

    As it stands, I find myself just changing the projectversion and projectsettings files directly outside of the editor in order to avoid unnecessary and time consuming processing, which isn't something one should ever need to do.
     
  31. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    948
    Another one: 32-bit and 64-bit Windows are treated as separate platforms by the editor and trigger mass asset reimports too. It's less awful with asset db v2 and its fast platform switching, but the first time you build for either one after building for the other will still require all assets to be imported as if its a fresh start.
     
    andreiagmu, Jes28 and Lars-Steenhoff like this.
  32. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    In this particular case import times are linear, so really just "one texture" would show similar speedups too. We've tested on some larger projects as well (Book of the Dead is 2GB worth of textures, we tested on a 20GB worth of textures project as well - the speedups were very similar. But the project is not public; we decided to use publicly available projects for the blog post). In any case, in this particular case I think this "you should use a larger project" is not relevant, sorry (in many other cases this request is relevant).

    I don't disagree. Cache Server / Accelerator can help today, especially if you have a build machine priming it with the imports every night or so. Ability to import assets "on demand / as needed" is being worked on as we speak. But nothing that ships in 2021.1 just yet.

    That's not true, and in fact what happens is exactly what you suggest - assets are reimported between versions only when "something substantial in their import logic" changes (this is done per asset type). So it is possible that going form version X to Y will reimport all audio files, and going from version Y to Z will reimport all meshes, or whatever. But it's not the case that "between any version, everything is reimported".

    That sounds like a bug. I've seen this mentioned a few times, that like "adding vulkan to my rendering API list reimported all the textures!", but I could never reproduce it myself, in various projects. There's no code logic that would do this. If you can make that happen, please file a bug!

    I fixed that in 2020.2. If you see that still happening in that or later version, please file a bug with details what happens and how to make it happen.
     
  33. AlanPereiraArt

    AlanPereiraArt

    Joined:
    Apr 29, 2014
    Posts:
    17
    Hi,
    Does the speedups on texture compressions affects Asset Bundle Builds?
    I mean, does it makes asset bundle build times faster?

    Sorry if it seems a dumb question. Thanks in advance.
     
  34. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    If affects import time of the textures. So depends on whether your asset bundle builds are spending most of their time importing assets, or producing the asset bundle content itself. If it's the latter, then no that won't be affected by these optimizations.
     
  35. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,090
    Starring at the progressbar and waiting for ASTC textures to be imported right now. I would very much welcome if you could backport those optimizations to 2019.4.
     
    Energy0124, Jes28 and Aras like this.
  36. dongch007

    dongch007

    Joined:
    Jan 8, 2014
    Posts:
    22
    ASTC optimization backport to 2020 please.
    These's a bug install/update some package will triger reimport all, long time wasted on compress.
     
  37. benthroop

    benthroop

    Joined:
    Jan 5, 2007
    Posts:
    217
    I don't know how much you've looked at this Aras, but it'd also be great to get some attention on controlling *if and when* textures are imported. There are a number of settings (Graphics APIs being one) that trigger a full reimport. Often you might run around and say, set Graphics API, set compression type, change platform, etc. Each one of these will do a full reimport. It'd be great to get a popup like "This will require a full texture reimport. Do you want to do that now?". And then if you say no, there is a UI element somewhere that's like "Texture Reimport Required". Then you can run around and get all your settings right and hit that button when you are ready.

    This has bitten me hard in 2019 LTS this past week. Lots of watching that beautiful green bar.
     
    andreiagmu, dongch007 and Jes28 like this.
  38. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,763
    This one is curious, because it should absolutely *not* cause a texture reimport (except maybe some very specific textures, e.g. "only lightmaps, and only if they were in a format where the format depends on which graphics APIs are included or not").

    Yeah that would make sense, but I'm afraid the asset importing code is not setup to work that way :/ And I don't know much about it myself to make it work that way.
     
unityunity