Blender导出GLB后Three.js加载材质丢失？

Question

Blender导出GLB后Three.js加载时材质丢失（如变黑、纯白或无贴图），是高频痛点。根本原因常在于：① Blender中未正确连接 Principled BSDF 的 Base Color、Normal、Metallic/Roughness 等输出至材质输出节点（尤其遗漏 Normal Map 经“Normal Map”节点转换）；② 贴图路径未嵌入GLB（导出时未勾选“Include > Images > Embed”）；③ 使用了GLTF 2.0不支持的节点（如Bump、Displacement、自定义ShaderNode）或非PBR工作流（如漫反射+高光贴图混用）；④ 法线/切线未在Blender中生成（需在Object Data Properties → Geometry → Normals → “Auto Smooth” + 勾选“Face Corner Normals”并应用）。Three.js r160+虽增强兼容性，但仍严格遵循glTF规范——任何超规材质都将被降级为默认MeshStandardMaterial（无纹理、参数归零）。建议导出前用[glTF Validator](https://github.khronos.org/glTF-Validator/)校验，并在Blender中启用“GLTF Exporter: Show Export Options”逐项核对。

Answer 1

```html

一、现象层：Three.js中GLB材质异常的典型表现

加载GLB后模型呈现纯黑（material.emissive未设但环境光不足）、纯白（baseColorFactor被错误覆盖为[1,1,1,1]）、贴图完全缺失（UV可见但纹理为空）、法线失效导致高光扁平化——这些并非Three.js渲染器Bug，而是glTF资产在语义层面已“失真”。r160+版本中，GLTFLoader会静默丢弃不合规材质节点，降级为无纹理的MeshStandardMaterial，且material.color强制归零，造成视觉断层。

二、协议层：glTF 2.0对PBR材质的刚性约束

glTF规范仅定义metallicRoughness和specularGlossiness（已废弃）两种工作流，Principled BSDF必须严格映射至标准字段。关键映射关系如下：

Blender节点输出	glTF语义字段	是否必需
Base Color → Color Texture	pbrMetallicRoughness.baseColorTexture	✓（若使用贴图）
Normal → Normal Map节点→ShaderNode	normalTexture	✓（需经Normal Map节点转换，不可直连）
Metallic/Roughness → Separate RGB→Scalar	pbrMetallicRoughness.metallicFactor/roughnessFactor	✗（可由贴图驱动）

三、建模层：Blender材质节点链的合规性检查清单

1. 确认Principled BSDF所有输入端口均来自标准节点（禁用Bump、Displacement、Group内自定义ShaderNode）；
2. Normal贴图必须经Normal Map节点（非Bump Map），且Space设为Tangent；
3. 金属度/粗糙度若用贴图，须用Separate RGB拆分G/B通道，并分别连接至对应输入；
4. 所有图像纹理节点右键→External Data → Pack into .blend，避免路径断裂；

四、导出层：GLB嵌入与验证双轨机制

导出设置中必须启用：
✅ Include > Images > Embed（否则贴图路径丢失）
✅ Materials > Export Materials
✅ Geometry > Normals > Export Normals（否则face corner normals不写入）
⚠️ 禁用Draco Compression（调试阶段易掩盖元数据问题）

五、验证层：glTF Validator与Three.js运行时诊断

使用官方验证器可定位具体违规项，例如：

{
  "code": "MISSING_NORMAL_TEXTURE",
  "message": "Normal texture is required when 'normalTexture' is present in material.",
  "severity": "ERROR"
}

同时，在Three.js中注入调试钩子：

loader.setMaterials((materials) => {
  materials.forEach(m => {
    if (m.isMeshStandardMaterial && !m.map) {
      console.warn('DOWNGRADED MATERIAL:', m.name);
    }
  });
  return materials;
});

六、修复层：从Blender到Three.js的端到端流程图

graph LR A[Blender材质编辑] --> B{Principled BSDF合规？} B -->|否| C[替换Bump为Normal Map节点
拆分Metallic/Roughness通道] B -->|是| D[检查法线生成] D --> E[Object Data Properties → Normals → Auto Smooth + Face Corner Normals] E --> F[导出前Pack Images & Embed] F --> G[glTF Validator校验] G -->|ERROR| H[返回Blender修正] G -->|OK| I[Three.js GLTFLoader加载] I --> J[检查material.userData.gltfExtensions]

七、进阶层：Three.js r160+的材质兼容性增强与陷阱

r160引入dracoLoader.setDecoderPath和meshoptDecoder支持，但材质解析逻辑未放宽。新增useLegacyLights: false默认启用物理光照模型，若GLB中emissiveFactor为[0,0,0]且环境光过弱，仍显黑——此时需同步调整scene.environment或添加RectAreaLight。另注意：Three.js不会自动补全缺失的tangent属性，若Blender未生成切线，法线贴图将彻底失效。

八、工程层：CI/CD中自动化材质合规检查

可在构建流水线中集成：

• Python脚本调用gltf-validator --quiet model.glb并捕获exit code；
• 使用@gltf-transform/cli检查纹理分辨率是否为2的幂次（非规范但影响WebGPU兼容性）；
• 通过gltfjsx生成TSX时添加--types参数，暴露材质字段类型，辅助前端强约束。

九、认知层：为何“看起来正常”的Blender预览≠GLB合规？

Blender视窗着色器（Workbench/Eevee/Cycles）各自实现材质渲染管线，而glTF导出器仅提取符合Khronos定义的**语义化子集**。例如：Cycles中Layer Weight节点可产生边缘光效果，但该节点无glTF等价物，导出时被完全剥离——这解释了为何“Blender里很炫酷，Three.js里变灰块”。本质是**渲染抽象层级错位**：Blender是通用渲染器，glTF是跨引擎交换格式，二者目标函数不同。

十、终极实践：五步黄金验证法

1. 在Blender中启用Viewport Shading → Rendered并切换至Eevee（最接近glTF PBR）；
2. 导出前执行Object → Shade Smooth + Auto Smooth（30°阈值）；
3. 导出选项勾选Embed Textures与Export Normals；
4. 上传GLB至glTF Validator，确保0 ERROR；
5. 在Three.js中用console.log(gltf.materials)确认map、normalMap、metalnessMap字段存在且非null。

```