GLB Mesh Import: Cube Models for Visible Mesh and Issue when used for Physics

[aiaustin]

Environment

Second Life Project Gltf-mesh-import 7.1.14.15205102881

Description

I have noted some issues with even the simplest mesh shape such as a cube whether loading it as a mesh, part of a larger model or trying to use the cube as a very simple physics shape for other meshes. Looking at this in isolation it seems that the Blender default cube shape has each face as a square (not triangles). I created two cubes, one the default Blender one (white) and the other with each face split to two triangles (blue). The attached .zip file has .dae and .glb exports of each.

Cubes.zip

Cube with 2 triangles per side in Blender

• Cube.dae - Works fine.
• Cube.glb - Works fine.

Cube with 1 square face per side in Blender as created by default with Add -> Cube (on export to DAE or GLB extra faces might be added)

• Cube-Default-Blender-Square-Faces.dae - Works fine.
• Cube-Default-Blender-Square-Faces.glb - Message "There was a problem uploading the file". But allows upload and rezzes anyway.

.glb models, even a simple cube, used for physics shapes appear to have issues. Note that trying to use Cube.glb as a "file" physics model gives a log entry "No physics model specified for Cube" whereas using Cube.dae shows the expected "PHYS Model Cube loaded".

P.S. Firestorm provides an option to select a default built in cube.dae for physics and I note that also has each face split into two triangles.

Reproduction steps

1. Unzip the provided Cube.zip and obtain the .dae and .glb of the Blender default Cube and a cube with each face split into two triangles.
2. Try mesh uploads of each and observe the messages given in UI popups, in the Log tab of the uploader and in SecondLife.log
3. Try to use the .dae and .glb variants as a simple physics model for any GLB mesh upload and observe that there is an error message for GLB variants.

[marchcat]

• Cube-Default-Blender-Square-Faces.glb - Message "There was a problem uploading the file". But allows upload and rezzes anyway.

The model looks properly triangulated by the Blender's export.
This message indicates that the file has no materials in it.

[marchcat]

Cube-Default-Blender-Square-Faces.glb works fine with simple models too.
And for the complex models, current behavior is similar to .dae loader.

[aiaustin]

Useful to know that is one cause of the error message. I assumed you should stop and not proceed with an upload when such a message was shown. It would be helpful if that cause was added to the message shown to the user, and further details given in the log tab.

The log tab at the moment using "Cube-Default-Blender-Square-Faces.glb" seems to say "No physics model specified for Mesh" which I think from what you said is incorrect? Whereas using the Collada "Cube-Default-Blender-Square-Faces.dae" indicates "PHYS Model Batmobile 1966 loaded".

[AtlasLinden]

Tested on Second Life Project 7.1.14.15976006598 (GLTF Mesh Import) on Win11/MacOS

No error appears upon uploading Cube-Default-Blender-Square-Faces.glb (or the other provided cube models).
However, using either cube GLB file as physics for any of the cube models gives the following log and does not apply any physics to the model:

Loaded LOD 4: correct namesfound; submodels NOT found
PHYS Model Cube loaded
No physics model specified for Cube
List of models does not include Cube

This does not occur when using Cube-Default-Blender-Square-Faces.dae as the physics for each of the cube models.

Oddly enough, using the GLB file for physics for a different model such as the duck used above appears to work as expected with the following log:

Loaded model name Cube-Default-Blender-Square-Faces for LOD 4 doesn't match the base model. Renaming to LOD3spShape_PHYS
PHYS Model duck loaded
Assigning collision for LOD3spShape to match LOD3spShape_PHYS

@marchcat, what are your thoughts on this behaviour?

[marchcat]

Thank you for finding this, @AtlasLinden!

It looks like this happens when you're trying to upload the same file for both LOD_HIGH and LOD_PHYS.
In general, that shouldn't be an issue, since you can just select the same LOD for physics, but this behavior is inconsistent with the DAE loader. I'll look into it later.

[AtlasLinden]

If that's the case then I'll make a separate issue for that. See #4314
For now this report passes QA.
Verified on Second Life Project 7.1.14.15976006598 (GLTF Mesh Import) on Win11/MacOS