Texture corruption after resizing texture on runtime - Figmin XR

Hi Magic Leap

For the longest time we've had this seemingly random texture corruption issue, we've narrowed it down to only happening when we resize textures on runtime, we do this often because Sketchfab 3D models usually have unreasonable texture sizes.

The problem is that this issue happens exclusively on ML2, out of the like 7 or so other platforms that we support, and it's a silent error so we have no clue what's going on.

We also don't have the source code to the Library that actually does the resizing, it's called Resize Pro in the Unity Asset store.

Here is a video showing the problem, I load 3d models, most of the time they have some kind of texture issue but sometimes they are totally fine.
If you watch till the end you'll see that i later on go to settings and set the texture quality to high and the problem is gone, (mode must be set to edit for this to show).

So I'm not so sure what to do, here is a download link to the Figmin XR APK so you can try yourself:

I'm also attaching the logs, at the very end of the log I load the plane but I don't see any issues.

Thanks! hopefully we can figure this one out

Unity Editor version: 2022.2.0b14
ML2 OS version: 1.1.0
MLSDK version:1.3?
Host OS: (Windows/MacOS) Windows

Error messages from logs (syntax-highlighting is supported via Markdown):
FigminLogs.txt (585.7 KB)

Hi @Javier, thank you for your post. I'm talking to our engineers now. Are you using universal render pipeline for Magic Leap 2 or on your other devices?

Also, what texture formats is this happening to? Thanks.

We don't use URP, just the oldschool render pipeline.

The texture format of the plane shown in the video is RGBA32

Thanks!

1 Like

Hi @javier,
Just wanted to give you an update and say that we are sending this off to our graphics team. Do you know if this issue occurs if you're not applying the texture to 3D models?

Would you be able to create a small example scene to isolate the issue? Ideally it would be automated.

For example:
I launched the application
I see a cube with a texture applied to it
After 2 seconds the texture resize back and forth from high to low quality

Another example could be that the object gets destroyed and recreated with the resized texture.

Hi @ababilinski

I made a quick test to resize pictures and the issue still occurs, here's a video, it appears like most of the time it doesn't finish the job since it's partially black. Heads up though, you can't repro it like this in the APK i attached, just use the 3D models.

I'm afraid I won't' be able to make you a test scene, I'm about to go on a holiday but I'm not sure how much that would help you since I don't have the code that actually does the resizing, it's a DLL. If you need it I can send it to you privately.

In code nothing fancy happens just something like:

Texture2D tex = new Texture2D(2, 2);
if (tex.LoadImage(data))
{
int width = tex.width;
int height = tex.height;
tex.ResizePro(width / 2, height / 2, false, true, false);
m_material.mainTexture = tex;
}

Another bit of info I can give you is that ML2 is the only platform that runs on Vulkan so maybe that's why it only happens here. Also these are not textures included in the build, they are downloaded off the internet.

Hope that helps!

Are the textures downloaded once or do they get redownloaded before resizing?

We download them once, then cache to disk and that's where that data byte is coming from.

Hi Javier, thank you for that information. Unfortunately without having an isolated apk we won't be able to debug the application effectively.
Let me know if you are able to build the project after your holiday. Until then, I would recommend contacting the plugin developer to troubleshoot. They will be able to use the emulator in Android Studio to run a Android 10 x86_64 virtual machine

@javier One of our engineers suggested to check to see if it's a memory leak and if you're running out of VRAM. The engineer ran into that on both assist and Visualize with runtime imported textures.

The issue we had was that Texture2Ds do not get garbage collected when out of scope, you have to free the memory with Destroy explicitly otherwise you create a leak. If you're resizing by creating a new Texture2D and not destroying the original we can see this being an issue.

The ML2 has 1GB of VRAM and begins corrupting around 800-900MB of usage in a single app. Unity's Memory Profiler can help diagnose if this is the issue or the Runtime Profiler if you have it report VRAM usage.

Hope this helps.

This issue was resolved by updating to Unity 2022.2.14

1 Like