从Meshy这类AI生成平台导出角色模型时，不少用户会碰到一个共同问题：在平台预览中角色还能摆姿势，导出的FBX或GLB文件导入Blender、Unity或Unreal后，骨骼却不见了，蒙皮权重也失去作用。出现这种状况并不意味着模型本身没有绑定数据，而是绑定信息的表达方式在格式转换中产生了断裂。我们将从文件结构层面分析骨骼丢失的原因，并给出可操作的修复与导出方案。

一、为什么Meshy导出的骨骼会丢失？

FBX和GLB对骨骼与蒙皮的定义机制完全不同。FBX把骨骼作为场景中的节点层级保存，每个骨骼节点带有变换信息，网格通过SkinDeformer引用这些节点并存储每个顶点的权重。GLB则使用skin对象记录关节索引列表、逆绑定矩阵和自由度，关节本身是普通的scene node。Meshy在生成带绑定模型时，内部可能采用一套统一的骨架结构，但导出时为了压缩文件、优化节点数量，会丢弃未参与蒙皮的骨骼、重置绑定姿势，或者把所有骨骼合并成单一的普通节点。当导入工具读取到这些节点时，无法识别它们是关节，自然就不会创建骨架。

另一个常见原因是命名规则。FBX导入器会依据节点名称或Deformer关系判断骨骼，如果Meshy导出的骨骼名字里带有空格、特殊字符，或者多个骨骼重名，导入器可能自动重命名，导致Deformer引用的名称与实际节点不匹配，最终只导入了网格而丢失权重。因此，在修复前必须先确认源文件里是否还保留了顶点组和骨骼修改器，而不是直接重建。

检查一个GLB文件是否包含骨骼，可以使用Python的pygltflib库。下面的脚本会读取文件并打印skin数量、joints数量和顶点权重属性，帮助快速定位问题。

from pygltflib import GLTF2
gltf = GLTF2.load("character.glb")
if gltf.skins:
    for skin in gltf.skins:
        print("骨骼数量:", len(skin.joints))
        print("逆绑定矩阵访问器:", skin.inverseBindMatrices)
else:
    print("文件中不存在skin数据")
for mesh in gltf.meshes:
    for prim in mesh.primitives:
        if "JOINTS_0" in prim.attributes:
            print("网格包含关节索引属性")
        if "WEIGHTS_0" in prim.attributes:
            print("网格包含蒙皮权重属性")

二、在Blender中重建绑定关系与保留权重

如果检查结果显示模型没有skin，但网格顶点组仍然存在，说明绑定信息还停留在顶点组层面，只是没有被导出为骨骼关系。这时可以在Blender里手动创建骨架，再把顶点组权重转移到新的骨架修改器上。推荐流程是：先新建一个Armature对象，根据角色身体结构添加骨骼，然后为网格添加数据传递修改器，将顶点组权重映射到骨骼顶点组。

需要注意的是，数据传递的映射方式会直接影响权重质量。对于角色网格，选择按最近面插值通常比按最近顶点更平滑；如果网格拓扑复杂，可以先烘焙高模权重到低模，再用权重渐变工具修正关节弯曲区域。完成权重转移后，需要通过权重归一化确保每个顶点的总权重为1，并删除权重为0的顶点组，避免导出后出现蒙皮变形错误。

下面这段Blender Python脚本演示了从顶点组创建骨架并自动建立父子关系的核心步骤。假设源网格名称是MeshyCharacter，新建骨架名称是Armature，并且已经手动在骨架中添加了对应骨骼。

import bpy
source_obj = bpy.data.objects["MeshyCharacter"]
target_arm = bpy.data.objects["Armature"]
# 先添加数据传递修改器，将顶点组权重转移到骨架对应的顶点组
dt = source_obj.modifiers.new(name="TransferWeights", type='DATA_TRANSFER')
dt.object = target_arm
dt.use_vert_data = True
dt.data_types_verts = {'VGROUP_WEIGHTS'}
dt.vert_mapping = 'NEAREST_FACE_INTERPOLATED'
# 设置父子关系，自动绑定到骨架
bpy.context.view_layer.objects.active = target_arm
source_obj.select_set(True)
target_arm.select_set(True)
bpy.ops.object.parent_set(type='ARMATURE_AUTO')

脚本执行后，网格会获得Armature修改器并关联到骨架。此时可以在姿态模式下旋转骨骼，检查蒙皮是否正常。如果某些顶点被拉长或错位，可以回到权重绘制模式，用平滑或模糊笔刷修正。修复完成后，导出前记得应用数据传递修改器，或者直接在导出设置中勾选应用修改器，防止下游工具忽略未烘焙的修改器。

在实际修复中，还经常遇到顶点组名称与新建骨骼名称不一致的情况。例如平台导出的顶点组可能带有前缀或后缀，直接转移权重会导致骨骼修改器找不到对应的顶点组。建议先把源网格的顶点组重命名为与骨架骨骼完全一致的名称，或者使用脚本批量替换名称中的非法字符。这样可以避免权重转移后出现骨骼看似存在但模型完全不动的情况。

三、格式兼容与导出参数建议

不同引擎对骨骼格式的支持并不一致。GLB和glTF在Web端、Three.js以及移动端AR应用中表现稳定，因为Khronos规范明确定义了skin和joints。但部分旧版Unity对glTF的骨骼解析存在缺陷，可能无法识别非标准命名的关节。FBX则在Unity、Unreal和Maya等传统DCC工具中支持更好，但FBX文件版本和坐标轴方向会影响导入结果。USDZ是Apple生态的偏好格式，骨骼动画使用SkelAnimation和SkelBindingAPI，兼容性受iOS版本影响。

导出时需要根据目标平台切换参数。例如在Blender导出GLB时，必须勾选Skinning和Include All Bones，否则仅导出网格。导出FBX时，建议设置Path Mode为Copy，并关闭Bake Animation，防止烘焙过程破坏原有骨骼层级。对于Unity项目，若导入后发现骨骼仍在层级视图中但角色无法播动画，通常不是骨骼丢失，而是Rig被设为Generic但动画类型不匹配，在导入器里切换为Humanoid可重新映射骨骼。

如果需要在多个DCC工具之间反复传递模型，推荐使用GLB作为中间格式，因为它基于JSON和二进制数据，骨骼引用关系更透明。FBX虽然流行，但二进制结构封闭，不同版本之间的兼容性容易出问题。日常流程可以遵循一个原则：从Meshy导出后，先导入Blender检查并修复骨骼，再用Blender二次导出为目标格式，而不是直接使用平台原始导出文件。

import bpy
bpy.ops.export_scene.gltf(
    filepath="C:\\models\\character_fixed.glb",
    export_format='GLB',
    export_skins=True,
    export_morph=False,
    export_animations=False,
    export_apply=True
)

总结来说，Meshy导出骨骼丢失通常不是不可逆的损坏，而是缺少了正确的上下文。通过检查顶点组、重建骨架关联，并选择适合目标平台的导出参数，可以大幅减少重复工作。