You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thanks for the magnificent codebase 😉, this issue has me completely stumped so I’m pretty confident it’s a bug. However, apologies in advance if it’s not and there’s some elusive means of clearing gLTFast’s memory use I’ve somehow missed in the included example project.
Describe the bug
Every time we load a new GLB model we can only partially remove it from memory. This seems to happen on every platform, but is particularly problematic for us on iPad, where our application will inevitably build up memory use over time and eventually crash. To clarify, each one of our models is optimised enough to be viewed individually but viewing them in sequence causes issues because we cannot completely remove their predecessors from RAM.
Files
A small example unity project (including a glb) which re-creates the issue and produces .snap files (unity memory snapshots) as evidence can be downloaded here: https://we.tl/t-jYf1k8LwRZ
Open build settings and tick “Development Build”, then do a build
Run the built executable, the example application will:
Load an empty scene, then take a first memory snapshot.
Additively load a new scene.
Run-time load a glb inside of that new scene.
Destroy the loaded glb and clear any references to it.
Unload the scene the glb (and the script that loaded it) was in.
Force a memory clean-up with Resources/UnloadUnusedAsset and GC.Collect.
Take a second memory snapshot
Wait until the application says, “Demonstration complete”. You can then close the application.
There will be two new .snap files on your desktop, return to the Unity Editor and use Window -> Analysis -> Memory Profiler to import and compare the .snap files. For example, I get an additional 270mb of untracked memory from the second memory snapshot, when ideally both snap files would have the same memory use.
Expected behaviour
When the first and second memory snapshots are compared, memory usage should be nearly identical. We should be able to restore RAM usage to (roughly) the original amount it was before the GLB was loaded.
Screenshots
Desktop (please complete the following information):
glTFast version: 6.8.0 (From the Unity Registry)
Unity Editor version: 2022.3.51f1
Render Pipeline and version: Built-In Render Pipeline for 2022.3.51f1
Platform: Standalone (Windows, Mac, Linux), Windows 10
The text was updated successfully, but these errors were encountered:
I realised my example above, crucially, doesn’t invoke GltfImport.Dispose, here’s a version of the project which does invoke GltfImport.Dispose: https://we.tl/t-dzLqJbvrGf
Sadly, the memory leak is still present even after invoking GltfImport.Dispose:
First, thanks for the magnificent codebase 😉, this issue has me completely stumped so I’m pretty confident it’s a bug. However, apologies in advance if it’s not and there’s some elusive means of clearing gLTFast’s memory use I’ve somehow missed in the included example project.
Describe the bug
Every time we load a new GLB model we can only partially remove it from memory. This seems to happen on every platform, but is particularly problematic for us on iPad, where our application will inevitably build up memory use over time and eventually crash. To clarify, each one of our models is optimised enough to be viewed individually but viewing them in sequence causes issues because we cannot completely remove their predecessors from RAM.
Files
A small example unity project (including a glb) which re-creates the issue and produces .snap files (unity memory snapshots) as evidence can be downloaded here: https://we.tl/t-jYf1k8LwRZ
To Reproduce
Expected behaviour
When the first and second memory snapshots are compared, memory usage should be nearly identical. We should be able to restore RAM usage to (roughly) the original amount it was before the GLB was loaded.
Screenshots
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: