Search Issue Tracker
By Design
By Design in 2023.2.X
Votes
1
Found in
2021.3.28f1
2022.3.5f1
2023.1.4f1
2023.2.0a23
Issue ID
UUM-42924
Regression
No
Texture2D.PackTextures produces uncompressed Textures
How to reproduce:
1. Open the user-attached project “TextureRepackBug”
2. Open the “SampleScene” scene
3. Enter the Play Mode
4. Observe the Console
Expected result: There is nothing logged into the Console because the Texture is in ASTC_4x4 format
Actual result: There is a message logged into the Console notifying about the Texture being in RGBA32 format
Reproducible with: 2021.3.28f1, 2022.3.5f1, 2023.1.4f1, 2023.2.0a23
Reproducible on: Windows 11 Pro
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Performance Markers Search window shows an empty entry in the list
- Enabling Deep Profiling in Performance Markers Search window breaks Inspector panel buttons when navigating through the marker items
- Dragging selector from selector row background shows preview but does not apply class in UI Builder
- An "InvalidOperationException" error is thrown when TryRemoveItem is used with rebuildTree set to false
- Build fails with IL2CPP error when building on Android platform in a specific project
Resolution Note:
This case is "As Designed". Unfortunately, some of the API docs don't make it clear why this is happening, so we will ensure that those are improved.
- Regarding the reason why the "destTexture.LoadRawTextureData(target.texture.GetRawTextureData())" line fixes the visuals: this is both because Texture2D.LoadRawTextureData sets pixel data for the texture in CPU memory and the fact that Texture2D.PackTextures relies on that CPU version of the texture.
Additionally, as explained here (https://docs.unity3d.com/ScriptReference/Graphics.CopyTexture.html), CopyTexture never performs copies of the CPU data if copying a region of a compressed texture.
As such, in this case, CopyTexture cannot be used to set up the input textures for Texture2D.PackTextures.
- Regarding the reason why the texture switches to uncompressed RGBA32: as the Texture2D.PackTextures documentation mentions, "if the input textures can't all fit into a texture atlas of the desired size then they will be scaled down to fit" (https://docs.unity3d.com/ScriptReference/Texture2D.PackTextures.html).
However, an important detail that is missing here is that, if Unity must scale down, then the format of the atlas is switched to uncompressed RGBA32.
In order to avoid this, you must use a "maximumAtlasSize" that can fit all the textures to pack. (in this case: 2400)
Resolution Note (2023.2.X):
This case is "As Designed". Unfortunately, some of the API docs don't make it clear why this is happening, so we will ensure that those are improved.
- Regarding the reason why the "destTexture.LoadRawTextureData(target.texture.GetRawTextureData())" line fixes the visuals: this is both because Texture2D.LoadRawTextureData sets pixel data for the texture in CPU memory and the fact that Texture2D.PackTextures relies on that CPU version of the texture.
Additionally, as explained here (https://docs.unity3d.com/ScriptReference/Graphics.CopyTexture.html), CopyTexture never performs copies of the CPU data if copying a region of a compressed texture.
As such, in this case, CopyTexture cannot be used to set up the input textures for Texture2D.PackTextures.
- Regarding the reason why the texture switches to uncompressed RGBA32: as the Texture2D.PackTextures documentation mentions, "if the input textures can't all fit into a texture atlas of the desired size then they will be scaled down to fit" (https://docs.unity3d.com/ScriptReference/Texture2D.PackTextures.html).
However, an important detail that is missing here is that, if Unity must scale down, then the format of the atlas is switched to uncompressed RGBA32.
In order to avoid this, you must use a "maximumAtlasSize" that can fit all the textures to pack. (in this case: 2400)