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
Celestine Ghiardie
Wow yes - just tested this today. The issue is not yet fixed. An ankle long dress exported from Blender 3.6.9 as Collada (.dae) (without using Avastar) looks fine in SL. Exporting the exact same dress as GLTF 2 shows issues in belly region, back - from lower back to the neck, elbows and shoulder/chest area.
Dan Linden
A potential fix for this issue was added to the 26.3 Beta, now available at https://releasenotes.secondlife.com/viewer/26.3.0.30006559438.html
I personally don't see a difference, but I'm not an expert on this subject matter. Feedback is welcome!
Gaia Clary
Dan Linden Thanks, Dan. I checked the published 26.3.0.30006559438 build. The relevant fixes seem to not be included in this Beta.
The missing commits are:
4926a066dd5c502d9d2c155a323936ea6e8cb8e0
#5639 Initialize LLJointData support category from avatar skeleton
3ca4bf1ac0a3b26e961579a86869181104c11b5f
#5639 Fix glTF collision volume bind reconstruction
The public release/26.3 source still contains the old collision-volume implementation, and the shipped macOS binary also matches the pre-fix code path. Both fixes are present on develop, but not in the published 26.3 Beta.
This explains why no improvement is visible. Could these two commits please be integrated into release/26.3 and a new Beta build provided for testing?
For the original test files, âInclude skin weightâ must be enabled and âInclude joint positionsâ disabled. Both DAE and GLB must be uploaded again with the corrected viewer, then compared after wearing them.
Dan Linden
Gaia Clary: Thank you for the confirmation that it's not yet fixed.
Dan Linden
updated the status to
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