differences between collada and glb imports
tracked
Gaia Clary
We are comparing rigged mesh export from Blender to Second Life via both .dae and .glb.
We can export both formats so that they behave identically in SL, but only when deformation is limited to the standard m* bones.
As soon as SL volume bones are also marked deform, the .glb result differs slightly from the .dae result after the mesh is worn on the avatar. The imported static meshes are identical. The difference appears only after wearing, when the SL rig actually deforms the mesh.
A few details:
-same source rig and mesh
- same visible export mesh in Blender before writing the file
- same result in SL when volume bones are not deforming
- mismatch appears only when volume bones participate
- note that volume bones have the known non-neutral/rest-scale oddities
Does anyone know how SLâs .glb importer handles volume bones internally, especially their rest/bind transforms or scaling? We are trying to determine whether the difference comes from Blender glTF export, Avastar/Collada export assumptions, or SLâs handling of volume-bone skinning.
Log In
Dan Linden
marked this post as
tracked
Dan Linden
Hi Gaia,
Can you send us some content to test with? Please email the zip file to bug-attachments@lindenlab.com and reference the issue name in the email subject line.
Thank you!
Gaia Clary
Dan Linden I have mailed a zip file as you requested. Note that the files have wrong bone orientations, so the files only work "with weights" and will fail when imported "with joints". I meanwhile fixed this detail on the glTF exporter side, but I believe it is not relevant for the differences between dae and glb imports "with weights".
However, we meanwhile have been testing a few scenarios with different volume-bone setups. We also took a brief look into the SL viewer source, but we are not very familiar with that codebase, so please take this with a grain of salt:
One thing that stood out to us is that the glTF collision-volume branch in the viewer source contains an explicit comment saying that this part is âlikely incomplete or even wrongâ and that viewer collision bones specify rotation and scale, which should be applied there (see
indra/newview/gltf/llgltfloader.cpp
, around line 1569, local checkout 130c50c
).That seemed highly relevant to us because the biggest visible deviations in our tests show up around the chest/pec area, and those volume bones do have rotation in the viewer skeleton definition.
So our current suspicion is that the DAE and glTF paths do not reconstruct collision-volume bind/rest state in the same way, especially for rotated volume bones.
If more examples, files, or targeted inspections would help, we are happy to assist.
====
One follow-up question: from our tests and brief source inspection, it looks as if the current glTF import path may rely on the viewerâs default collision-volume transforms, rather than fully preserving imported rotation/scale for deforming volume bones.
If that reading is correct, does this reflect an intentional limitation of the current glTF importer, or is it considered incomplete behavior that is expected to change?
We ask because, if this is an intentional long-term restriction, we may need to align our Collada export behavior as well to avoid giving creators inconsistent results between
.dae
and .glb
.Gaia Clary
We meanwhile looked deeper into this because we really wanted to understand what happens in the viewer, and that investigation led us to a proposed viewer-side fix for the glTF collision/volume bone bind reconstruction path:
From our tests, this was the missing piece that made the
.glb
import match the corresponding .dae
import for rigs using deforming volume bones.If there is anything else we can do, please let us know.
Dan Linden
Gaia Clary: Thank you so much!
This issue is tracked at https://github.com/secondlife/viewer/issues/5639