PlayCanvas bug when processing a specific .glb file

This has been an ongoing PlayCanvas bug for a while and today we were able to reliably recreate it. When uploading certain .glb files to a project, they will fail while being processed. The editor will then show a red circle next to the asset. No errors will be shown in the console.
Screenshot Capture - 2024-03-16 - 20-54-42

Steps to reproduce:

  1. Fork this example project
  2. Download this .glb file
  3. Upload the .glb file to the project

Thank you to @kelsey for setting this up.

After the build has been published, there will be 403 (Forbidden), Access Denied errors when clients try to load this asset. There have been numerous other PlayCanvas posts where the authors simply deleted and reuploaded the .glb as a workaround. I’m hoping this example helps the PlayCanvas team track down and fix the root cause of the issue.


Ping @yak32 @slimbuck

1 Like


We’ve met the same issue today with our imported GLTF models.

I downloaded the linked glb file to my desktop, and imported it to a new project without any problems. Is the problem with uploading it to this specific project only?

For me it happens when I try with a blank project. I will send you the GLTF model via email.

1 Like

We were only able to recreate this error reliably using the example project. The error seems related to the diff between the two .glbs.

As a workaround we can of course delete the project’s existing .glb and upload the new one, but this isn’t always practical because many assets may need to be relinked.

It looks like we generate invalid material json when converting a GLB with material containing IOR == 0. I’m busy fixing this on our backend, but note that it looks like the engine doesn’t handle the special case of IOR == 0 correctly at render time. We’ll investigate this separately.


Created an issue for easier tracking:


Hi @Devortel,

Thanks for providing a repro. Our template merging code is failing due to the root node name changing between the old template and the new (in this case the old root node name ‘female’ becomes ‘SceneRoot’).

The code in question is pretty deep inside unfamiliar code on our backend, so I’m not sure how quickly we could address this issue.

Hopefully you can mitigate some of the pain with this extra context though.