企业官网建设流程全解析

1. 从零拆解：为什么选 Blender MCP 做仓储数字孪生

1.1 数字孪生仓储的真实需求到底是什么

先聊一个我踩过的坑。去年接了个智慧仓储的可视化项目，客户张口就要"数字孪生"，我第一反应是打开 Three.js 手搓货架、叉车、AGV 小车。结果做了两周，货架模型棱角生硬、材质像塑料、灯光一打全是噪点，客户看完只说了一句"这不像真的"。问题出在哪？Three.js 擅长的是渲染和交互，不是建模。你用它从零构建一个货架的几何体，等于用螺丝刀去砍树。

数字孪生仓储的核心诉求其实分三层。最底层是几何还原——货架有几层、每层多高、立柱多粗、托盘什么尺寸，这些必须和物理世界对得上，否则"孪生"两个字就是空谈。中间层是状态映射——哪个库位有货、哪个库位空着、AGV 走到哪了、堆垛机在做什么动作，这些数据要实时驱动模型变化。最上层是交互与性能——用户能旋转缩放、能点击货架看库存、能在浏览器里流畅跑起来，不能一转就卡成 PPT。

我见过太多项目死在第一层。用代码硬编码几何体，改一个货架尺寸要动十几行代码，客户说"货架再加两层"，你就得重新算坐标。这时候 Blender 的价值就出来了：它是一个成熟的 DCC（数字内容创作）工具，建模、材质、UV、灯光一条龙，导出的 glTF 模型直接能被 Three.js 加载。Blender 负责"长得像"，Three.js 负责"动起来"，各司其职。

那 MCP 又是什么角色？MCP 全称 Model Context Protocol，简单说就是让 AI 助手能够直接操作外部工具的一套协议。Blender MCP 就是让 AI 能"遥控"Blender——你说"给我建一个 4 层货架，每层承重 500kg，立柱用 100x100 的方管"，AI 通过 MCP 调用 Blender 的 Python API 把模型建出来。这解决的是建模效率问题，尤其是批量生成标准化货架、托盘这类重复资产时，比手动建模快一个数量级。

所以这个项目的技术选型逻辑很清晰：Blender MCP 负责快速产出高质量 3D 资产，Three.js 负责在浏览器里渲染和交互，Vue 3 负责整个前端应用的工程化组织。三者串起来，才是一个能落地、能维护、能扩展的数字孪生方案。

1.2 Antigravity 在链路里扮演什么角色

标题里的 Antigravity 是这套方案里的 AI 编程助手环境。你可以把它理解成一个能理解你意图、能调用工具、能写代码的智能体工作台。在这个项目里，它的核心作用是把自然语言需求翻译成 Blender 操作和 Three.js 代码。

举个实际场景。我跟它说："帮我生成一个 20 米长、12 米宽、8 米高的仓库场景，里面放 6 排货架，每排 10 组，货架 4 层，通道宽 3 米。"它需要做几件事：第一，理解空间布局，算出货架的摆放坐标；第二，通过 Blender MCP 调用建模脚本，把货架几何体生成出来；第三，导出 glTF；第四，生成 Three.js 加载和摆放的代码。这一整套流程，如果纯手工做，建模加摆位加调代码，少说半天。有了 AI 辅助，可能十几分钟就能出第一版。

但这里有个现实问题必须提前说清楚：Antigravity 这类工具在使用过程中经常遇到账号验证、请求被拒、执行中断等状况。热搜词里那些"verify your account""403""agent execution terminated"都是真实存在的痛点。我的经验是，不要把它当成一个必须时刻在线的依赖，而是当成一个加速器——它在线时帮你快速产出，它抽风时你有手动方案兜底。所以本文的实操部分，我会同时给出"AI 辅助路径"和"手动兜底路径"，确保你不管遇到什么状况都能把项目推进下去。

1.3 整体架构长什么样

在动手之前，先把架构在脑子里过一遍，不然做到一半容易迷路。

整个系统分四层。资产层是 Blender 产出的 glTF 模型文件，包括货架、托盘、AGV、叉车、地面、墙体这些静态资产。数据层是仓储的业务数据，库位状态、库存信息、设备位置，通常来自后端接口或 WebSocket 推送。渲染层是 Three.js 场景，负责加载模型、摆放位置、处理光照材质、响应交互。应用层是 Vue 3 组件，负责页面布局、状态管理、和渲染层通信。

数据流向是这样的：Vue 组件从后端拿到库位数据，通过状态管理传给 Three.js 场景管理器，场景管理器根据库位 ID 找到对应的 3D 对象，更新它的材质颜色或显示隐藏。用户点击某个货架，Three.js 的射线检测捕获到对象，把库位 ID 回传给 Vue，Vue 弹出详情面板。

这个架构的关键在于资产和逻辑分离。Blender 只管把模型做漂亮，Three.js 只管把模型摆对位置、响应交互，Vue 只管业务逻辑和 UI。三层之间通过清晰的接口通信，任何一层要改都不会牵一发动全身。我见过把建模、渲染、业务逻辑全塞在一个文件里的项目，改一个货架颜色要找半天，那种代码维护起来是灾难。

2. Blender MCP 环境搭建与资产生产

2.1 环境准备：Blender 端要装什么

Blender 这边需要三样东西：Blender 本体、MCP 插件、以及一个能跑 Python 脚本的环境。Blender 版本建议 4.0 以上，因为 4.x 对 glTF 导出的支持更完善，尤其是材质和动画的导出质量比 3.x 有明显提升。

MCP 插件的安装方式取决于你用的具体实现。常见做法是把插件包放到 Blender 的插件目录，然后在偏好设置里启用。启用之后，Blender 会暴露一个本地服务端口，AI 助手通过这个端口发送指令。这里有个细节要注意：端口不要用默认的，改成一个不常用的高位端口，避免和你机器上其他服务冲突。我一般用 9876 这种，好记又不容易撞。

Python 环境方面，Blender 自带 Python，但版本可能和你系统里的不一样。如果你要写复杂的建模脚本，建议直接在 Blender 的脚本编辑器里写，用bpy模块操作场景。这样不用担心版本兼容问题。如果你习惯用外部编辑器写脚本再导入，记得确认脚本里用的 API 和你的 Blender 版本匹配，bpy.ops里很多操作在不同版本间有差异。

提示：安装完 MCP 插件后，先在 Blender 里手动跑一个最简单的脚本测试连通性，比如创建一个立方体。确认插件能正常接收指令再往下做，不然出了问题你分不清是插件没装好还是脚本写错了。

2.2 用自然语言驱动建模的实操流程

假设环境已经通了，现在开始建货架。我的习惯是先让 AI 生成一个基础货架，确认效果后再批量复制。

第一步，描述需求。不要只说"建个货架"，要给出具体参数。比如："创建一个横梁式货架单元，立柱截面 100mm x 100mm，高度 6000mm，深度 1200mm，宽度 2700mm，4 层横梁，每层间距 1500mm，横梁截面 80mm x 50mm，材质用金属灰。"参数越具体，AI 生成的模型越接近你要的效果。

第二步，AI 通过 MCP 调用 Blender 的 Python API 执行建模。它通常会做这几件事：用bpy.ops.mesh.primitive_cube_add创建立方体作为基础几何，然后通过缩放和位移调整尺寸，再用bpy.ops.object.duplicate复制立柱和横梁。这里有个性能细节：如果货架数量多，不要每个货架都单独建模，建一个然后复制。Blender 里复制对象比重新建模快得多，而且导出的 glTF 文件也更小。

第三步，检查模型。AI 建完不一定完美，你要在 Blender 里转一圈看看。常见问题是尺寸比例不对、横梁和立柱穿插、材质没赋上。发现问题直接告诉 AI 调整，比如"立柱太粗了，改成 80mm"或者"横梁位置往上移 100mm"。这种迭代比你自己手动调快很多。

第四步，导出 glTF。选中要导出的对象，用File > Export > glTF 2.0。导出设置里几个关键项：格式选.glb（二进制格式，单文件，方便传输），勾选"应用修改器"（如果你用了阵列修改器），材质导出选"导出"（确保材质信息带出去）。导出前记得把场景里不需要的对象删掉或隐藏，不然 glTF 里会带一堆垃圾数据。

2.3 批量生成货架与托盘的脚本思路

单个货架建好后，批量生成就是复制加位移。但这里有个坑：不要用 AI 一个个复制粘贴，让它写一个循环脚本。

脚本的核心逻辑是这样：定义货架的排列规则，比如 6 排、每排 10 组、排间距 3000mm、组间距 100mm。然后用双重循环遍历，每次复制一个货架对象，设置它的位置坐标。位置计算要注意坐标系——Blender 默认 Z 轴朝上，而 Three.js 默认 Y 轴朝上，导出 glTF 时 Blender 会自动转换，但你在写脚本时心里要有数。

托盘的生成类似，但托盘通常放在货架横梁上，位置要和货架层高对应。我的做法是先生成所有货架，记录每个货架每层的位置坐标，然后根据这些坐标摆放托盘。这样后续做库位映射时，每个托盘的位置就是现成的库位坐标。

材质方面，建议在 Blender 里就把材质调好，不要指望在 Three.js 里再调。Blender 的材质系统比 Three.js 强大得多，金属度、粗糙度、法线贴图这些都能精细控制。导出 glTF 时这些信息会以 PBR 材质的形式带出去，Three.js 能直接识别。如果你在 Blender 里只给个纯色，到了 Three.js 里再怎么调灯光也出不来真实感。

注意：glTF 导出时材质名称会保留，这是你后续在 Three.js 里定位对象的依据。所以给材质起名要有规律，比如mat_shelf_metal、mat_pallet_wood，不要用默认的Material.001这种，不然代码里根本分不清谁是谁。

2.4 资产优化：面数与纹理的取舍

数字孪生场景里对象数量多，面数控制不好浏览器直接卡死。一个货架如果用了圆角、螺栓、孔洞这些细节，面数轻松上万。6 排 10 组就是 60 个货架，60 万面，再加上托盘、AGV、地面，百万面起步，中低端显卡直接跪。

我的优化策略是分级建模。近处会仔细看的对象，比如用户经常点击的货架，保留中等细节，单个控制在 2000 面以内。远处只是背景的对象，用简化版，几百面就行。具体做法是在 Blender 里用"精简"修改器降低面数，或者干脆建一个低模版本专门给远处用。

纹理方面，能共用就共用。所有货架用同一张贴图，所有托盘用同一张，通过 UV 展开让它们看起来有变化。不要每个货架单独一张贴图，那样显存占用会爆炸。贴图分辨率 1024x1024 通常够用，除非你要做特写展示，才上 2048。

还有一个容易被忽略的点：合并同材质对象。Blender 里如果有 60 个货架各自是独立对象，导出后 Three.js 要发 60 次绘制调用。如果你把它们合并成一个对象（材质相同的情况下），就只发 1 次。这个优化对帧率提升非常明显。合并的方法是在 Blender 里选中所有货架，Ctrl+J合并。但合并后就无法单独控制每个货架了，所以合并的时机要把握好——如果每个货架需要独立变色表示库位状态，就不能合并，得用实例化（InstancedMesh）的方式在 Three.js 里处理。

3. Three.js 场景搭建与模型加载

3.1 Vue 3 项目里怎么组织 Three.js 代码

先把工程结构理清楚。Vue 3 项目里，Three.js 相关代码不要写在.vue组件的setup里，那样组件一多就乱套。我的做法是单独建一个three目录，里面放场景管理器、模型加载器、交互控制器这些模块。

场景管理器是一个类，负责创建场景、相机、渲染器、灯光，以及管理所有 3D 对象。它暴露几个方法：init(container)初始化并挂载到 DOM，loadModels()加载 glTF 资产，updateData(data)接收业务数据更新对象状态，dispose()销毁释放资源。Vue 组件只负责在onMounted时调用init，在onUnmounted时调用dispose，中间的数据通过 props 或状态管理传进去。

这样组织的好处是渲染逻辑和业务逻辑彻底解耦。你换一个 Vue 组件来展示同一个场景，只要传同样的数据就行。反过来，你要改渲染效果，也不用动 Vue 组件。我吃过耦合的亏，之前把 Three.js 代码写在组件里，后来要加一个全屏展示模式，发现代码根本没法复用，只能复制一份改，维护起来想死。

渲染器初始化有几个关键参数。antialias: true开抗锯齿，不然模型边缘全是锯齿。alpha: false除非你要透明背景。powerPreference: 'high-performance'告诉浏览器用独显。像素比用Math.min(window.devicePixelRatio, 2)，不要直接用devicePixelRatio，4K 屏上像素比是 3 甚至 4，渲染压力翻几倍，限制在 2 就够了，肉眼几乎看不出差别。

3.2 glTF 模型加载与位置映射

加载 glTF 用GLTFLoader。加载完成后，gltf.scene就是整个模型树。你需要遍历它，找到货架、托盘这些对象，给它们打上标记，方便后续根据业务数据定位。

这里有个坐标系转换的问题必须讲清楚。Blender 导出 glTF 时，会自动把 Z-up 转成 Y-up，所以你在 Blender 里货架是立着的，到 Three.js 里也是立着的，这点不用担心。但位置坐标的数值会变，因为轴换了。你在 Blender 里货架位置是(x, y, z)，到 Three.js 里可能变成(x, z, -y)。所以如果你在 Blender 里记录了库位坐标，到 Three.js 里不能直接用，要么在导出前转换，要么在加载后转换。

我的做法是在 Blender 里就用 Three.js 的坐标系建模。具体说，建模时把 Blender 的 Y 轴当成 Three.js 的 Z 轴来用，导出后位置就基本对得上了。或者更简单：在 Three.js 里加载完模型后，遍历所有对象，把位置坐标做一次转换再存到映射表里。转换公式是threePos.set(blenderPos.x, blenderPos.z, -blenderPos.y)。

位置映射表是核心数据结构。我用一个Map，key 是库位 ID，value 是{ object, position, status }。加载模型时，根据对象名称或自定义属性解析出库位 ID，建立映射。后续收到业务数据，直接map.get(locationId)就能找到对应对象，改它的材质颜色或可见性。

3.3 灯光与材质调优让场景"活"起来

Three.js 默认的灯光很平，场景看起来像纸片。要让仓储场景有真实感，灯光得下功夫。

基础配置是环境光加方向光。环境光提供整体照明，方向光模拟主光源，产生阴影。环境光强度 0.4 到 0.6，方向光强度 1.0 到 1.5，具体看场景色调。方向光的位置要调，从斜上方打下来，阴影才有层次。阴影贴图分辨率 2048 够用，4096 更清晰但更吃性能。

进阶一点用HDRI 环境贴图。找一张仓库或工业场景的 HDRI，用RGBELoader加载，设置为scene.environment。这样金属货架会有真实的环境反射，质感立刻上一个档次。HDRI 分辨率不用太高，1K 或 2K 就行，它主要提供反射信息，不直接显示。

材质方面，Blender 导出的 PBR 材质 Three.js 能直接识别，但你可能需要微调。比如金属度太高会显得像镜子，粗糙度太低会太光滑。我的经验是货架金属度 0.8、粗糙度 0.4 左右比较像喷塑钢架。托盘木质金属度 0、粗糙度 0.8。地面如果是环氧地坪，金属度 0.1、粗糙度 0.3，带一点反射。

还有一个提升真实感的小技巧：加一点雾。scene.fog = new THREE.Fog(0x1a1a2e, 50, 200)，远处对象逐渐淡出，既有纵深感，又能掩盖远处模型的低精度。雾的颜色和背景色一致，过渡才自然。

3.4 相机控制与交互基础

相机控制用OrbitControls，这是标配。但默认参数要调：enableDamping开阻尼，旋转有惯性，手感好很多。maxPolarAngle限制在Math.PI / 2左右，防止相机转到地面以下。minDistance和maxDistance限制缩放范围，太近穿模，太远看不清。

交互的核心是射线检测。用户点击屏幕，从相机发一条射线穿过点击位置，检测和哪些对象相交。相交的第一个对象就是用户点中的。拿到对象后，通过它的名称或自定义属性找到库位 ID，回传给 Vue 组件。

射线检测有个性能坑：不要对场景里所有对象做检测。如果场景里有几万个对象，每次点击都遍历一遍，卡到怀疑人生。正确做法是只对需要交互的对象做检测，比如把所有货架放在一个数组里，检测时只遍历这个数组。或者用Layers分层，交互对象放一层，背景放另一层，检测时只检测交互层。

悬停高亮也是常见需求。mousemove时做射线检测，如果悬停到货架，改它的 emissive 颜色让它发光。移开时恢复。这里要注意节流，mousemove触发频率很高，每次都做射线检测会卡。用requestAnimationFrame或时间戳节流，限制到每秒 30 次左右就够了。

4. 数据驱动与状态映射实战

4.1 库位状态如何映射到 3D 对象

数字孪生的灵魂在于数据驱动。3D 场景不是摆设，它要反映真实仓库的状态。库位有货、空置、锁定、异常，这些状态要在模型上直观体现。

最直接的方式是改颜色。有货的库位托盘显示正常木色，空置的库位托盘隐藏或显示半透明，锁定的库位显示黄色，异常的显示红色。实现上就是遍历业务数据，对每个库位找到对应的 3D 对象，改它的材质颜色。

但这里有个性能问题：如果每个托盘单独一个材质，改颜色要改几十上百个材质，开销大。优化方案是用共享材质加顶点颜色，或者用InstancedMesh加实例颜色。InstancedMesh是 Three.js 提供的实例化渲染方案，同一个几何体渲染多次，每次可以有不同的变换和颜色，绘制调用只有一次。对于托盘这种大量重复的对象，用InstancedMesh性能提升非常明显。

具体做法是：加载一个托盘模型，提取它的几何体和材质，创建InstancedMesh，设置实例数量为库位总数。然后每个实例设置位置矩阵和颜色。更新状态时，只需要改对应实例的颜色属性，然后标记instanceColor.needsUpdate = true。这样即使有几千个库位，更新也是瞬间完成。

4.2 实时数据推送与场景更新

业务数据通常来自后端。如果是静态展示，初始化时拉一次数据就行。但数字孪生要"孪生"，就得实时。常见方案是 WebSocket，后端有状态变化就推给前端。

前端收到推送后，不能直接改 3D 对象，因为可能一次推来几百条更新，逐条改会卡。我的做法是用一个更新队列。推送来的数据先入队，然后在requestAnimationFrame循环里批量处理。每帧处理一定数量，比如 50 条，剩下的下一帧继续。这样既保证了实时性，又不会阻塞渲染。

更新逻辑要幂等。同一条数据可能推多次，或者推送顺序乱了，你要保证最终状态一致。做法是每次更新都基于最新数据全量计算，而不是增量修改。比如收到库位 A 状态变为"有货"，你就把 A 的状态设为"有货"，而不是"在原来基础上加有货"。这样即使重复推送或乱序，结果都是对的。

还有一个细节：更新要有过渡动画。状态从空置变有货，托盘突然出现很突兀。用TWEEN或自己写插值，让托盘的透明度或缩放从 0 渐变到 1，视觉上舒服很多。同理，颜色变化也用插值过渡，不要瞬间跳变。

4.3 性能监控与帧率优化

场景跑起来后，要盯着帧率。Three.js 有Stats工具，挂在页面上角，实时显示 FPS、绘制调用数、内存占用。FPS 低于 30 就要优化了，低于 20 用户能明显感觉卡。

优化的第一刀砍向绘制调用。renderer.info.render.calls这个数值如果超过 500，说明绘制调用太多。解决办法是合并同材质对象、用InstancedMesh、用LOD（细节层次）。LOD 是远处用低模、近处用高模，Three.js 的LOD对象可以自动切换。

第二刀砍向阴影。阴影很吃性能，尤其是大场景。如果帧率不够，先关阴影看提升多少。如果必须保留阴影，缩小阴影相机的范围，只对近处对象投射阴影。或者用烘焙阴影贴图代替实时阴影，性能好很多，但对象不能动。

第三刀砍向材质。透明材质、高精度贴图、复杂着色器都吃性能。检查有没有不必要的透明对象，贴图能不能压缩，着色器能不能简化。我遇到过一个案例，场景里有个对象用了MeshPhysicalMaterial加清漆层，帧率直接掉一半，换成MeshStandardMaterial就好了。

提示：优化是个迭代过程，不要一次改太多，改一项测一次，不然你不知道是哪个改动起了作用。用Stats和 Chrome 的 Performance 面板配合分析，定位瓶颈更准。

5. 踩坑实录与常见问题排查

5.1 模型加载失败与路径问题

glTF 加载失败是最常见的问题，表现是场景里空空如也，控制台报错。原因通常有几个。

路径不对。Vue 项目里静态资源放public目录，引用时用绝对路径/models/shelf.glb。如果放src/assets，要用import或new URL的方式引用，不然打包后路径会变。我建议放public，省心。

跨域问题。开发时如果模型放在另一个服务上，浏览器会拦。解决办法是把模型放同源目录，或者后端配 CORS。生产环境一般同源，问题不大。

格式不兼容。Blender 导出的 glTF 有.gltf和.glb两种。.gltf是 JSON 加外部资源，.glb是单文件二进制。优先用.glb，单文件不会丢资源，加载也快。如果用.gltf，确保.bin和贴图文件路径正确。

版本问题。Three.js 的GLTFLoader在不同版本间 API 有变化。如果你从网上抄的代码跑不通，先检查 Three.js 版本。新版本里GLTFLoader要从three/examples/jsm/loaders/GLTFLoader.js导入，老版本路径可能不同。

5.2 材质显示异常与颜色偏差

模型加载出来但颜色不对，通常是这几个原因。

色彩空间。Three.js 从 r152 版本开始默认用 sRGB 色彩空间，但贴图需要手动设置texture.colorSpace = THREE.SRGBColorSpace。如果没设，贴图会偏暗或偏亮。Blender 导出的贴图一般是 sRGB，记得设。

光照不足。PBR 材质需要足够的光照才能正确显示。如果场景里只有环境光，金属材质会显得很暗。加方向光或 HDRI 环境贴图，材质质感立刻出来。

材质类型不匹配。Blender 里用的某些节点，导出 glTF 后可能不被支持，降级成基础材质。比如 Blender 的Principled BSDF大部分参数能导出，但一些特殊节点不行。导出前在 Blender 里用glTF预览检查一下，或者导出后在 Three.js 里看效果。

透明排序问题。透明对象渲染顺序不对会穿帮。Three.js 里设置material.transparent = true和material.depthWrite = false，然后手动控制renderOrder。透明对象一般最后渲染。

5.3 交互无响应与射线检测失效

点击没反应，先检查射线检测的代码。

相机矩阵没更新。射线检测依赖相机的投影矩阵和视图矩阵，如果相机动了但矩阵没更新，射线方向就是错的。在render之前调用camera.updateMatrixWorld()，或者确保OrbitControls更新后相机矩阵同步了。

对象没有包围盒。射线检测需要对象的几何体有boundingSphere或boundingBox。如果几何体是动态生成的，可能没算包围盒。调用geometry.computeBoundingSphere()手动算一下。

层级问题。如果对象在多层Group里，射线检测返回的是最底层的Mesh，但你可能想操作的是它的父级Group。检测后要向上遍历找到你标记的那个对象。我的做法是给需要交互的对象设userData，检测到Mesh后向上找带userData的祖先。

事件绑定问题。addEventListener绑在了错误的元素上，或者被其他元素挡住了。检查绑定的 DOM 元素是不是渲染器的canvas，以及有没有其他元素覆盖在上面。

5.4 常见问题速查表

5.5 几个我踩过的独家坑

坑一：Blender 导出时对象名称被改。Blender 里对象叫"货架A"，导出 glTF 后可能变成"货架A.001"或者被截断。如果你代码里按名称找对象，就会找不到。解决办法是导出前统一命名，或者用userData存 ID，不依赖名称。

坑二：Three.js 的dispose不彻底。组件卸载时如果只调renderer.dispose()，几何体、材质、贴图占的显存不会释放。反复切换页面，显存越占越多，最后崩掉。正确做法是遍历场景，对每个几何体、材质、贴图调dispose()，再销毁渲染器。

坑三：Vue 的响应式代理拖慢 Three.js。如果把 Three.js 对象放在 Vue 的reactive或ref里，Vue 会给它加代理，每次访问都走代理，性能下降明显。Three.js 对象不要放进 Vue 响应式系统，用普通变量或shallowRef存。

坑四：移动端适配。桌面端跑得好好的，手机上打开卡成幻灯片。移动端 GPU 性能差，要降分辨率、关阴影、减面数。用renderer.setPixelRatio(Math.min(devicePixelRatio, 1.5))限制像素比，移动端 1.5 就够了。

坑五：内存泄漏。requestAnimationFrame循环如果在组件卸载时没取消，会一直跑，占着内存和 CPU。在dispose里调cancelAnimationFrame，把循环停掉。事件监听也要移除，不然 DOM 元素删了监听还在。

6. 从单机到园区：这套方案的扩展边界

6.1 多仓库与园区级场景的组织

单仓库跑通后，很自然会想扩展到多仓库甚至园区级。这时候场景规模上了一个数量级，原来的做法要调整。

分块加载是核心思路。不要一次性把所有仓库的模型都加载进来，而是根据相机位置动态加载。相机在仓库 A 附近，就只加载 A 的模型，B 和 C 用低模或空占位。Three.js 里可以用LOD或者自己写加载逻辑，监听相机移动，进入某个区域才加载对应模型。

场景分层也很重要。地面、道路、绿化这些静态背景放一层，仓库建筑放一层，内部货架放一层，AGV 等动态对象放一层。每层可以独立控制可见性和加载状态。园区级场景里，用户大部分时间看的是宏观布局，内部细节可以按需加载。

坐标系统一是前提。多个仓库的模型如果各自用各自的坐标系，拼在一起就乱了。建模时就要约定好全局坐标系，每个仓库在全局中的位置固定。Blender 里可以建一个总场景，把各个仓库的模型按位置摆好，再整体导出。或者分别导出，在 Three.js 里按约定坐标摆放。

6.2 与后端数据系统的对接方式

数字孪生要真正有用，必须和业务系统打通。WMS（仓储管理系统）、WCS（仓储控制系统）里的数据要实时反映到 3D 场景。

对接方式通常有两种。推模式是后端主动推，WebSocket 或 MQTT，状态变化立刻推给前端。优点是实时性好，缺点是前端要处理连接管理和断线重连。拉模式是前端定时轮询，每隔几秒拉一次最新数据。优点是简单可靠，缺点是实时性差，且请求量大。

我的建议是推拉结合。初始化时拉一次全量数据，之后用 WebSocket 接收增量更新。WebSocket 断了就降级到轮询，恢复后继续推。这样兼顾实时性和可靠性。

数据格式要约定清楚。库位 ID、状态码、时间戳这些字段的含义和取值范围要文档化。我遇到过前后端对状态码理解不一致，前端以为 1 是"有货"，后端 1 是"锁定"，显示全错了。对接前先对一遍字段定义，能省很多事。

6.3 后续可以继续深挖的方向

这套方案跑通后，还有不少可以深挖的点。

路径动画。AGV 小车在仓库里跑，路径可以预先规划好，用CatmullRomCurve3生成平滑曲线，让小车沿曲线移动。速度、加速度、转弯半径这些参数可以调，看起来更真实。

碰撞检测。如果要模拟 AGV 避障，需要做碰撞检测。Three.js 有Raycaster可以做简单的射线检测，复杂场景可以用Ammo.js或Cannon.js物理引擎。不过物理引擎开销大，看需求取舍。

数据可视化叠加。在 3D 场景上叠加数据面板，比如货架上方显示库存数量，AGV 上方显示电量。用CSS2DRenderer或CSS3DRenderer把 HTML 元素定位到 3D 坐标上，样式用 CSS 控制，比在 3D 里画文字方便得多。

VR/AR 展示。Three.js 支持 WebXR，可以做成 VR 模式，用户戴头显在仓库里"走"。或者 AR 模式，手机对着真实仓库，叠加数字信息。这些是加分项，看项目预算和需求。

历史回放。把仓库的历史状态存下来，做成时间轴，用户可以拖动查看某个时间点的仓库状态。这对分析问题和优化流程很有价值。实现上就是把状态数据按时间存，回放时按时间点还原场景。

这套方案我从单仓库做到园区级，最大的体会是架构比技术重要。技术点就那么些，Three.js 的 API、Blender 的操作、Vue 的组件化，网上都能查到。但怎么把这些技术组织成一个可维护、可扩展的系统，靠的是架构设计。资产和逻辑分离、数据驱动、分层加载、推拉结合，这些原则定好了，后面加功能就是填空。定不好，做到一半就得推倒重来。

最后分享一个我个人的习惯：每做完一个模块，先跑一遍性能测试再往下做。不要等功能全做完了才发现卡，那时候改起来成本高得多。用Stats盯着帧率，用 Chrome Performance 面板看瓶颈，发现问题立刻解决。数字孪生项目对性能敏感，早发现早治疗，比后期优化省力得多。