Texture sizes are 10x bigger in iOS builds from 6000.0.24f1 vs 2023.2.20f1

[ROBYER1]

Describe the bug 💬

This project exported and ran fine in Unity 2023.2.20f1 on iOS running on an iPad Pro - when I updated it to Unity 6000.0.23f1 and also 6000.0.24f1, I noticed the allocated size of textures in the build in the memory profiler are nearly 10x the size of the textures in the build from Unity 2023.2.20f1.

I have cross checked this doesn't happen with textures linked to obj, dae or fbx files imported into Unity and this only is happening with .glb files.

I have a small repro project here using the DamagedHelmet.glb example file from the Khronos GLTF sample models repo where I opened it in Unity 2023.2.20f1, built to test then opened it in Unity 6000.0.24f1 without changing anything built and tested it to cross reference this - See size differences of the DamagedHelmet.glb textures.

Unity 2023.2.20f1

Unity 6000.0.24f1 LTS

Steps to reproduce 🔢

1. Download the attached project from the repro files below, open in Unity 2023.2.20f1 as build target iOS on Silicon Mac Editor (not intel)
2. On Models > DamagedHelmet, ensure UnityGLTF is the importer for the model
3. Build and run it on iOS to a device like an ipad Pro as development build with auto link profiler on
4. In Memory Profiler, grab a memory snapshot of the running build
5. Repeat the steps above with Unity 6000.0.24f1 as build target iOS on Silicon Mac Editor (not intel)
6. Compare the memory snapshots

Files to reproduce the issue ♻

MemoryRepro.zip

Editor Version 🎲

6000.0

Render Pipeline and version

URP 16.0.6

UnityGLTF Version

2.14.0 & 2.14.1 tested

Operating System 👩‍💻

macOS, iOS

When does this problem happen?

• [ ] Editor Import
• [ ] Runtime Import
• [ ] Editor Export
• [X] Runtime Export

Additional Info 📜

No response

Validations 🩹

• [X] I have searched existing issues: no issue already exist that reports the same problem.
• [X] I follow the Code of Conduct
• [X] I provided a minimal reproducible example, including files when necessary.

[hybridherbst]

Thanks for the detailled information! Just to be clear, is this the bug you also sent to Unity about this change of behaviour? Could you reference the issue number here?

[ROBYER1]

It is the same issue I sent to Unity although I sent them a larger bug repro project than the one linked here, I will follow up my bug report with the same zip linked here if required.

The Unity issue is IN-87705

[ROBYER1]

I haven't managed to reproduce this on Windows build platform target so I would assume this is specific to iOS for now.

[ROBYER1]

Still happens in Unity 6000.0.27f1 on iOS, the bug report with Unity at IN-87705 is still under review as well but Unity support has been especially slow for me the past 5 months so far so I'm not holding out hope of a response from them.

[ROBYER1]

I have good news, Unity have acknowledged this bug today and it has been tasked by them internally. I'll close this bug report when they have fixed it.

Your bug report Texture2D memory allocation size is significantly increased when running on iOS device has been confirmed and transferred to the appropriate internal development team at Unity. Your bug report has the following internal ID: UUM-88991

Public issue tracker link: https://issuetracker.unity3d.com/issues/texture2d-memory-allocation-size-is-significantly-increased-when-running-on-ios-device

[atteneder]

Hi folks 👋 ,

this issue somehow found its way to me Unity-internally :)

I couldn't reproduce it with 6000.0.55f1 and UnityGLTF 2.15.0 (the pre-installed 2.14.0 was not working anymore, so I took the next newer, working version).

The Texture Compression setting on that asset is set to Best, which makes UnityGLTF encode it to ASTC6x6. I have the suspicion that for some reason those textures end up as uncompressed bitmaps in your observation (maybe undetected platform switch or sort of?).

When you select the texture in the project view (you have to expand the DamagedHelmet to see the textures it comes with), what format does the it say it is in the inspector (at the bottom of the preview)? It should be ASTC6x6 like this:

If it's another format, what happens if you re-import the asset (right-click -> Reimport)? What happens if you switch platforms forth and back?

[hybridherbst]

Nice to see you here 😀

UnityGLTF does correctly switch texture compression options when the target platform changes. We verified this to work correctly in builds as well.

The issue here, to the best of my understanding, is that the compression that Unity itself suggests for the iOS platform does then not actually work on iOS, somehow Unity decompresses the (correctly compressed) subassets on build again (or when loading? not sure). Regular textures also get compressed to ASTC6x6 on iOS, and then work fine in builds.

[atteneder]

Thanks for the info.

I tried again with 6000.0.33f1 (the most recent version @ROBYER1 reported he could still reproduce the issue) and it seems to work fine on my machines (iPad Pro 11-inch running iPadOS. 18.6 and iPhone 12 Pro on iOS 18.5).

@ROBYER1 on top of the texture format in the inspector I requested above, please provide three more things:

1. info about the exact iOS/iPadOS version used and the exact device.

2. Can we compare the build size report (see Editor logs right after building)? It might give an indicator whether things fall apart during build or later at runtime. Mine shows these numbers:

-------------------------------------------------------------------------------
Build Report
Uncompressed usage by category (Percentages based on user generated assets only):
Textures               15.4 mb	 85.0% 
Meshes                 773.3 kb	 4.2% 
Animations             0.0 kb	 0.0% 
Sounds                 0.0 kb	 0.0% 
Shaders                721.9 kb	 3.9% 
Other Assets           710.8 kb	 3.8% 
Levels                 0.0 kb	 0.0% 
File headers           154.3 kb	 0.8% 
Total User Assets      18.1 mb	 100.0% 
Complete build size    1.3 gb
Used Assets and files from the Resources folder, sorted by uncompressed size:
 12.7 mb	 0.9% Assets/Models/DamagedHelmet.glb

The important value is how big the Textures category and Assets/Models/DamagedHelmet.glb is.

3. Please show me the Selection Details in the Memory Profiler -> Unity Objects view if you select Texture_0. Here's how mine looks like:

With that information we might have a strong indicator that Unity (or iPadOS?) does wrongfully decompress the textures at runtime.

That being said, I'll forward the issue as it's not my personal area of expertise, but the more info we can gather, the more targeted we can operate.

Thanks both of you.

[ROBYER1]

So I haven't noticed this in recent Unity + UnityGLTF versions I have used in production but I trust this is probably an issue affecting some older engine versions.

Tested on an M1 Mac Mini 2020 model with Sequoia 15.6.1 Unity 6000.1.12f1 UnityGLTF 2.17.9

Ipad Pro 12.9inch 6th gen iPadOS 18.6.2

Texture sizes at runtime in the memory profiler captured from the iPad using memory snapshot are as expected.

I would consider this issue fixed in that combination of Unity editor and UnityGLTF.

If anything else needs to be tested I can help