A key focus area for Unity 2021.1, now available in beta, is Editor performance, helping you iterate faster on your project. Texture import and compression optimization is a key part of this.
Compared to other game assets, textures typically take up the majority of hard disk space – and approximately two thirds of the total import time. When working on a complex project, waiting for textures to import or compress costs you valuable time. While Unity tools for teams, such as Unity Accelerator, help alleviate this issue, we know that we can always do more. That’s why we’ve started working on optimizing the texture import and compression process.
The timing below reflects a project on a PC with AMD ThreadRipper 1950X CPU with the project folder on an SSD disk. Speedups on other configurations (e.g., Mac) are similar. We are comparing an earlier version of Unity 2020.2 (alpha 21) with the Unity 2021.1 beta 5 version.
Here’s how long it takes to import all textures from the Boat Attack project (118 textures, 720MB):
- PC platform: 102 → 94 seconds (1.1x speedup)
- Android platform, ETC2 compression: 203 → 101 seconds (2.0x speedup)
- Android platform, ASTC compression: 536 → 172 seconds (3.1x speedup)
- PC platform, same texture size settings as Android: 30 → 22 seconds (1.4x speedup) Many textures in the project use larger texture sizes on PC compared to on the Android platform.
On a larger project, such as Book of the Dead: Environment, importing all the textures (425 textures, 1.9 GB) takes:
- PC platform: 161 → 133 seconds (1.2x speedup)
- Android platform, ETC2 compression: 1140 → 494 seconds (2.3x speedup)
- Android platform, ASTC compression: 3162 → 1204 seconds (2.6x speedup)
We achieved these speedups by focusing on optimizing the following two areas:
1) pixel data conversions and copies done during the texture import process, as well as adding SIMD or threading optimizations to the slow parts (e.g., sRGB conversion, panoramic layout cubemap processing, etc.)
2) texture compression, by updating to the latest versions of compression libraries or optimizing the compression libraries themselves
Low-risk parts of the ETC format compression optimizations (1.4x speedup) are already backported to 2020.2.0, 2020.1.15 and 2019.4.16 versions.
What’s next
Further improvements to texture import times and compression are coming for Unity 2021.2, so keep an eye out for the next public release on our beta testing page and beta forums.
Unity 2021.1 beta
We hope this helps and that as a Unity 2021.1 user, you’ll spend way less time waiting for import progress bars to finish. You can get the latest beta from the Unity Hub or on our download page. As of today, it includes over 1,900 fixes and more than 260 features and changes. Try it out, and if you run into any issues, submit a bug report to qualify for your chance to win one of four ultrawide IPS 34” 144 Hz monitors (see the full rules here). Remember, the beta is not intended for use in production-stage projects. You should always make sure to back up your existing projects if you plan to use them with the beta.
That being said, we would love to know if you experience similar texture import time improvements in Unity 2021.1. Tell us what you think in this forum thread.
Postagens relacionadas
Comments are closed.
25 replies on “Texture optimization in Unity 2021.1”
This is great! Unrelated request, but that would be a great improvement: being able to run Texture2D.Compress (or something similar) on a separate thread. Improvements on mesh manipulations a couple years back were great news. Being able to compress textures at runtime without spikes would be awesome!
Great work guys! Improved iteration times makes for better results.
Would it be possible to move texture importing to a background process?
Most of the time we do not need (the full resolution version of) most textures immediately after dragging them into the project folder or after updating our Unity version (or anything else that triggers an asset reimport).
So ideally Unity should only create a placeholder texture which can already be used (applied to a Material) but which gets replaced with higher and higher resolution versions as it continues being imported in the background. With mipmapping enabled the lower resolution versions could even be reused (I think).
And to finish it off, add a new EdiorWindow which shows a reorderable list of texture-import tasks so that *when* a specific texture if required faster it can be moved to the top of the priority list.
“Would it be possible to move texture importing to a background process?” — yes, and something along those lines is what we are experimenting with (not only for textures, but in general for most/all assets). As well as other approaches to achieve better iteration/import times. But nothing to announce just yet.
Most of my time spending to see this message :
https://i.ibb.co/dmgNppv/uuuu.png
That one is about script recompilation/reload, and not related to textures at all. I’d suggest using Editor Iteration Profiler to see what makes that slow (might be scripts in your own project). https://forum.unity.com/threads/introducing-the-editor-iteration-profiler.908390/
Please fix the bad global illumination and verify the realtime global illumination.
Can we use deferred renderer in urp on upcoming unity version?
This does not sound related to the topic of the blog post at all. If you have specific feedback about lighting features of Unity, GI forum section sounds more relevant.
I’m assuming that any speedups on consoles would be similar to the PC results?
In general, yes. Some of the speedups are general “everywhere”, some are specific to particular texture compression formats. In the examples in this post, “PC” is a mix of DXT and BCn formats, and mobile is ETC2 and ASTC formats. Depending on which consoles you’re asking about, these would use very similar texture formats.
Well the next-gen consoles have introduced new texture compression formats + hardware decompression. These architectures differ wildly from what is currently found on PC’s.
@Wolfos: I don’t think that they differ in the *compression* process. But anyway, even if I knew anything concrete about that, I could not say that in public due to NDAs.
Performance improvements in the editor are always welcome. Great job Aras, Florian, and anyone else involved. I would love to see more blog posts like this. Thank you!
Very nice improvements! Thanks
Any news about only compressing the textures that are used in the build at build time?
and not all the textures in the project folder?
You may want to see how the compression (crunch) affect the graphics while in editor. How much space it takes etc.
Well it could be configurable / on-demand. Although the editor isn’t comparable to the runtime in many ways already.
> Any news about only compressing the textures that are used in the build at build time
Not yet. “Import and compress assets on-demand instead of everything” is being experimented on, but nothing to announce just yet.
Thanks for the status update!
Hi, nice work. Any numbers for OSX texture import times?
The speedups are very similar. The hardware I was testing on is different of course, but overall speedups are in the same ballpark. We use the same texture import processing code and the same texture compression libraries across all of Windows, Mac, Linux editor platforms, so optimizations like this apply across the board.
Good job Unity, keep it up!
I can’t wait to see your next updates.
really nice but… what’s the value of importing textures faster if Book of the Dead: Environment doesn’t work since 2018 versions?
“Book of the Dead: Environment” is just a test case to show some numbers. Similar speedups you’d see in any project, including your own. If your suggestion is to *not* speed up texture importing for everyone just because we do have one sample project that does not work in later Unity versions then… well I dunno, I don’t agree with that suggestion :)
Are you able to take advantage of the MS DirectStorage API yet?
My understanding is that 1) DirectStorage has not related at all to the topic being discussed here — it’s about *loading* textures at runtime, not about import time processing & compression, and 2) DirectStorage is not even released yet (for Windows).