1. 为什么我要用 Blender MCP 搭一个仓储数字孪生
第一次听到“数字孪生”这个词，是在一个做智能仓储的朋友那里。他给我看他们新上线的系统：屏幕上是一个三维仓库，货架、叉车、传送带全都在动，点一下某个货位，右侧就弹出库存数量、入库时间、周转率。当时我第一反应是——这不就是个 3D 可视化页面吗？后来自己动手做才发现，事情远没有这么简单。
数字孪生和普通 3D 展示最大的区别在于“孪生”两个字。普通 3D 页面是静态的、装饰性的，模型摆在那里好看就行；而数字孪生要求虚拟场景和真实业务数据保持同步映射，货架上的货位状态变了，3D 场景里对应的格子颜色、数量、标签都得跟着变。这就意味着，模型不能是“一坨死模型”，它必须带着结构化的语义信息——哪个 mesh 对应哪个货位、哪个货架、哪条通道。
我这次要做的，是一个智慧仓储的数字孪生原型。核心工具链是Blender + MCP + Three.js。Blender 负责建模和场景组织，MCP（Model Context Protocol）负责把 Blender 里的场景结构、对象属性暴露给外部程序调用，Three.js 负责在浏览器里做实时渲染和交互。这套组合的好处是：建模在专业工具里完成，数据接口标准化，前端渲染轻量化，三者各司其职。
这篇文章是“上篇”，重点放在场景搭建和 MCP 打通这一段。也就是说，我会把仓库的 3D 场景在 Blender 里建好、组织好，然后通过 MCP 把场景里的对象信息暴露出来，为下篇的前端数据绑定和实时同步打基础。如果你正在做数字孪生、3D 可视化、或者想找一个从建模到数据接口的完整链路参考，这篇内容应该能帮你少走不少弯路。
需要提前说明的是，我用的 Blender 是 4.x 版本，MCP 部分走的是 Blender 的 Python API 加一个本地服务桥接的方案。整个流程我反复跑过几遍，中间踩的坑不少，下面会一个个拆开讲。
2. 智慧仓储场景在 Blender 里的建模与语义组织
2.1 仓库布局的模块化拆分思路
很多人做 3D 场景，习惯一上来就堆模型，货架、箱子、地面全往一个文件里塞。做纯展示没问题，但做数字孪生就是灾难。因为数字孪生的核心是“数据映射”，你必须在建模阶段就把场景拆成有逻辑层级的模块，否则后面根本没法把业务数据对应到具体的 3D 对象上。
我的做法是按“区域—货架—货位”三级来拆。整个仓库先分成几个功能区：入库区、存储区、拣货区、出库区。每个区域下面挂若干货架，每个货架下面再挂具体的货位。这个层级关系在 Blender 里用 Collection（集合）和 Empty（空物体）来表达。
具体操作上，我会先建一个顶层 Empty，命名为Warehouse_Root，然后下面挂Zone_Inbound、Zone_Storage、Zone_Picking、Zone_Outbound四个子 Empty。每个 Zone 下面再挂货架的 Empty，货架下面挂货位的 Empty。真正的 mesh 对象作为货位 Empty 的子物体。这样整个场景的层级结构就是一棵清晰的树，后面 MCP 读取的时候可以直接遍历这棵树拿到完整的语义结构。
提示：Empty 在 Blender 里不参与渲染，但它是组织层级的最佳工具。用 Empty 做“逻辑节点”，用 mesh 做“视觉表现”，两者分离，后期改起来非常灵活。
为什么非要这么拆？因为数字孪生里最常见的操作是“根据货位编号找到对应的 3D 对象，然后改它的颜色或显示状态”。如果你的场景是一堆平铺的 mesh，没有层级、没有命名规范，那你就只能靠遍历所有对象、比对名字来查找，效率极低且容易出错。有了层级树，查找就变成了“从根节点逐级定位”，逻辑清晰，代码也好写。
2.2 货架与货位的参数化建模
货架是仓储场景里重复度最高的物体。一个仓库可能有几十上百个货架，每个货架结构一样，只是位置和尺寸不同。这种场景绝对不能用“复制粘贴再手动调”的方式，必须参数化。
我的做法是写一个 Blender Python 脚本，用参数控制货架的生成。核心参数包括：货架层数、每层货位数、货位宽度、货位深度、货位高度、立柱截面尺寸。脚本跑一遍，就能按参数生成一个完整的货架，并且自动把每个货位建成独立的 mesh 对象，命名规则是Rack_{货架编号}_Level_{层号}_Slot_{货位号}。
这里有个细节值得展开：货位的 mesh 到底该用多大的粒度？我试过两种方案。方案一是整个货架一个 mesh，货位只是贴图上的格子；方案二是每个货位一个独立 mesh。方案一性能好，但没法单独控制某个货位的颜色和状态；方案二对象数量多，但每个货位都能独立操作。数字孪生场景下，我选方案二，因为“单个货位状态变化”是核心需求。为了控制性能，货位的 mesh 用最简单的立方体，不加倒角、不加细分，材质用纯色，靠前端 Three.js 的实例化渲染来扛量。
参数化建模的另一个好处是“改需求不返工”。比如客户说货架要从 5 层改成 6 层，我只需要改一个参数重新跑脚本，不用手动去调。这个思路在做数字孪生项目时特别重要，因为业务需求变更是常态，建模阶段就要为变更留好接口。
2.3 命名规范：数字孪生的“身份证”体系
如果说层级结构是骨架，那命名规范就是数字孪生的“身份证”体系。我在这上面吃过大亏。早期做的一个项目，货位命名是随手起的，有的叫Box_01，有的叫货位A，有的干脆是 Blender 默认的Cube.023。结果到了数据绑定阶段，前端要根据货位编号找对象，根本对不上，最后只能返工重命名。
后来我定了一套强制规范，所有对象命名必须遵循类型_区域_货架_层_位的格式。比如Slot_Storage_R01_L03_S05表示存储区 1 号货架第 3 层第 5 个货位。货架本身叫Rack_Storage_R01，区域叫Zone_Storage。这套命名看起来啰嗦，但它保证了每个对象的名字都是全局唯一的、可解析的。前端拿到一个货位编号，直接拼出对象名就能找到对应的 mesh，不需要额外的映射表。
命名规范还有一个隐藏价值：它让场景具备了“自描述性”。任何人打开这个 Blender 文件，看名字就知道每个对象是什么、在哪里。团队协作时，这一点能省掉大量沟通成本。
2.4 材质与视觉分层：让状态可被“看见”
数字孪生场景里的颜色不是随便选的，每一种颜色都承载着业务含义。比如绿色代表货位空闲，蓝色代表有货，黄色代表拣货中，红色代表异常。这些颜色必须在建模阶段就规划好，并且通过材质的方式组织起来。
我的做法是建一套“状态材质库”，每个状态一个材质，命名如Mat_Status_Idle、Mat_Status_Occupied、Mat_Status_Picking、Mat_Status_Error。货位 mesh 默认挂Mat_Status_Idle，前端根据数据切换材质。这里要注意，材质切换在 Three.js 里是通过替换 material 实现的，所以 Blender 导出的模型必须保留材质槽信息，不能合并材质。
另外，场景的视觉分层也很重要。地面、墙体、通道这些“背景元素”用低饱和度的灰色系，货架用中性色，货位用高饱和度的状态色。这样视觉焦点自然落在货位上，业务状态一目了然。我见过一些项目，背景做得花里胡哨，货位状态反而看不清，这就是视觉层级没做好。
3. Blender MCP 的接入原理与本地桥接搭建
3.1 MCP 到底解决了什么问题
在讲具体搭建之前，得先说清楚 MCP 在这个项目里的角色。MCP 全称 Model Context Protocol，它的核心作用是“让外部程序能够以标准化的方式访问和操作模型环境里的资源”。放到 Blender 场景里，就是让一个外部进程（比如我的前端服务或者数据处理脚本）能够查询 Blender 场景里有哪些对象、每个对象的属性是什么、层级关系怎样，甚至能够反向修改场景。
没有 MCP 的时候，我要么把 Blender 场景导出成 glTF 再在前端解析，要么在 Blender 里跑脚本把数据写成 JSON 文件再读。这两种方式都是“离线”的，场景改了就得重新导出。MCP 的价值在于它提供了一个“在线”的接口，Blender 开着，外部程序就能实时读取场景状态。对于数字孪生这种需要频繁迭代场景的项目，这个能力非常关键。
需要说明的是，Blender 本身并没有官方的 MCP 实现，我这里用的是“Blender Python API + 本地 Socket 服务”的桥接方案。思路是在 Blender 里跑一个 Python 脚本，启动一个本地 Socket 服务，监听外部请求；外部程序通过 Socket 发送指令，Blender 端解析指令、调用 Blender API 执行操作、把结果返回。这个方案虽然不是标准 MCP 协议，但实现了 MCP 的核心思想——标准化访问模型上下文。
3.2 在 Blender 里启动本地服务
具体搭建分两步。第一步是在 Blender 里写一个服务脚本。这个脚本的核心逻辑是：创建一个 Socket 服务，绑定本地端口，循环接收请求，解析请求类型，调用对应的 Blender API，返回结果。
请求我用 JSON 格式，包含action和params两个字段。比如查询场景树，请求是{"action": "get_scene_tree", "params": {}}；查询某个对象的属性，请求是{"action": "get_object_info", "params": {"name": "Slot_Storage_R01_L03_S05"}}。Blender 端收到请求后，根据 action 分发到不同的处理函数。
这里有个关键点：Blender 的 Python 环境是单线程的，Socket 服务如果直接在主线程跑，会阻塞 Blender 的 UI。我的做法是用一个后台线程跑 Socket 服务，收到请求后通过bpy.app.timers把实际操作调度回主线程执行。这样既保证了服务持续监听，又不会卡住 Blender 界面。
import bpy import socket import json import threading def handle_request(request): action = request.get("action") params = request.get("params", {}) if action == "get_scene_tree": return build_scene_tree() elif action == "get_object_info": return get_object_info(params.get("name")) return {"error": "unknown action"} def socket_server(): server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.bind(("127.0.0.1", 9876)) server.listen(5) while True: conn, addr = server.accept() data = conn.recv(4096).decode("utf-8") request = json.loads(data) result = handle_request(request) conn.send(json.dumps(result).encode("utf-8")) conn.close() threading.Thread(target=socket_server, daemon=True).start()这段代码跑起来后，Blender 就在本地 9876 端口开了一个服务。外部程序连上这个端口，发 JSON 请求，就能拿到场景数据。
3.3 场景树的序列化输出
get_scene_tree这个接口是整个桥接的核心。它的作用是把 Blender 的场景层级完整地序列化成 JSON，供外部程序使用。实现上就是递归遍历bpy.data.objects，从根节点开始，把每个对象的名称、类型、位置、旋转、缩放、子对象列表都输出出来。
输出的 JSON 结构大概是这样：每个节点包含name、type、location、rotation、scale、children字段。type区分是 Empty 还是 Mesh，前端可以根据这个决定怎么处理。children是递归的子节点数组，这样整个场景就是一棵完整的树。
这里有个坑要注意：Blender 里的坐标是 Z 轴向上的，而 Three.js 是 Y 轴向上的。所以序列化的时候要么在 Blender 端做坐标转换，要么在前端做。我选择在前端做，因为 Blender 端保持原始数据更纯粹，转换逻辑放在渲染层更合理。转换规则是(x, y, z) -> (x, z, -y)，这个后面讲前端的时候会再展开。
3.4 对象属性的按需查询
场景树只包含结构信息，具体对象的详细属性需要单独查询。get_object_info接口接收对象名，返回该对象的完整信息：除了基础的位置旋转缩放，还包括材质列表、mesh 顶点数、自定义属性等。
自定义属性这块特别有用。我可以在 Blender 里给货位对象加自定义属性，比如slot_id、rack_id、capacity、current_stock，这些属性会跟着对象一起被查询出来。这样前端拿到的就不只是“这个 mesh 在哪”，而是“这个货位的业务属性是什么”。这一步是数字孪生“数据映射”的关键——3D 对象和业务数据通过自定义属性绑定在一起。
注意：Blender 的自定义属性支持字符串、整数、浮点数、数组等类型，但不支持嵌套字典。如果需要复杂结构，建议序列化成 JSON 字符串存进去，前端再解析。
4. 从 Blender 到 Three.js 的数据通道设计
4.1 为什么不在 Blender 里直接导出 glTF
很多人会问：既然最终要在 Three.js 里渲染，为什么不直接在 Blender 里导出 glTF，前端加载就行了，何必搞 MCP 这一套？
这个问题我认真想过。glTF 导出适合“静态场景”——模型建好、导出、前端加载、渲染，流程简单。但数字孪生场景是“动态”的：货位状态会变、货架可能增减、布局可能调整。如果每次改动都重新导出 glTF，前端就得重新加载整个模型文件，体验很差，而且导出过程本身也耗时。
MCP 方案的优势在于“增量更新”。场景结构变了，前端只需要重新拉一次场景树，对比差异，更新变化的部分，不用重新加载整个模型。对象属性变了，直接查那个对象的属性就行。这种增量式的数据通道，才是数字孪生该有的样子。
当然，glTF 也不是完全不用。我的做法是“结构走 MCP，几何走 glTF”。场景的层级结构、对象属性通过 MCP 实时查询；具体的 mesh 几何数据还是导出成 glTF，前端加载一次后缓存起来。两者结合，既保证了结构数据的实时性，又保证了几何数据的加载效率。
4.2 坐标系统转换的细节
前面提到 Blender 是 Z 轴向上，Three.js 是 Y 轴向上，这个转换必须处理好，否则整个场景会“躺倒”。
转换规则是：Blender 的(x, y, z)对应 Three.js 的(x, z, -y)。位置、旋转、缩放都要按这个规则转。旋转的转换稍微麻烦一点，因为欧拉角的顺序不同。Blender 默认是 XYZ 顺序，Three.js 也是 XYZ，但轴的定义不同，所以不能简单换轴，得用四元数做转换。
我的做法是在前端写一个convertTransform函数，统一处理所有对象的坐标转换。位置直接换轴，旋转用四元数转换，缩放因为是对称的，直接换轴就行。这个函数在加载场景树的时候对每个节点调用一次，保证所有对象都在正确的坐标系里。
function convertTransform(blenderObj) { const pos = new THREE.Vector3( blenderObj.location[0], blenderObj.location[2], -blenderObj.location[1] ); const quat = new THREE.Quaternion( blenderObj.rotation[0], blenderObj.rotation[2], -blenderObj.rotation[1], blenderObj.rotation[3] ); const scale = new THREE.Vector3( blenderObj.scale[0], blenderObj.scale[2], blenderObj.scale[1] ); return { pos, quat, scale }; }这段代码看着简单，但如果不做，场景里的货架会全部倒在地上，货位的位置也会错乱。我一开始就是漏了旋转转换，调了半天才发现问题。
4.3 对象查找与数据绑定的索引策略
前端拿到场景树后，需要建立一个“对象名到 Three.js 对象”的索引，这样业务数据来了才能快速找到对应的 3D 对象。我用的是一个 Map，key 是对象名，value 是 Three.js 的 Object3D 实例。
建立索引的时机是在场景树加载完成后，递归遍历整棵树，把每个节点都注册到 Map 里。这样后续无论是根据货位编号查对象，还是根据区域查货架，都是 O(1) 的查找。
数据绑定的逻辑是：业务数据里带着货位编号，前端用编号拼出对象名，从 Map 里查到对应的 mesh，然后更新它的材质或显示状态。比如收到{slot_id: "Storage_R01_L03_S05", status: "occupied"}，就找到Slot_Storage_R01_L03_S05这个 mesh，把材质换成Mat_Status_Occupied。
这套索引策略的关键是“命名规范必须严格”。只要命名规范统一，查找逻辑就极其简单。反过来，如果命名混乱，就得建额外的映射表，维护成本高且容易出错。
4.4 增量更新的触发机制
数字孪生的数据是实时变化的，前端不能一直轮询全量数据，得做增量更新。我的方案是：MCP 服务端维护一个“变更版本号”，每次场景结构或对象属性变化，版本号加一。前端定时查询版本号，发现变了就拉取变更列表，只更新变化的部分。
变更列表的粒度可以做到对象级：哪个对象变了、变了什么属性、新值是什么。前端拿到变更列表后，逐个应用。这样即使场景里有几千个对象，每次更新也只处理变化的那几个，性能开销很小。
这个机制在仓储场景里特别实用。比如一批货入库，只有对应的几个货位状态变了，前端就只更新那几个货位的颜色，其他对象不动。相比全量刷新，效率提升非常明显。
5. 实操中踩过的坑与排查链路
5.1 Blender 服务端口被占用导致连接失败
第一个坑是端口占用。我一开始把服务端口写死成 9876，结果有次重启 Blender 后服务起不来，排查半天发现是上一个 Blender 进程没完全退出，端口还被占着。
排查链路是这样的：先看 Blender 控制台有没有报错，发现OSError: [Errno 98] Address already in use；然后用lsof -i :9876查哪个进程占着端口，发现是残留的 Blender 进程；杀掉进程后重启，服务正常。
后来我改成“端口自动探测”：从 9876 开始试，被占用就试 9877，直到找到可用端口。同时把实际使用的端口写到一个临时文件里，外部程序读这个文件拿端口号。这样就不会因为端口冲突导致连接失败了。
5.2 场景树递归时的循环引用问题
第二个坑更隐蔽。Blender 的对象层级理论上是一棵树，但实际上可能存在“父子关系循环”——A 是 B 的父对象，B 又是 A 的父对象。这种情况在手动操作时不容易出现，但用脚本批量设置父子关系时可能误操作产生。
我的场景树序列化函数是递归的，遇到循环引用就会无限递归，直接把 Blender 卡死。第一次遇到时我还以为是 Blender 崩了，重启了好几次。
解决办法是在递归时维护一个“已访问集合”，每次进入一个对象前先检查是否已访问过，访问过就跳过。这样即使有循环引用，也不会无限递归。同时我在序列化结束后加了一个校验，如果发现循环引用就报警告，提示用户检查场景结构。
def build_scene_tree(obj, visited=None): if visited is None: visited = set() if obj.name in visited: return None visited.add(obj.name) node = { "name": obj.name, "type": obj.type, "location": list(obj.location), "rotation": list(obj.rotation_quaternion), "scale": list(obj.scale), "children": [] } for child in obj.children: child_node = build_scene_tree(child, visited) if child_node: node["children"].append(child_node) return node5.3 材质切换不生效的根因定位
第三个坑出在材质切换上。前端根据状态切换货位材质，代码逻辑没问题，但实际渲染出来颜色不变。排查过程比较曲折。
第一步，确认前端有没有拿到正确的状态数据——打印日志，数据是对的。第二步，确认有没有找到对应的 mesh——打印对象名，也找到了。第三步，确认材质有没有被替换——打印 mesh.material，发现材质对象确实换了，但渲染不变。
最后发现问题出在 Blender 导出的 glTF 上：多个货位共享了同一个材质实例，前端替换一个货位的材质时，实际上替换的是共享材质，但因为 Three.js 的材质缓存机制，渲染器没有重新编译着色器，所以视觉上没变化。
解决办法是在导出 glTF 时，给每个货位分配独立的材质实例，不要共享。或者在 Three.js 里替换材质时，显式设置material.needsUpdate = true，强制重新编译。我两个都做了，问题彻底解决。
5.4 大数据量下的场景树查询超时
第四个坑是性能问题。仓库场景有几千个货位，场景树序列化出来的 JSON 有几百 KB，前端查询一次要好几秒，体验很差。
优化分两步。第一步是“懒加载”：场景树只返回层级结构和对象名，不返回详细属性；具体属性按需查询。这样初始加载的数据量大幅减少。第二步是“分区域查询”：前端可以只查询某个区域下的对象，不用一次拉全场景。比如只查存储区，数据量就小很多。
优化后，初始加载时间从几秒降到几百毫秒，按需查询也是毫秒级响应。这个经验告诉我，数字孪生场景的数据通道设计，一定要考虑数据量，不能假设“数据不大”。
6. 场景验证：怎么确认 Blender 和前端对上了
6.1 用最小场景做端到端验证
搭完这套链路后，我没有直接上完整仓库场景，而是先做了一个“最小验证场景”：一个地面、一个货架、三个货位。用这个最小场景跑通“Blender 建模 → MCP 查询 → 前端渲染 → 状态切换”的完整流程。
最小场景的好处是“问题容易定位”。如果三个货位里有一个位置不对，一眼就能看出来是哪个环节的问题。如果直接上几千个货位的场景，出了问题根本不知道从哪查起。
验证的检查点有四个：场景树能不能正确拉取、坐标转换对不对、对象查找准不准、材质切换生不生效。四个都通过后，再逐步扩大场景规模，每次扩大都重新验证一遍。这种“小步快跑”的方式，比一次性搭完再调试高效得多。
6.2 坐标与层级的对照检查方法
坐标验证我用的方法是“打点对照”。在 Blender 里记录几个关键对象的坐标，比如货架原点、某个货位的中心点；然后在前端打印对应 Three.js 对象的世界坐标；两者按转换规则换算后对比，看是否一致。
层级验证用的是“路径打印”。在 Blender 里选中一个货位，看它的完整层级路径；在前端根据对象名反查，看能不能沿着父子关系一路找到根节点。两边路径一致，说明层级结构正确同步了。
这两个检查方法看着笨，但非常有效。数字孪生项目里，坐标和层级是最基础的东西，基础错了后面全错。花时间在这上面做验证，绝对值得。
6.3 状态切换的视觉回归测试
状态切换的验证，我做了一个简单的“视觉回归测试”：准备一组测试数据，覆盖所有状态（空闲、有货、拣货中、异常），然后逐个切换，截图对比。
具体操作是：前端加载场景后，依次把某个货位设成四种状态，每次截图；然后人工检查截图里货位颜色是否符合预期。这个测试跑一遍只要几分钟，但能发现很多视觉层面的问题，比如颜色不对、材质没切换、多个货位互相影响等。
我还把这个测试脚本化了，每次改完代码自动跑一遍，截图存到指定目录。这样回归测试的成本几乎为零，但能保证状态切换逻辑始终正确。
7. 上篇收尾：这套链路目前的边界在哪
做到这里，Blender 场景建好了，MCP 桥接通了，前端能拉到场景树并正确渲染了，状态切换也验证过了。但要说这套方案已经完美，那是假话。它目前有几个明确的边界，我得说清楚。
第一，MCP 桥接方案依赖 Blender 进程常驻。如果 Blender 关了，服务就断了。生产环境里这显然不合适，所以下篇我会讲怎么把场景数据持久化，让前端不依赖 Blender 实时运行。
第二，当前的增量更新是“轮询式”的，前端定时查版本号。这种方式实现简单，但实时性有上限，而且有无效轮询的开销。下篇会换成“推送式”，服务端主动推变更给前端。
第三，场景规模上去之后，Three.js 的渲染性能是瓶颈。几千个独立 mesh 的渲染开销不小，需要做实例化渲染或者 LOD 优化。这部分也会在下篇展开。
我个人在实际操作中的体会是，数字孪生项目最难的不是某一项技术，而是“链路的完整性”。从建模到数据接口到前端渲染，任何一环出问题，整个系统就跑不起来。所以我的建议是：先把最小链路跑通，再逐步加功能、加规模。不要一上来就追求大而全，那样很容易卡在某个环节出不来。
最后分享一个小技巧：在 Blender 里给对象加自定义属性时，属性名统一加个前缀，比如dt_（digital twin 的缩写），这样在场景树里一眼就能区分哪些是业务属性、哪些是 Blender 自带属性。这个习惯能省掉很多混淆。
