That’s good to know.
Unfortunately, I think this is exactly where Roblox’s importer is poorly designed.
I’m currently trying to document all of its behavior, and it’s surprisingly complicated.
Regarding your fourth point, if the name of a geometry mesh object (when exporting as FBX), or the name of the mesh data (when exporting as glTF), matches the name of a bone in the connected armature, that bone is converted into a physically simulated Motor6D.
I assume this will eventually become an AnimationConstraint once support is added.
The bone itself is not deleted.
The real problem is that Motor6Ds are imported with their rest-pose rotations reset to (0, 0, 0).
If you then import an animation authored in Blender for a rig whose rest-pose orientations were never intended to be globally aligned, Roblox ends up using a different rest-pose basis from the original file, causing the animation to play incorrectly.
That’s why people recommend giving the bones different names so they are not converted into Motor6Ds or AnimationConstraints.
Personally, I think this is fundamentally the wrong design.
Adding the ‘Zeroed Rotations’ option certainly helps, but it still breaks down if a rig contains both Bones and Motor6Ds.
Some joints preserve their original rest-pose rotations while others have them zeroed, so neither the regular ‘Imported Rig’ nor the ‘Imported Rig (Zeroed Rotations)’ version can correctly reproduce the original rig.
I also suspect the ‘Zeroed Rotations’ implementation itself still has some issues.
I’m currently experimenting to understand exactly how it behaves.
For R15 characters, meshes named {Name}_Geo are automatically associated with the bone named {Name}. However, this naming convention is not applied to custom rigs. A mesh named {Name}_Geo will not be associated with the bone {Name} and therefore will not be converted into a Motor6D.
If Roblox has already established the _Geo naming convention, I think the same naming convention should apply to custom rigs as well.


