1. 从零拆解：为什么选 Blender MCP 做仓储数字孪生
1.1 这个项目到底在解决什么问题
仓储数字孪生这个词听起来很唬人，但落到实际业务里，它要解决的核心问题其实非常朴素：让管理者在屏幕上看到一个和真实仓库同步运转的三维场景，并且能点、能查、能联动数据。传统做法要么是买一套昂贵的商业孪生平台，要么是前端团队从零手撸 Three.js 场景，前者贵且不灵活，后者开发周期长、美术资源难维护。
这个项目走的是另一条路：用Blender 作为三维资产的唯一生产源头，通过MCP（Model Context Protocol）把 Blender 和 AI 智能体打通，让 AI 直接理解场景结构、批量生成和调整货架、托盘、AGV 等模型，再导出到前端用 Three.js 渲染。标题里的 "Antigravity" 在这里扮演的是智能体执行环境与工具调度的角色，负责把自然语言指令翻译成对 Blender 的操作。
说白了，这套组合的价值在于：把"建模—调整—导出—前端接入"这条链路里的重复劳动交给 AI，人只负责把关和微调。适合谁看？三类人：做智慧园区/仓储可视化的前端工程师、想入门数字孪生的三维美术、以及需要快速出原型验证业务逻辑的产品或集成商。
1.2 为什么是 Blender + MCP，而不是纯前端建模
我试过直接在 Three.js 里用代码堆货架，一开始觉得挺爽，几十行代码就能摆一排立方体。但真实仓储场景一旦复杂起来——货架有横梁、立柱、层板，托盘上有货物，地面有分区标线，还有 AGV 小车——纯代码建模的维护成本会指数级上升。改一个货架尺寸，可能要动十几个参数；想换个货架样式，等于重写。
Blender 的优势在于它是参数化 + 可视化的。货架可以用几何节点（Geometry Nodes）做成参数化资产，改一个数值，整排货架跟着变。而 MCP 的价值在于，它让 AI 能"看懂"Blender 里的对象树、材质、变换信息，并且能执行脚本级的批量操作。举个实际例子：我要把仓库里 200 个货架统一改成三层结构，纯手工点要疯，写 Python 脚本也行，但有了 MCP，我直接说"把所有货架层板数量改为 3，间距 0.8 米"，智能体就能生成并执行对应的 Blender 操作。
这里要澄清一个常见误解：MCP 不是让 AI 直接"画模型"，它是让 AI 通过标准化协议调用 Blender 的能力。模型本身还是 Blender 的几何体，AI 做的是编排和参数控制。这个边界想清楚了，后面很多坑就能提前避开。
1.3 整体架构与技术选型逻辑
整个项目的架构可以拆成四层，我用一个表格说清楚每层的职责和选型理由：
| 层级 | 组件 | 职责 | 选型理由 |
|---|---|---|---|
| 资产生产层 | Blender + 几何节点 | 建模、参数化、材质、导出 | 免费、脚本能力强、glTF 导出成熟 |
| 智能调度层 | Antigravity + MCP Server | 解析指令、调用 Blender API | 协议标准化，工具可复用 |
| 数据转换层 | glTF/GLB 导出管线 | 压缩、优化、坐标转换 | Three.js 原生支持，体积可控 |
| 前端渲染层 | Three.js + WebGL | 场景加载、交互、数据绑定 | 生态成熟，社区案例多 |
选 glTF 而不是 FBX 或 OBJ，是因为 glTF 是"三维界的 JPEG"，专为实时渲染设计，支持 PBR 材质、动画、层级结构，Three.js 的 GLTFLoader 对它的支持也最完善。FBX 虽然 Blender 导出没问题，但前端解析要额外依赖，体积也大。OBJ 更不用说了，连材质都要单独配 MTL，不适合这种带材质和层级的场景。
坐标系的坑必须提前说：Blender 默认 Z 轴向上，Three.js 默认 Y 轴向上。导出 glTF 时 Blender 会自动做 Y-up 转换，但如果你在 Blender 里手动改了旋转，导出后可能出现模型"躺平"的情况。我的经验是，建模阶段就统一按 Blender 的 Z-up 来，导出时勾选 +Y Up，前端不要再手动旋转，否则后面调起来很痛苦。
2. 环境搭建与 Blender MCP 接入实操
2.1 Blender 侧的准备与参数化资产搭建
先把 Blender 装好，版本建议 4.0 以上，因为几何节点在新版本里更稳定。装完之后第一件事不是急着建模，而是规划资产命名规范。我踩过的坑是：一开始随手命名"Cube.001""Cube.002"，等到前端要按名字找货架时，完全对不上号。后来改成统一前缀：rack_开头是货架，pallet_是托盘，agv_是小车，floor_是地面分区。这个规范后面 MCP 批量操作和前端数据绑定都要用。
货架用几何节点做参数化，核心参数就几个：层数、层高、立柱间距、横梁厚度。我用一个"实例化"节点把单层货架复制成多层，再用"变换"节点控制间距。这样做的好处是，改一个参数整排货架联动，而且导出时几何体是合并的，不会产生几百个独立对象拖慢前端。
材质方面，仓储场景不需要太花哨，但有几个细节要注意：金属货架用 Principled BSDF，粗糙度给 0.4 左右，金属度 0.8，这样在 Three.js 里打光才有质感。地面用一张带网格线的贴图，比纯色更能体现空间感。贴图分辨率控制在 1024 以内，否则 GLB 体积会爆炸，前端加载卡顿。
提示：Blender 里做好的材质，导出 glTF 时只有 Principled BSDF 能被正确转换。如果你用了复杂的节点组，导出后可能变成默认灰色，这点务必在导出前用预览确认。
2.2 MCP Server 的配置与连接验证
MCP 的核心是让智能体能调用 Blender 的能力。配置思路是：在 Blender 里启用一个能接收外部指令的接口（通常通过 Blender 的 Python API 配合一个本地服务），然后在 Antigravity 侧配置 MCP Server 指向这个接口。
具体操作上，Blender 需要开启脚本执行权限，并加载一个负责监听和执行的 Python 脚本。这个脚本的职责是：接收 JSON 格式的指令，解析成 Blender 的 bpy 操作，执行后返回结果。指令格式我建议自定义一套简单的，比如：
{ "action": "batch_update", "target": "rack_*", "params": { "layers": 3, "layer_height": 0.8 } }Antigravity 侧配置 MCP Server 时，关键是填对通信地址和端口，以及确认工具描述（tool description）写得足够清晰。工具描述写得好，AI 才知道什么时候该调用它、参数怎么填。我见过有人把描述写成"操作 Blender"，结果 AI 完全不知道该传什么参数。正确的写法是明确列出每个参数的含义和取值范围。
连接验证别偷懒，一定要做三步测试：第一步，让智能体执行一个"列出当前场景所有对象"的只读指令，确认通信通；第二步，执行一个"创建一个立方体"的写指令，确认权限够；第三步，执行一个"批量修改货架层数"的复合指令，确认批量逻辑对。这三步过了，后面才敢放心用。
2.3 智能体指令设计与常见报错处理
指令设计是这套方案里最考验经验的部分。AI 不是万能的，你得把任务拆到它能理解的粒度。比如"帮我建一个仓库"这种指令，AI 会懵；但"在原点创建一个 20x30 米的地面平面，然后在 X 轴方向每隔 3 米放一个货架，共 6 个"这种指令，它就能执行。
我总结的指令设计原则是：先定位、再操作、后验证。定位是告诉 AI 操作哪个对象，操作是具体改什么，验证是让它返回执行结果供你检查。比如"把名为 rack_01 到 rack_06 的货架层数改为 3，改完后列出它们的层数确认"，这样一条指令就包含了完整闭环。
常见报错里，最高频的是"对象未找到"，原因通常是命名不匹配或者对象被隐藏了。解决办法是在指令里加通配符匹配，并且让脚本先检查对象是否存在再操作。第二高频的是"权限被拒绝"，这通常是 Blender 的脚本执行权限没开，或者 MCP Server 没启动。第三是"执行超时"，批量操作对象太多时会触发，解决办法是分批执行，每批不超过 50 个对象。
注意：Antigravity 在执行复杂指令时可能因为上下文过长而中断，这时候不要反复重试同一条指令，而是把它拆成几条短指令分步执行，成功率会高很多。
3. 从 Blender 到 Three.js 的完整数据链路
3.1 glTF 导出参数与体积优化
模型建好、材质调好之后，导出这一步决定了前端能不能流畅跑起来。Blender 导出 glTF 的选项里，有几个必须关注的：
- 格式选 glTF Binary (.glb)，单文件包含所有资源，前端加载最省事。
- +Y Up 勾选，做坐标系转换。
- 应用修改器（Apply Modifiers）勾选，否则几何节点生成的东西导不出去。
- 压缩（Draco）建议开启，能把体积压到原来的三分之一甚至更小，但前端要额外引入 Draco 解码器。
体积优化的核心思路是"能省则省"。货架的立柱如果是圆柱，段数从默认 32 降到 8，肉眼几乎看不出差别，但顶点数少一大截。重复的货架不要每个都导出独立网格，用实例化（Instancing）在前端复制，GLB 里只存一份。我实测过一个 200 货架的仓库，优化前 GLB 有 40 多兆，优化后压到 6 兆左右，加载时间从十几秒降到两秒内。
材质贴图也要控制。仓储场景里，货架用纯色材质就够了，地面和墙面用贴图。贴图统一转成 WebP 或者压缩过的 PNG，别用原始的大图。如果场景里有文字标牌，能用几何体拼的就别用贴图，省资源还清晰。
3.2 Three.js 场景加载与坐标对齐
前端这边，用 Three.js 加载 GLB 的标准流程是：初始化场景、相机、渲染器，然后用 GLTFLoader 加载模型，加载完成后遍历场景树，给需要交互的对象绑定事件。这里有个关键点：加载后的模型要按业务需求重新组织层级，不能直接用 Blender 导出的原始层级，因为 Blender 里的父子关系可能和前端交互逻辑不一致。
坐标对齐是新手最容易翻车的地方。Blender 里货架在 (0,0,0)，导出后到 Three.js 里可能位置对，但如果你在 Blender 里用了父级空物体做整体偏移，导出后位置就可能偏。我的做法是：导出前把所有对象的变换应用掉（Apply Transform），让每个对象的变换都是干净的，这样前端拿到的坐标就是所见即所得。
相机设置上，仓储场景建议用透视相机，视野（FOV）给 50 到 60 度，位置放在场景斜上方，俯角 30 度左右，这样能同时看到地面分区和货架高度。如果要支持自由漫游，再加一套轨道控制器（OrbitControls），限制一下俯仰角度，别让用户转到地面以下。
3.3 数据绑定：让孪生场景"活"起来
数字孪生和普通三维展示的区别就在"数据绑定"。静态模型谁都能做，但要让货架上的库存数量、AGV 的实时位置、温湿度传感器的数值反映到场景里，才叫孪生。
实现思路是：前端维护一个"对象 ID 到业务数据"的映射表，后端通过 WebSocket 推送数据更新，前端收到后找到对应的三维对象，更新它的视觉表现。比如货架库存满了显示绿色，低于阈值显示黄色，缺货显示红色。AGV 的位置更新则是直接改它的 position 属性，配合插值让移动看起来平滑。
这里有个性能坑：如果每来一条数据就遍历整个场景树找对象，数据量一大就卡。正确做法是在加载阶段就建立 ID 到对象的索引（Map 结构），更新时直接查表，O(1) 复杂度。我试过用遍历的方式，200 个对象、每秒 10 条更新就开始掉帧，换成索引后同样的数据量稳在 60 帧。
提示：数据绑定的字段名要和 Blender 里的对象命名对应上，最好在建模阶段就定好一套 ID 规则，比如货架 ID 就是它的对象名，这样前后端对接时不用再维护一张额外的映射表。
4. 实操避坑与问题排查实录
4.1 建模与导出阶段的典型问题
问题一：导出的模型在前端显示为纯黑。这几乎都是材质问题。Blender 里如果用了非 Principled BSDF 的材质，或者材质的输出没连到表面，导出后就会丢失。解决办法是导出前逐个检查材质，确保都是标准节点。另一个可能是前端没打光，Three.js 默认没有环境光，加一个 AmbientLight 和 DirectionalLight 就能解决。
问题二：模型位置偏移或缩放不对。前面提过，根因是变换没应用。Blender 里如果对象有缩放（比如 0.01），导出后前端拿到的是原始尺寸，看起来就会巨大或极小。养成习惯：建模完成后全选，Ctrl+A 应用全部变换。
问题三：GLB 文件过大导致加载慢。除了前面说的 Draco 压缩和实例化，还有一个容易被忽略的点是动画数据。如果 Blender 里不小心给对象加了关键帧，导出时会带上动画，体积翻倍。检查方法是在导出设置里取消"动画"勾选，除非你确实需要。
4.2 MCP 指令执行失败的排查思路
MCP 这条链路出问题，排查要按"通信—权限—逻辑"三层来。通信层看 MCP Server 是否启动、端口是否被占用、Antigravity 里的地址是否填对。权限层看 Blender 的脚本执行是否开启、防火墙是否拦截。逻辑层看指令本身是否有语法错误、目标对象是否存在。
我整理了一个速查表，遇到问题按这个顺序查：
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 指令无响应 | MCP Server 未启动 | 检查服务进程和端口 |
| 报"对象未找到" | 命名不匹配或对象隐藏 | 先执行列出对象指令确认 |
| 报"权限拒绝" | 脚本执行未开启 | Blender 偏好设置里开启 |
| 执行超时 | 批量对象过多 | 拆分成多批，每批 50 以内 |
| 结果不符合预期 | 指令描述模糊 | 细化指令，加验证步骤 |
独家经验是：每次批量操作前先做一次"干跑"（dry run），也就是让脚本只返回将要操作的对象列表，不实际执行。确认列表对了再真正执行。这个习惯帮我避免过好几次误删对象的事故。
4.3 前端渲染性能优化实战
Three.js 在仓储场景里卡顿，通常不是模型面数的问题，而是绘制调用（Draw Call）太多。每个独立对象都是一次绘制调用，200 个货架就是 200 次，GPU 再强也扛不住。解决办法是用 InstancedMesh，把相同几何体的对象合并成一次绘制。货架、托盘、货物这些重复度高的，都适合用实例化。
另一个优化点是视锥剔除（Frustum Culling）。Three.js 默认开启，但如果对象的包围盒计算不准（比如用了自定义几何体），剔除就会失效，导致屏幕外的对象也在渲染。检查方法是看渲染器的 info.render.calls 数值，如果远大于可见对象数，就是剔除没生效。
还有光照。实时阴影很吃性能，仓储场景如果不需要精确阴影，用一张烘焙好的阴影贴图贴在地面上，效果差不多但性能好很多。如果一定要实时阴影，把阴影贴图分辨率降到 1024，并且只让主光源投射阴影。
注意：谷歌浏览器在渲染复杂 Three.js 场景时确实容易卡，尤其是开了开发者工具的情况下。测试性能时记得关掉 DevTools，或者用性能面板单独测，否则数据不准。
5. 这套方案还能怎么扩展
5.1 从单机演示到多人协同
目前这套流程是单机跑通的，但仓储孪生的真实需求往往是多人同时看、同时操作。扩展方向是把场景状态放到服务端，前端只做渲染和指令发送。具体做法是用 WebSocket 做状态同步，每个客户端连上来先拉一份全量场景数据，之后只接收增量更新。这样多个管理者看到的是同一个仓库状态，谁改了货架布局，其他人也能实时看到。
这里要注意冲突处理。两个人同时改同一个货架，得有策略决定谁生效。简单做法是加时间戳，后到的覆盖先到的；复杂一点用操作变换（OT）或者 CRDT，但那是另一个量级的工程了。原型阶段用时间戳就够了。
5.2 接入实时数据源做真正的孪生
静态场景只是第一步，真正的孪生要接实时数据。仓储场景常见的数据源有：WMS 系统的库存数据、AGV 调度系统的位置数据、IoT 传感器的温湿度数据。接入方式通常是后端做一层适配，把不同来源的数据统一成前端能理解的格式，再通过 WebSocket 推给前端。
数据频率要控制。库存数据可能几分钟变一次，AGV 位置可能每秒变十次，如果都按最高频率推，前端会被淹没。我的做法是按数据类型分级：低频数据（库存、温湿度）用轮询或低频推送，高频数据（AGV 位置）用 WebSocket 并且做节流，前端渲染时再做插值平滑。
5.3 移动端与轻量化展示的取舍
仓储管理者很多时候是在手机上看的，这就要求场景能在移动端跑起来。移动端 GPU 性能有限，策略是降级渲染：减少实例数量、关闭实时阴影、降低贴图分辨率、限制同屏对象数。Three.js 的 renderer 可以根据设备像素比动态调整分辨率，移动端把 pixelRatio 限制在 1.5 以内，能明显提升流畅度。
另一个思路是做"分层展示"：移动端只显示关键信息（货架状态色块、AGV 位置点），不显示精细模型；桌面端才展示完整三维场景。这样同一套数据，不同终端有不同的呈现方式，兼顾了性能和体验。
我个人在实际操作中的体会是，数字孪生这个领域，建模和渲染只是冰山一角，真正花时间的是数据链路和业务逻辑的对接。Blender MCP 这套组合最大的价值是帮你快速把三维资产这一块搞定，让你能把精力放在数据绑定和交互设计上。如果你也在做类似的项目，建议先把一条最小的数据链路跑通——哪怕只有一个货架、一条库存数据——再往上堆复杂度，这样每一步都踩得实。
