Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
4 of 7 tasks
ROBYER1 opened this issue Oct 29, 2024 · 5 comments
Open
4 of 7 tasks

Comments

@ROBYER1
Copy link

ROBYER1 commented Oct 29, 2024

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
Screenshot 2024-10-29 at 2 29 42 pm

Unity 6000.0.24f1 LTS
Screenshot 2024-10-29 at 2 29 51 pm

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
  • Runtime Export

Additional Info 📜

No response

Validations 🩹

@hybridherbst
Copy link
Collaborator

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
Copy link
Author

ROBYER1 commented Oct 29, 2024

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
Copy link
Author

ROBYER1 commented Nov 11, 2024

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

@ROBYER1
Copy link
Author

ROBYER1 commented Nov 21, 2024

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
Copy link
Author

ROBYER1 commented Nov 25, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants