1. 为什么我要用 Blender MCP 来做仓储数字孪生

第一次听到"数字孪生"这个词是在一个物流行业的交流会上，当时有人展示了一个仓库的三维可视化系统，货架、叉车、传送带全都在屏幕上实时跑着，点击任何一个货位就能弹出库存信息。我当时的第一反应是：这东西做起来肯定很贵。后来自己动手研究了一段时间才发现，如果选对了工具链，个人开发者也能搭出一套像样的智慧仓储数字孪生原型。

这次我选的技术路线是Blender MCP + Three.js。Blender 负责三维场景的建模和资产管理，MCP 作为中间层把 Blender 的能力暴露出来，Three.js 负责在浏览器端做最终的渲染和交互。你可能会问，为什么不用 Unity 或者直接用 Three.js 从零建场景？原因很简单：Blender 的建模效率远超代码手搓几何体，而 Three.js 在 Web 端的轻量化和可分享性是 Unity WebGL 比不了的。MCP 则解决了 Blender 和外部程序之间的通信问题，让整个流程可以自动化。

这篇文章主要面向三类人：一是做前端可视化但没怎么碰过三维建模的开发者；二是做物流仓储系统、想给现有 WMS 加一层三维可视化的工程师；三是对数字孪生感兴趣、想找一个完整项目练手的学生或爱好者。我会把整个流程拆开讲清楚，包括 Blender 里怎么建仓储场景、MCP 怎么配置、数据怎么从 Blender 流到 Three.js、以及我在实操中踩过的那些坑。

注意：本文假设你对 JavaScript 和基础的 Three.js 有了解，但不需要你精通 Blender。所有 Blender 操作我都会给出具体的快捷键和参数。

2. 智慧仓储数字孪生的核心需求拆解

2.1 数字孪生到底"孪"的是什么

很多人对数字孪生的理解停留在"三维可视化"层面，觉得把仓库用 3D 画出来就叫数字孪生了。这个理解不太准确。三维可视化只是外壳，数字孪生的核心在于物理实体和数字模型之间的数据映射关系。

放到仓储场景里，一个完整的数字孪生至少需要三层：

• 几何层：仓库的建筑结构、货架布局、设备外形，这是最直观的部分，也是 Blender 最擅长的。
• 状态层：每个货位的占用情况、每台设备的运行状态、每条传送带的流速，这些数据通常来自 WMS 或 IoT 传感器。
• 交互层：用户点击某个货架能看到库存详情，拖动时间轴能回放历史状态，这些是 Three.js 负责的。

我见过不少项目只做了几何层就宣称是数字孪生，结果客户一看，货架永远是空的，叉车永远不动，那跟看一张 3D 效果图有什么区别。所以在这个项目里，我从一开始就把三层都考虑进去了。

2.2 为什么选 Blender 而不是代码建场景

用 Three.js 直接写代码建一个仓库场景不是不行，但效率差距非常大。我做过对比：用代码手搓一个包含 4 排货架、每条货架 5 层、每层 10 个货位的场景，光是计算每个货位的坐标就要写一大堆循环逻辑，而且调整布局的时候要改代码重新跑。用 Blender 的话，建一个货架单元，然后用阵列修改器复制，拖一拖参数就完事了。

更关键的是材质和光照。Blender 的材质节点系统可以做出非常逼真的金属、塑料、地面反射效果，导出的 glTF 模型自带 PBR 材质，Three.js 直接加载就能用。如果纯用代码写 Shader 去模拟这些效果，工作量至少翻三倍。

还有一个容易被忽略的点：Blender 的几何体优化能力。仓库场景里货架和货位的数量可能上千，如果不做优化，导出的模型面数会爆炸，浏览器直接卡死。Blender 提供了 Decimate 修改器、LOD 生成等工具，可以在导出前把面数压下来。

2.3 MCP 在这个流程里扮演什么角色

MCP 全称是 Model Context Protocol，原本是为 AI 模型和外部工具之间通信设计的协议。但在 Blender 场景下，它的作用更像是一个自动化桥梁。传统的 Blender 工作流是：手动建模 → 手动导出 glTF → 手动放到项目目录 → 前端加载。每次模型有改动，这套流程就要重来一遍。

有了 Blender MCP 之后，我可以让 Blender 通过脚本自动导出模型、自动上传到指定目录、甚至自动通知前端刷新。对于仓储数字孪生这种需要频繁调整布局的项目来说，这个自动化流程节省的时间非常可观。

提示：MCP 的配置方式在不同版本的 Blender 里略有差异，建议用 Blender 4.0 以上版本，插件生态更完善。

3. Blender 仓储场景的建模实操

3.1 从零搭建一个标准货架单元

打开 Blender 之后，先把默认的立方体删掉（选中按 X），然后按 Shift+A 添加一个新的立方体。按 Tab 进入编辑模式，按 S 缩放，把它压成一个扁平的板子，这就是货架的层板。尺寸方面，我建议按照真实仓储的标准来：层板长 2.7 米、宽 1.1 米、厚 0.05 米。这个尺寸对应的是最常见的横梁式货架，一个货位放一个标准托盘。

层板做好之后，按 Tab 回到物体模式，按 Shift+D 复制一层，按 Z 沿垂直方向移动 0.4 米，这就是第二层。重复这个操作做出 5 层，整个货架的高度就是 2 米左右。然后添加立柱：Shift+A 添加立方体，缩放成 0.08 x 0.08 x 2.0 的长条，放在四个角上。

这里有个技巧：不要手动一个个复制立柱。选中一根立柱，添加 Array 修改器，设置 Count 为 4，偏移量根据货架宽度来算。这样调整货架尺寸的时候，立柱会自动跟着变。

做完一个货架单元之后，选中所有部件，按 Ctrl+J 合并成一个物体，命名为 "Rack_Unit"。然后添加 Array 修改器，X 方向偏移 2.8 米（层板长 2.7 米加 0.1 米间隙），Count 设为 10，一排货架就出来了。再用同样的方法在 Y 方向阵列 4 排，整个仓库的货架布局就完成了。

3.2 货位编号与顶点色标记

数字孪生和普通 3D 场景最大的区别在于，每个货位都需要有唯一标识。在 Blender 里，我用的方法是给每个货位分配不同的顶点色。具体操作是：选中一个货位对应的面，进入顶点绘制模式，给它涂一个特定的颜色。这个颜色值在导出 glTF 之后会保留在顶点属性里，Three.js 可以通过读取顶点色来识别不同的货位。

你可能会问，为什么不用命名对象的方式？因为一个货架上有 50 个货位，如果每个货位都是独立对象，场景里就会有几百个对象，管理起来很麻烦。用顶点色的话，整个货架是一个对象，但每个货位的面有不同的颜色标记，既减少了对象数量，又保留了标识能力。

具体操作步骤：

1. 选中货架对象，按 Tab 进入编辑模式
2. 按 Ctrl+Tab 切换到面选择模式
3. 选中一个货位的顶面
4. 在顶点绘制模式下，用颜色选择器选一个颜色涂上去
5. 重复以上步骤，给每个货位涂不同的颜色

颜色编码规则我建议用 RGB 三个通道分别表示排、列、层。比如 R 通道表示第几排，G 通道表示第几列，B 通道表示第几层。这样在 Three.js 里读取顶点色之后，直接解码就能得到货位编号。

3.3 材质与光照的取舍

仓储场景的材质不需要太花哨，但有几个地方值得注意。地面建议用深灰色的哑光材质，粗糙度设到 0.8 左右，这样不会产生太强的反射干扰视线。货架的金属部分用 Metallic 0.9、Roughness 0.3 的参数，看起来有金属质感但不会像镜子一样反光。

光照方面，千万不要用 Blender 的物理光照直接导出。Blender 的 Cycles 渲染器效果很好，但导出 glTF 之后光照信息会丢失。正确的做法是在 Blender 里只做基础的环境光设置，把主要的光照工作交给 Three.js 来做。我通常会在 Blender 里加一个简单的 Sun 光源，强度调到 1.0，然后在 Three.js 里用 AmbientLight + DirectionalLight 重新打光。

注意：导出 glTF 时，材质节点里如果有 Blender 特有的节点（比如 Musgrave 纹理），导出后会丢失。建议只用 Principled BSDF 节点，这是 glTF 标准支持的。

4. MCP 配置与模型导出流水线

4.1 Blender MCP 插件的安装与配置

Blender MCP 的安装方式和普通插件不太一样，它需要同时配置 Blender 端的插件和外部服务的连接。首先在 Blender 的偏好设置里找到插件面板，搜索 MCP 相关的插件并启用。启用之后，在 3D 视图的侧边栏（按 N 键调出）会出现一个 MCP 面板。

配置项主要有几个：

• 服务端口：默认是 9876，如果被占用可以改成其他端口
• 导出路径：设置 glTF 文件的输出目录，建议设成前端项目的 public/models 目录
• 自动导出：勾选之后，每次保存 Blender 文件都会自动导出 glTF

这里有个坑：Blender MCP 插件对 Blender 版本有要求。我在 Blender 3.6 上试过，插件能装但导出的时候会报错。换成 4.0 之后就正常了。如果你遇到 "MCP export failed" 之类的错误，先检查版本。

4.2 glTF 导出参数怎么调

Blender 导出 glTF 的参数很多，但仓储场景真正需要关注的就这么几个：

Draco 压缩特别值得说一下。一个包含 4 排货架、每排 10 个单元、每个单元 5 层的场景，不做压缩的话 glb 文件大概 15MB 左右。开启 Draco 之后能压到 3MB 以内，加载速度快了不止一点。但要注意，使用 Draco 压缩的模型在 Three.js 里需要额外加载 DRACOLoader，这个后面会讲。

4.3 自动化导出脚本的编写

MCP 面板上手动点导出按钮只能应付偶尔的改动，如果场景频繁调整，最好写一个自动化脚本。Blender 支持 Python 脚本，可以在脚本里调用导出 API：

import bpy # 设置导出路径 export_path = "/path/to/project/public/models/warehouse.glb" # 导出 glTF bpy.ops.export_scene.gltf( filepath=export_path, export_format='GLB', export_materials='EXPORT', export_colors=True, export_draco_mesh_compression_enable=True, export_draco_mesh_compression_level=6, export_yup=True ) print(f"Exported to {export_path}")

把这个脚本保存成 .py 文件，在 Blender 的脚本编辑器里加载运行，或者通过命令行blender --background --python export.py来执行。配合 MCP 的自动导出功能，每次改完模型按 Ctrl+S 就能自动更新前端用的 glb 文件。

5. Three.js 端的加载与交互实现

5.1 场景初始化与模型加载

Three.js 端的代码结构我习惯分成三个模块：场景初始化、模型加载、交互逻辑。场景初始化部分包括创建 Scene、Camera、Renderer，以及设置基础光照。这部分代码比较标准，网上教程很多，我就不展开讲了。

模型加载部分有几个关键点。首先是 DRACOLoader 的配置：

import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js'; import { DRACOLoader } from 'three/examples/jsm/loaders/DRACOLoader.js'; const dracoLoader = new DRACOLoader(); dracoLoader.setDecoderPath('/draco/'); dracoLoader.setDecoderConfig({ type: 'js' }); const gltfLoader = new GLTFLoader(); gltfLoader.setDRACOLoader(dracoLoader); gltfLoader.load('/models/warehouse.glb', (gltf) => { const model = gltf.scene; scene.add(model); // 遍历模型，找到货架对象 model.traverse((child) => { if (child.isMesh && child.name.includes('Rack')) { // 处理货架 } }); });

DRACOLoader 的解码器文件需要从 Three.js 的 examples 目录里拷贝到 public 目录下，否则加载会报 404。这个坑我踩过好几次，每次部署到新环境都忘了拷。

5.2 顶点色解码与货位识别

模型加载进来之后，下一步是从顶点色里解码出货位信息。Three.js 的 BufferGeometry 里，顶点色存储在geometry.attributes.color里，每个顶点有 RGB 三个分量。读取方式如下：

const colors = geometry.attributes.color; const position = geometry.attributes.position; for (let i = 0; i < colors.count; i++) { const r = colors.getX(i); const g = colors.getY(i); const b = colors.getZ(i); // 解码货位编号 const row = Math.round(r * 255); const col = Math.round(g * 255); const layer = Math.round(b * 255); const slotId = `R${row}-C${col}-L${layer}`; // 存储货位信息 }

这里有个细节：顶点色在 glTF 里是线性空间的，Three.js 加载后可能会做 sRGB 转换。如果发现解码出来的数值不对，检查一下renderer.outputColorSpace的设置。我一般会把它设成THREE.SRGBColorSpace，然后在解码时做相应的逆转换。

5.3 射线检测与货位点击交互

用户点击货架时，需要判断点到了哪个货位。Three.js 提供了 Raycaster 来实现这个功能：

const raycaster = new THREE.Raycaster(); const mouse = new THREE.Vector2(); renderer.domElement.addEventListener('click', (event) => { const rect = renderer.domElement.getBoundingClientRect(); mouse.x = ((event.clientX - rect.left) / rect.width) * 2 - 1; mouse.y = -((event.clientY - rect.top) / rect.height) * 2 + 1; raycaster.setFromCamera(mouse, camera); const intersects = raycaster.intersectObjects(rackObjects); if (intersects.length > 0) { const hit = intersects[0]; const faceIndex = hit.faceIndex; // 根据 faceIndex 找到对应的货位 const slotInfo = getSlotFromFace(hit.object, faceIndex); showSlotDetail(slotInfo); } });

getSlotFromFace这个函数需要根据面的顶点索引去查顶点色，然后解码出货位编号。具体实现取决于你的模型结构，如果每个货位的面是连续的，可以直接用 faceIndex 除以每个货位的面数来算。

5.4 状态数据的动态映射

货位识别出来之后，下一步是把 WMS 的数据映射到三维场景上。我的做法是维护一个slotId -> mesh的映射表，当 WMS 推送数据更新时，根据 slotId 找到对应的货位，修改它的材质颜色。比如空货位用灰色，有货的用绿色，满货的用红色。

function updateSlotStatus(slotId, status) { const slot = slotMap.get(slotId); if (!slot) return; const color = statusColors[status]; slot.material.color.set(color); }

如果货位数量很多，逐个修改材质会有性能问题。优化方案是用 InstancedMesh，把所有货位合并成一个实例化网格，通过修改实例属性来更新颜色。不过 InstancedMesh 的射线检测和顶点色处理会复杂一些，建议先用普通 Mesh 跑通流程，性能不够了再优化。

6. 实操中踩过的坑与排查过程

6.1 模型加载后位置偏移的问题

第一次导出 glb 加载到 Three.js 里的时候，模型的位置完全不对，整个仓库飘在半空中。排查了半天，发现是 Blender 和 Three.js 的坐标系不一致导致的。Blender 默认 Z 轴向上，Three.js 默认 Y 轴向上。虽然导出 glTF 时勾选了 Y 轴向上，但模型的原点位置还是有问题。

解决办法是在 Blender 里把模型的原点设置到仓库地面的中心位置。具体操作：选中所有对象，按 Shift+S 调出吸附菜单，选择 "Cursor to World Origin"，然后按 Ctrl+Shift+Alt+C 设置原点为 3D 光标位置。这样导出的模型原点就在地面中心，加载到 Three.js 里位置就对了。

6.2 Draco 压缩导致的顶点色丢失

开启 Draco 压缩之后，发现顶点色读不出来了。查了资料才知道，Draco 压缩默认不保留顶点色属性。需要在导出时显式指定保留顶点色。在 Blender 的导出参数里，除了勾选 "顶点色" 之外，还要确保 Draco 的压缩设置里没有排除 color 属性。

如果还是不行，可以试试降低 Draco 压缩级别。我实测下来，压缩级别 6 的时候顶点色会丢，降到 3 就正常了。文件体积会大一些，但至少功能是完整的。

6.3 大量货位导致的渲染卡顿

场景里如果有几千个货位，每个货位都是独立的 Mesh，浏览器帧率会掉到 20 以下。这个问题的根源是Draw Call 太多。每个 Mesh 至少一次 Draw Call，几千个就是几千次，GPU 再强也扛不住。

优化方案有三个层次：

1. 合并几何体：把同一排货架的所有货位合并成一个 BufferGeometry，用顶点色区分不同货位。这样 Draw Call 从几千降到几十。
2. 使用 InstancedMesh：如果货位的几何形状完全相同，只是位置和颜色不同，用 InstancedMesh 是最优解。一次 Draw Call 就能渲染所有货位。
3. LOD 分级：远处的货架用低面数模型，近处的用高面数模型。Three.js 的 LOD 对象可以自动根据距离切换。

我最后用的是方案一加方案三的组合。合并几何体之后 Draw Call 降到了 50 左右，再加上 LOD，帧率稳定在 60。

6.4 MCP 自动导出时的路径问题

MCP 自动导出功能配置好之后，有时候会报 "Export path not found" 的错误。排查发现是路径里的变量没有正确解析。MCP 的导出路径支持相对路径，但相对的是 Blender 文件所在的目录，不是项目根目录。如果 Blender 文件和前端项目不在同一个盘符下，相对路径就会失效。

解决办法是用绝对路径，或者在 MCP 配置里设置一个环境变量指向项目根目录，导出路径用环境变量拼接。我现在的配置是：

EXPORT_PATH = ${PROJECT_ROOT}/public/models/warehouse.glb

这样不管 Blender 文件放在哪里，导出路径都是对的。

7. 从原型到可用系统的扩展思路

7.1 实时数据接入的方案选择

原型跑通之后，下一步就是接入真实的仓储数据。常见的数据来源有三种：WMS 系统的数据库、IoT 传感器的 MQTT 消息、以及人工录入的 Excel 表格。不同的数据源接入方式不一样。

WMS 数据库的话，通常通过后端 API 做一层转发，前端定时轮询或者用 WebSocket 接收推送。MQTT 的话，前端可以用 MQTT.js 直接订阅主题，但要注意消息频率，太高的话需要做节流。Excel 导入适合演示场景，用 SheetJS 解析之后映射到货位。

我建议先用 WebSocket 做实时推送，因为仓储场景对实时性要求比较高，轮询会有延迟。WebSocket 的服务端可以用 Node.js 的 ws 库快速搭建，消息格式用 JSON，包含 slotId 和 status 两个字段就够了。

7.2 多楼层与多仓库的切换

单个仓库跑通之后，很自然会想到支持多楼层和多仓库。这个扩展的关键在于场景的组织方式。我建议把每个楼层做成一个独立的 Group，通过显示/隐藏 Group 来切换楼层。多仓库的话，每个仓库一个 glb 文件，按需加载。

切换的时候要注意相机的位置和视角。可以用 Tween.js 做平滑过渡，从当前视角飞到目标楼层的视角。这个体验比直接切换好很多。

7.3 性能监控与异常告警

数字孪生系统上线之后，需要监控两方面的指标：渲染性能和数据延迟。渲染性能可以用 Three.js 的renderer.info来获取，包括 Draw Call 数量、三角形数量、内存占用等。数据延迟的话，在 WebSocket 消息里带上时间戳，前端收到之后计算差值。

如果 Draw Call 超过阈值或者数据延迟超过 5 秒，就在界面上显示告警。这个功能在演示的时候特别有用，客户能看到系统是"活"的。

7.4 移动端适配的注意事项

仓储场景经常需要在平板或手机上查看，所以移动端适配是必须的。Three.js 在移动端的主要问题是性能和触控交互。性能方面，移动端 GPU 弱一些，需要降低模型精度和关闭一些特效。触控方面，点击事件要用 touchstart 而不是 click，射线检测的坐标转换也要相应调整。

还有一个容易被忽略的点：移动端的屏幕比例和桌面端差异很大，相机的 aspect 需要动态计算。我一般会在 resize 事件里同时更新相机的 aspect 和投影矩阵。

window.addEventListener('resize', () => { const width = window.innerWidth; const height = window.innerHeight; camera.aspect = width / height; camera.updateProjectionMatrix(); renderer.setSize(width, height); });

这段代码看起来简单，但如果不写，在手机上旋转屏幕之后画面就会变形。

8. 一些个人体会

这个项目从开始做到现在差不多两个月，中间经历了无数次"模型导出不对→排查→重新导出"的循环。最大的感受是，Blender 和 Three.js 之间的数据流转是最容易出问题的环节。坐标系、材质、顶点色、压缩格式，任何一个环节出问题都会导致前端显示异常。

我的建议是，在正式做复杂场景之前，先用一个最简单的立方体跑通整个流程：Blender 建一个带顶点色的立方体，导出 glb，Three.js 加载并读取顶点色。这个最小闭环跑通之后，再逐步增加复杂度。这样出问题的时候，排查范围小，定位快。

另外，MCP 的自动化确实能省不少事，但不要过度依赖。有些时候手动导出反而更可控，特别是调试阶段。等场景稳定了，再开启自动导出。

最后说一句，数字孪生这个方向目前还在快速发展，工具链也在不断更新。今天能用的方案，半年后可能有更好的替代。保持关注，但不要为了追新而追新，能解决问题的方案就是好方案。