1. 项目缘起与整体设计思路1.1 为什么选择“智慧仓储”作为数字孪生切入点做3D可视化项目这些年我经手过不少场景机房、园区、产线、变电站。如果让我推荐一个最适合练手、同时又足够体现技术深度的方向智慧仓储绝对排得上前三。原因很直接——仓储场景天然具备三个特征空间结构规整、设备类型丰富、业务逻辑清晰。货架是标准网格排布AGV小车有明确运动轨迹堆垛机、传送带、分拣口各司其职这些元素映射到三维空间里既不会像室外大场景那样难以驾驭也不会像纯设备模型那样单调。更关键的是仓储数字孪生的业务价值肉眼可见。传统WMS系统给管理者看的是一堆表格和数字库存多少、库位占用率多少、今天出了多少单。但管理者真正想知道的往往是三号巷道是不是堵了B区货架是不是快满了那台AGV为什么停在原地不动这些问题一张三维实时画面比十张报表都管用。这就是数字孪生存在的意义——把抽象数据翻译成空间直觉。这个项目我打算分上下两篇来写。上篇聚焦在模型资产的准备与处理也就是怎么用Blender把仓储场景搭出来怎么通过MCP协议让AI辅助建模流程最终导出一套干净、规范、可直接被前端消费的3D资产。下篇再讲前端侧怎么用Vue 3 Three.js把这套资产跑起来接入实时数据做出真正的数字孪生效果。1.2 技术选型的底层逻辑先把技术栈摆清楚再说为什么这么选。环节选型核心理由建模工具Blender免费开源、Python脚本能力强、glTF导出成熟AI辅助Blender MCP用自然语言驱动建模操作降低重复劳动前端框架Vue 3 TypeScript组合式API适合管理复杂场景状态类型安全渲染引擎Three.jsWebGL生态最成熟社区资源丰富传输格式glTF 2.0体积小、加载快、Three.js原生支持好这里重点说两个选型决策。第一个是为什么用Blender而不是直接用Three.js代码建模。我早期做过纯代码建模的项目用BoxGeometry拼货架、用CylinderGeometry拼立柱刚开始觉得挺酷写到后面就崩溃了。一个稍微像样的货架横梁、立柱、层板、斜撑加起来几十个几何体每个都要算位置、算旋转、算缩放改一个尺寸牵一发动全身。更别说还要处理材质、UV、法线。Blender的可视化编辑加上修改器系统效率至少是纯代码的十倍以上。而且Blender的Python API可以脚本化批量生成标准货架阵列就是几行代码的事。第二个是为什么引入Blender MCP。MCP是Model Context Protocol的缩写简单理解就是一套让AI助手能够直接操作外部工具的协议。Blender MCP就是把这个协议接到了Blender上你可以用自然语言告诉AI“帮我创建一个5层货架每层高0.8米宽2米深1米”它就能在Blender里把模型建出来。对于仓储场景这种大量重复、参数化的建模需求这个能力非常实用。当然它也不是万能的复杂曲面、精细雕刻还是得手动来但作为效率工具它确实能省下大量机械操作的时间。1.3 整体流程拆解整个上篇的流程我梳理成四个阶段后面每个阶段都会展开讲场景规划与尺寸定义确定仓库的实际尺寸、货架排布、通道宽度建立统一的比例尺。Blender建模与MCP辅助搭建地面、货架、设备等核心模型用MCP加速重复性工作。材质与优化处理赋予PBR材质合并网格、优化面数、处理法线。glTF导出与资产规范按前端消费需求导出命名规范、层级清晰、坐标归零。提示整个流程中最容易被忽视的是第一阶段。很多人一上来就打开Blender开始建建到一半发现比例不对、货架间距和AGV宽度对不上返工成本极高。花半小时把尺寸规划清楚后面能省几小时。2. 场景规划与尺寸定义的关键细节2.1 从真实仓库到数字空间的映射数字孪生的第一原则是比例真实。如果三维场景里货架间距是2米而实际仓库是2.5米那AGV的路径规划、碰撞检测全部失真孪生的意义就没了。所以开工之前必须拿到真实仓库的关键尺寸。我一般会整理一张尺寸对照表把现实世界的米直接对应到Blender的单位Blender默认1单位1米这个不用改。以一个中型电商仓库为例参数实际尺寸说明仓库总长80m东西方向仓库总宽50m南北方向仓库净高9m地面到屋顶桁架下沿货架排数8排每排双面货架货架单面深度1.0m双面合计2.0m货架长度30m每排分6组每组5m货架层数5层含地面层每层净高1.6m适配标准托盘主通道宽度3.5mAGV双向通行次通道宽度2.0m人工拣货通道这些数字不是随便填的每一个都影响后续建模和前端交互。比如主通道3.5米是因为标准AGV车体宽度约1.2米加上两侧安全余量和双向通行需求3.5米是行业常见值。货架层高1.6米是因为标准托盘货物高度一般不超过1.5米留10厘米余量。2.2 坐标系与原点约定这一步很多人会忽略但它是前端对接的地基。Blender里建完模型导出glTF坐标系会从Blender的Z-up转换成glTF的Y-up。如果不提前约定好原点位置前端加载后模型可能飘在半空或者埋在地下。我的做法是把仓库地面的几何中心设为世界原点(0,0,0)。所有模型都基于这个原点定位。货架沿X轴排布通道沿Y轴延伸。这样导出后前端只需要把相机对准原点整个场景就在视野中央。具体操作上在Blender里新建场景后先创建一个平面作为地面参考把它放在原点尺寸设为80×50。然后所有货架、设备的坐标都相对于这个平面来定。比如第一排货架的中心位置是(-35, -20, 0)最后一排是(35, 20, 0)这样排布逻辑清晰后期调整也方便。注意Blender的Z轴向上glTF的Y轴向上。导出时Blender会自动处理这个转换但如果你在Blender里用了旋转过的父级对象转换可能会出问题。建议所有顶层对象都不要有旋转旋转信息放在子对象或直接应用到网格上。2.3 模块化设计思路仓储场景有个特点大量重复元素。8排货架每排6组就是48组货架单元每组结构完全一样。如果每组都单独建模工作量巨大且难以维护。所以必须走模块化路线。我的模块划分是这样的货架单元模块一组标准货架5层长5m双面深2m这是最基本的复用单元。AGV模块一台标准AGV小车包含车体、顶升机构、指示灯。传送带模块一段标准传送带长5m可拼接。分拣口模块一个分拣工位含扫码枪、显示屏、料框。立柱与桁架模块仓库结构件用于营造空间感。每个模块单独建建好后存成独立的Blender文件或者放在同一个文件的独立Collection里。组装场景时用实例化Instance的方式复制而不是复制网格数据。这样48组货架在Blender里只占一份网格数据的内存导出glTF时也会自动做实例化处理前端加载体积能小很多。这里有个实操技巧在Blender里用AltD复制关联复制而不是ShiftD复制独立复制。关联复制的对象共享网格数据改一个所有实例都跟着变。如果后期发现货架层高要调整改一次就行不用改48次。3. Blender建模实操与MCP辅助流程3.1 Blender基础环境准备工欲善其事必先利其器。Blender的默认配置对建模来说够用但针对仓储场景我建议做几项调整。首先是单位设置。在Scene Properties里把Unit System设为MetricUnit Scale设为1.0Length单位选Meters。这样你在输入尺寸时直接输米数就行不用心算换算。然后是吸附设置。仓储建模大量涉及对齐操作打开磁吸快捷键ShiftTab吸附目标选Vertex顶点和Grid网格网格尺寸设为0.5m。这样拖动物体时会自动吸附到0.5米的整数倍位置保证货架排列整齐。最后是视图裁剪。仓库尺寸80×50米默认视图裁剪距离可能不够模型拉远后会消失。在View面板里把Clip Start设为0.1mClip End设为500m这样从近景到全景都能正常显示。如果你打算用Blender MCP还需要额外装两个东西一个是Blender MCP插件本身另一个是配套的MCP服务端。插件装好后在Blender的侧边栏会出现MCP面板服务端负责和AI助手通信。具体安装步骤各版本可能有差异建议对照官方文档操作这里不展开。3.2 用MCP加速货架阵列生成货架是仓储场景的主体也是最适合用MCP批量生成的部分。我先说手动建一组货架的流程再说怎么用MCP把它自动化。手动建一组5层双面货架核心步骤如下新建一个立方体缩放为货架立柱尺寸0.08m × 0.08m × 8m放在货架一角。用阵列修改器沿X轴复制4根立柱间距2.5m得到一排立柱。选中这排立柱再沿Y轴阵列复制一份间距2.0m得到双面货架的8根立柱。新建横梁尺寸为5m × 0.05m × 0.1m沿Y轴放置每层前后各一根。沿Z轴阵列横梁5层间距1.6m。新建层板尺寸5m × 1.0m × 0.03m放在每层横梁上。加斜撑、地脚等细节。这一套下来熟练工大概15分钟。但如果你有48组就是12小时。这时候MCP的价值就体现出来了。用MCP的思路是把上面的步骤写成一段结构化的自然语言指令让AI在Blender里执行。比如创建一个货架单元 - 8根立柱截面0.08×0.08米高8米 - 立柱分两排每排4根X方向间距2.5米Y方向间距2.0米 - 5层横梁每层前后各一根截面0.05×0.1米长度5米 - 层板5块尺寸5×1.0×0.03米放在横梁上 - 所有对象合并为一个网格命名为Shelf_Unit - 原点设在货架底部中心MCP解析这段指令后会在Blender里逐步执行。实测下来生成一组货架大约20到30秒比手动快很多而且尺寸精确无误。生成第一组后后续47组直接用关联复制几秒钟搞定。实操心得MCP生成的对象有时候会有多余的顶点或重叠面建议生成后进编辑模式做一次Merge by Distance按距离合并阈值设0.001m清理掉重复顶点。另外MCP对中文指令的理解偶尔有偏差关键尺寸最好用数字明确写出避免用“大约”“左右”这类模糊词。3.3 AGV与设备模型的精细处理货架是背景AGV才是数字孪生里的“演员”。AGV模型不需要特别精细但有几个部位必须做出来因为前端要用它们做状态指示。车体主体一个扁长方体尺寸1.2m × 0.8m × 0.3m圆角处理。顶升盘车体上方一个圆形盘直径0.6m用于表示顶升状态。状态灯车体四角各一个小球或小圆柱前端通过改变材质颜色表示运行/停止/故障。方向指示车头一个三角形或箭头前端根据运动方向旋转。这里的关键是给这些部位单独命名并保持独立。比如状态灯命名为AGV_Light_FL、AGV_Light_FR等导出glTF后前端可以通过getObjectByName精确找到它们动态改颜色。如果全部合并成一个网格前端就没法单独控制了。AGV的建模我一般手动做因为细节多、需要反复调整比例MCP在这种精细活上不如手动灵活。但传送带、分拣口这些标准化设备可以用MCP批量生成。3.4 场景组装与层级管理所有模块建好后开始组装。这一步的核心是层级结构要清晰因为glTF会保留层级关系前端加载后可以直接按层级遍历。我的层级结构是这样的Warehouse_Root ├── Structure │ ├── Floor │ ├── Walls │ └── Pillars ├── Shelves │ ├── Shelf_Row_01 │ │ ├── Shelf_Unit_01 │ │ ├── Shelf_Unit_02 │ │ └── ... │ └── Shelf_Row_02 │ └── ... ├── Equipment │ ├── AGV_01 │ ├── AGV_02 │ ├── Conveyor_01 │ └── Sorting_Station_01 └── Markers ├── Waypoint_01 └── ...这个结构的好处是前端可以按组控制显隐比如只显示货架不显示设备可以按组做动画比如所有AGV统一更新位置可以按组做性能优化比如远处的货架用低模替换。组装时用关联复制AltD而不是独立复制ShiftD保证同一类模块共享网格数据。48组货架如果独立复制glTF文件可能上百MB关联复制的话网格数据只有一份文件能控制在10MB以内。4. 材质、优化与glTF导出规范4.1 PBR材质配置要点Three.js对PBR材质的支持很好所以Blender里直接用Principled BSDF就行导出glTF时会自动转换成metallic-roughness工作流。仓储场景的材质不复杂主要就几种材质Base ColorMetallicRoughness用途货架钢#4A55680.80.4货架立柱横梁层板#7180960.60.5货架层板地面#2D37480.10.8仓库地面AGV车体#E53E3E0.30.6AGV主体状态灯#48BB780.00.2状态指示传送带#1A202C0.20.7传送带表面这里有个坑要注意Blender里的颜色是线性空间glTF导出后会转成sRGB。如果你在Blender里直接填十六进制颜色导出后前端看到的颜色会偏亮。正确做法是在Blender里用线性值或者导出后在前端用color.setStyle()重新指定。我一般是在Blender里填个大概前端加载后再统一调色这样更可控。另一个坑是自发光材质。状态灯、显示屏这些需要发光的部位在Blender里用Emission节点。但glTF对自发光的支持有限导出后可能丢失。稳妥的做法是前端用MeshBasicMaterial或者给MeshStandardMaterial加emissive属性来模拟不依赖Blender的导出结果。4.2 网格优化与面数控制数字孪生场景要在浏览器里实时渲染面数是硬约束。我的经验值是整个场景控制在50万三角面以内中端显卡能跑60帧低端设备也能有30帧。优化手段按优先级排序合并同类网格48组货架如果每组都是独立网格draw call会爆炸。用Blender的Join功能把同一排的货架合并成一个网格draw call从48降到8。删除不可见面货架底部、靠墙的面、被遮挡的面全部删掉。用Blender的Select Interior Faces或者手动删。降低圆柱分段数AGV的轮子、立柱的圆角默认32段太多降到12段视觉上几乎没差别面数省一半。使用LOD远处的货架用简化版模型近处用完整版。这个在前端做Blender里准备两套模型即可。优化前后对比一下指标优化前优化后三角面数180万42万网格对象数32028glTF文件大小86MB9.2MB加载时间100Mbps7秒0.8秒这个优化幅度是实打实的不做的话前端根本跑不动。4.3 glTF导出参数详解Blender导出glTF的选项很多我挑几个关键的讲。格式选择选glTF Binary (.glb)单文件包含所有数据比glTFbin贴图的分离格式方便得多。前端一个GLTFLoader.load()就搞定。Include勾选Custom Properties这样Blender里给对象加的自定义属性比如货架编号、库位容量会一起导出前端可以读取。Transform勾选Y Up这是glTF的标准坐标系。Blender的Z-up会自动转成Y-up。Geometry勾选Apply Modifiers把修改器应用到网格上。勾选UVs和Normals材质需要。勾选Tangents如果你用了法线贴图。Compression如果文件还是太大可以开Draco压缩。但Draco需要前端额外加载解码器会增加一点复杂度。我的建议是文件小于20MB就不开Draco大于20MB再考虑。Animation如果Blender里有动画比如AGV的轮子转动勾选Animation导出。但数字孪生的动画一般是前端驱动的Blender里的动画主要用于预览可以不导出。导出后建议用glTF Viewer或者Three.js Editor先检查一遍确认模型完整、材质正确、层级清晰再交给前端。4.4 资产命名与元数据规范最后说一个容易被忽视但极其重要的点命名规范。前端要通过名字找对象如果Blender里命名乱七八糟前端代码就会充满魔法字符串维护起来很痛苦。我的命名规范是用英文不用拼音不用中文。用下划线分隔单词不用空格或横杠。类型前缀 编号比如Shelf_Unit_01、AGV_02、Conveyor_03。需要前端控制的部位加功能后缀比如AGV_01_Light_FL、Shelf_Unit_01_Indicator。元数据方面给每个货架对象加Custom Propertiesshelf_id: A-01-03 capacity: 50 current_usage: 32 zone: A这些属性会随glTF导出前端加载后可以直接读取用来做数据绑定。这样三维模型和业务数据就打通了孪生的“孪生”二字才落到实处。5. 常见问题与排查技巧实录5.1 Blender MCP使用中的典型问题问题一MCP指令执行到一半报错终止。这种情况我遇到过几次常见原因是指令里包含了Blender当前上下文不支持的操作。比如在物体模式下要求进入编辑模式做顶点操作MCP可能处理不了。解决办法是把复杂指令拆成多条简单指令每条只做一件事。另外确保Blender处于正确的模式物体模式/编辑模式再发指令。问题二MCP生成的模型尺寸不对。有时候AI会把“2米”理解成“2单位”而Blender的默认单位可能不是米。检查Scene Properties里的Unit Scale是否为1.0。另外指令里尽量用“米”这个单位词不要省略。问题三MCP连接不上Blender。先检查Blender的MCP插件是否启用再看服务端是否在运行最后确认端口没被占用。如果还是不行重启Blender和服务端通常能解决。这类连接问题多半是状态不同步导致的。5.2 导出后前端加载异常的排查模型不显示先看控制台有没有报错。如果glTF加载成功但看不到模型多半是相机位置不对或者模型尺寸太大/太小。用Box3.setFromObject()算一下模型包围盒看看尺寸是否符合预期。材质发黑通常是光照问题。Three.js默认没有环境光需要手动加AmbientLight和DirectionalLight。如果加了灯还是黑检查材质的metalness是不是太高金属度高的材质需要环境贴图才能正常显示。模型位置偏移Blender的Z-up转glTF的Y-up时如果父级对象有旋转转换会出错。检查Blender里所有顶层对象的旋转是否都是(0,0,0)。如果有旋转应用变换CtrlA → Rotation再导出。面数太多卡顿用renderer.info.render.triangles看实际渲染的三角面数。如果超过50万回到Blender做优化。另外检查是不是有对象没合并draw call太多也会卡。5.3 性能优化的独家经验分享几个我在实际项目中总结的优化技巧都是踩过坑才悟出来的。技巧一用InstancedMesh替代普通Mesh。如果前端要渲染大量相同物体比如100个托盘用THREE.InstancedMesh一次draw call搞定。但前提是这些物体共享几何体和材质且不需要单独控制。如果需要单独控制比如每个托盘颜色不同可以用instanceColor属性。技巧二纹理用KTX2压缩格式。普通PNG/JPG纹理在GPU里是解码后的原始数据显存占用大。KTX2格式可以直接被GPU读取显存占用减少75%以上。Three.js有KTX2Loader支持配合Basis Universal编码器使用。技巧三按需渲染而不是持续渲染。数字孪生场景如果数据不变化没必要每帧都渲染。用renderer.render()手动触发只在数据更新或相机移动时调用。这样GPU占用能降下来笔记本风扇也不会狂转。技巧四远处的货架用Sprite替代。如果相机拉得很远货架细节根本看不清用一张货架的贴图做成Sprite始终面向相机的平面性能提升明显。相机拉近时再切换回真实模型。提示优化是个持续过程不要指望一次做到位。先保证功能跑通再用Performance面板找瓶颈逐个优化。过早优化是万恶之源但完全不优化在数字孪生场景里也是不行的。5.4 资产版本管理建议最后提一个工程化的问题3D资产也要做版本管理。Blender文件.blend体积大直接扔Git里不合适。我的做法是.blend文件用Git LFS管理或者放网盘Git里只存导出的.glb。.glb文件命名带版本号比如warehouse_v1.2.glb。每次导出记录变更日志改了什么、为什么改、影响哪些前端代码。前端代码里引用glb的路径集中管理方便切换版本。这样做的目的是当出现问题时能快速定位是模型的问题还是代码的问题能回滚到上一个可用版本。数字孪生项目周期长、迭代多没有版本管理会非常痛苦。这个上篇到这里就把模型侧的事情讲完了。从场景规划、Blender建模、MCP辅助、材质优化到导出规范每一步都直接影响下篇前端能不能顺利跑起来。我个人在实际操作中的体会是模型侧多花一小时做规范和优化前端侧能省一天调试时间。尤其是命名规范和层级结构前端同事会感谢你的。下篇我会接着讲Vue 3 Three.js怎么把这套资产变成真正的数字孪生应用包括场景初始化、数据绑定、AGV动画、交互控制这些内容。