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
- Player crash when switching focus in Exclusive Fullscreen mode with DirectX 12
- Too little validation messages in the "WebAssembly Language Features" Memory settings
- Project Settings Search Highlights are misaligned when using the Bitmap Text Rendering Mode
- "GetControlID at event ValidateCommand returns a controlID different from the one in Layout event" Warning is thrown when undoing the deletion of Sprite Shape Profile
- Memory related fields in the "WebAssembly Language Features" can be set to the negative numbers
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)