最近在做一个三维钓鱼网页岸边需要重复摆放树木、石头和芦苇。同一份模型会出现在不同位置大小和朝向也不一样。项目里采用了InstancedMesh。把 GLB 转成实例批次时有几件事需要一起处理模型可能包含多个 Mesh节点还有父级变换不同素材的尺寸和原点不统一退出场景时几何和材质又可能还被别处使用。这篇就围绕这条处理链展开。项目依赖 Three.js0.186.1文中的代码片段保留关键步骤限定处理普通静态模型。1. 一棵树包含三个 Mesh不能当成一个网格处理假设模型结构是这样TreeRoot └─ ScaledGroup ├─ Trunk 树干 ├─ Branches 树枝 └─ Leaves 树叶直接复制整个对象层级每棵树仍然有三份 Mesh 节点。即使 geometry 和 material 共用绘制提交也不会因此自动合成一批。我的处理方式是同一个源 Mesh 的所有摆放位置放进一个 InstancedMesh。上面的模型会变成三个实例批次每个批次保存 N 棵树对应的矩阵。这符合InstancedMesh对相同几何、材质和不同变换的使用方式。官方说明在一个简化条件下——三个 Mesh 各自只有一次有效材质绘制只看单次颜色通道——N 份普通对象大约需要3 × N次提交实例化后大约是 3 次。这是说明原理的估算实际项目还要算材质分组、阴影、反射以及其他通道。而且N 棵树的顶点和像素仍然要处理。实例化主要减少重复提交不会把它们的几何工作量变成一棵树。2. 实例矩阵里要保留源节点的父级变换GLB 的树干不一定直接挂在根节点下。父级可能有平移、旋转和缩放只复制子 Mesh 的position就会丢掉这部分信息。构建批次前先更新完整层级source.updateWorldMatrix(true,true);然后使用各源 Mesh 的matrixWorld。它包含当前节点到世界坐标的层级变换和只表示局部变换的matrix不同。Object3D 矩阵说明我把最终实例矩阵拆成三部分矩阵作用M源 Mesh 的matrixWorld保留素材内部布局N整体归一化将模型高度变成 1包围盒底部中心移到原点P本次摆放的位置、朝向和实际尺寸对于列向量组合关系是instanceMatrix P × N × M一个顶点从右往左依次经过源层级变换 → 模型归一化 → 放到钓场中。这里还约定P使用输出批次所在 Group 的局部坐标。这个 Group 如果再挂到一个有变换的父对象下父对象的变换还会继续作用。若手里拿的是目标世界矩阵需要先换算成该 Group 的局部矩阵不能直接混用。归一化时先平移再缩放假设已经合并了源模型的可见几何包围盒bounds可以这样生成Nconstheightbounds.max.y-bounds.min.y;constnormalizenewTHREE.Matrix4().makeScale(1/height,1/height,1/height,);normalize.multiply(newTHREE.Matrix4().makeTranslation(-(bounds.min.xbounds.max.x)/2,-bounds.min.y,-(bounds.min.zbounds.max.z)/2,));这里得到的是S × T先减去包围盒底部中心再按整体高度缩放。生成矩阵之前还要拒绝空模型、非有限高度和接近零的高度避免除零或把错误矩阵继续传给 GPU。拿一个简单数字验证底部中心的 X 为 10模型高度为 2。正确顺序是(10 - 10) / 2 0如果换成先缩放再平移就成了10 / 2 - 10 -5。这类错误经常表现为模型大小看起来对了位置却一直偏改素材尺寸后偏移量还跟着变。Matrix4.multiply()会修改调用它的矩阵因此填写实例数据时我使用临时矩阵不改调用方传入的摆放矩阵。Matrix4 接口3. 每个源 Mesh 建一个批次再更新包围体核心构建过程如下。parts是收集好的可见静态 Meshplacements是摆放矩阵数组normalize是上一节的整体归一化矩阵constgroupnewTHREE.Group();constcombinednewTHREE.Matrix4();for(constpartofparts){constmeshnewTHREE.InstancedMesh(part.geometry,part.material,placements.length,);mesh.castShadowpart.castShadow;mesh.receiveShadowpart.receiveShadow;for(leti0;iplacements.length;i){combined.copy(placements[i]).multiply(normalize).multiply(part.matrixWorld);mesh.setMatrixAt(i,combined);}mesh.instanceMatrix.needsUpdatetrue;mesh.computeBoundingBox();mesh.computeBoundingSphere();group.add(mesh);}包围体这一步会影响视锥裁剪和拾取。构建后如果又通过setMatrixAt()移动了实例需要重新检查包围体不能只更新矩阵缓冲。官方包围体与矩阵更新说明整片场景塞进一个超大批次也有代价批次的整体包围球只要进入视野就可能提交很多实际看不到的实例。场景扩大后可以按空间区域拆批再比较增加的提交次数和减少的几何工作量。本文示例针对普通静态模型按 Y 轴为高度使用常规平移、旋转和正均匀缩放。骨骼、变形动画、镜像/剪切、自定义顶点位移和复杂透明排序需要单独处理不能直接套这个函数。4. 共享模型时清理责任比遍历更重要实例批次直接借用了part.geometry和part.material。此时退出一个场景如果遍历到什么就全部dispose()可能把其他批次还在使用的资源也处理掉。我按资源归属来拆清理职责资源由谁负责当前 InstancedMesh 的实例数据当前批次当前世界为改色等操作克隆的材质当前世界源 GLB 的几何、材质与共享贴图素材缓存或资产所有者独立示例返回一个带group和dispose()的句柄。释放时移除当前组调用各批次的InstancedMesh.dispose()清空节点引用不会对借来的几何和材质调用销毁。InstancedMesh.dispose()负责该实例对象分配的资源潜在共享的几何、材质和纹理需要另外管理。实例清理说明、共享资源说明在项目实际代码里这层关系对应AssetScope同一作用域内使用相同 URL 只登记一次引用共用正在加载的 Promise离开世界时先减少引用再按缓存策略处理零引用资源。引用归零可以成为回收条件但不要求立即回收。克隆材质也要继续分清贴图是谁的我的场景会调整部分树叶材质和颜色所以先克隆材质再修改参数。以标准材质为例constlocalMaterialsourceMaterial.clone();localMaterial.color.set(#78965c);在项目锁定版本的MeshStandardMaterial.copy()中颜色值被复制而map等贴图仍然引用源纹理。因此本世界拥有这个新材质不等于也拥有贴图。离开世界时释放localMaterial贴图继续由资产所有者管理。几何、材质、纹理是不同层面的资源不能因为对象层级被复制了一份就默认所有资源都变成独占。5. 用一致的渲染口径检查别只看一次 calls批量化后我会检查两类问题模型是否仍在正确位置以及绘制提交是否按预期变化。Three.js 的renderer.info提供渲染和资源统计。一个可见帧包含多个渲染调用时可以关闭每次调用后的自动重置统一采样。统计接口说明renderer.info.autoResetfalse;renderer.info.reset();renderFrame();// 应包含这一帧实际使用的各个渲染调用。console.table({calls:renderer.info.render.calls,triangles:renderer.info.render.triangles,geometries:renderer.info.memory.geometries,textures:renderer.info.memory.textures,});比较时保持相同相机、画质、阴影和反射设置。只取主画面中的一部分调用容易漏掉额外通道的成本。memory.geometries和memory.textures是数量不是显存字节数。它们也不能代替 JavaScript 堆快照或 GPU 性能分析。若项目会重建 renderer还要分别看各实例以及跨世界保留的素材缓存。为了把矩阵和资源归属先验证清楚我另外做了一个独立示例用合成几何完成了 10 项自动测试覆盖嵌套变换、底部中心对齐、输入矩阵不被修改、多材质、重复释放以及共享资源不被误释放。它不创建 WebGL 上下文真实画面和性能仍需在浏览器里检查。这些处理思路用在我开发的闲钓小栈中目前是电脑端单人三维垂钓与学习预览。体验地址闲钓小栈。
最近在做一个三维钓鱼网页岸边需要重复摆放树木、石头和芦苇。同一份模型会出现在不同位置大小和朝向也不一样。项目里采用了InstancedMesh。把 GLB 转成实例批次时有几件事需要一起处理模型可能包含多个 Mesh节点还有父级变换不同素材的尺寸和原点不统一退出场景时几何和材质又可能还被别处使用。这篇就围绕这条处理链展开。项目依赖 Three.js0.186.1文中的代码片段保留关键步骤限定处理普通静态模型。1. 一棵树包含三个 Mesh不能当成一个网格处理假设模型结构是这样TreeRoot └─ ScaledGroup ├─ Trunk 树干 ├─ Branches 树枝 └─ Leaves 树叶直接复制整个对象层级每棵树仍然有三份 Mesh 节点。即使 geometry 和 material 共用绘制提交也不会因此自动合成一批。我的处理方式是同一个源 Mesh 的所有摆放位置放进一个 InstancedMesh。上面的模型会变成三个实例批次每个批次保存 N 棵树对应的矩阵。这符合InstancedMesh对相同几何、材质和不同变换的使用方式。官方说明在一个简化条件下——三个 Mesh 各自只有一次有效材质绘制只看单次颜色通道——N 份普通对象大约需要3 × N次提交实例化后大约是 3 次。这是说明原理的估算实际项目还要算材质分组、阴影、反射以及其他通道。而且N 棵树的顶点和像素仍然要处理。实例化主要减少重复提交不会把它们的几何工作量变成一棵树。2. 实例矩阵里要保留源节点的父级变换GLB 的树干不一定直接挂在根节点下。父级可能有平移、旋转和缩放只复制子 Mesh 的position就会丢掉这部分信息。构建批次前先更新完整层级source.updateWorldMatrix(true,true);然后使用各源 Mesh 的matrixWorld。它包含当前节点到世界坐标的层级变换和只表示局部变换的matrix不同。Object3D 矩阵说明我把最终实例矩阵拆成三部分矩阵作用M源 Mesh 的matrixWorld保留素材内部布局N整体归一化将模型高度变成 1包围盒底部中心移到原点P本次摆放的位置、朝向和实际尺寸对于列向量组合关系是instanceMatrix P × N × M一个顶点从右往左依次经过源层级变换 → 模型归一化 → 放到钓场中。这里还约定P使用输出批次所在 Group 的局部坐标。这个 Group 如果再挂到一个有变换的父对象下父对象的变换还会继续作用。若手里拿的是目标世界矩阵需要先换算成该 Group 的局部矩阵不能直接混用。归一化时先平移再缩放假设已经合并了源模型的可见几何包围盒bounds可以这样生成Nconstheightbounds.max.y-bounds.min.y;constnormalizenewTHREE.Matrix4().makeScale(1/height,1/height,1/height,);normalize.multiply(newTHREE.Matrix4().makeTranslation(-(bounds.min.xbounds.max.x)/2,-bounds.min.y,-(bounds.min.zbounds.max.z)/2,));这里得到的是S × T先减去包围盒底部中心再按整体高度缩放。生成矩阵之前还要拒绝空模型、非有限高度和接近零的高度避免除零或把错误矩阵继续传给 GPU。拿一个简单数字验证底部中心的 X 为 10模型高度为 2。正确顺序是(10 - 10) / 2 0如果换成先缩放再平移就成了10 / 2 - 10 -5。这类错误经常表现为模型大小看起来对了位置却一直偏改素材尺寸后偏移量还跟着变。Matrix4.multiply()会修改调用它的矩阵因此填写实例数据时我使用临时矩阵不改调用方传入的摆放矩阵。Matrix4 接口3. 每个源 Mesh 建一个批次再更新包围体核心构建过程如下。parts是收集好的可见静态 Meshplacements是摆放矩阵数组normalize是上一节的整体归一化矩阵constgroupnewTHREE.Group();constcombinednewTHREE.Matrix4();for(constpartofparts){constmeshnewTHREE.InstancedMesh(part.geometry,part.material,placements.length,);mesh.castShadowpart.castShadow;mesh.receiveShadowpart.receiveShadow;for(leti0;iplacements.length;i){combined.copy(placements[i]).multiply(normalize).multiply(part.matrixWorld);mesh.setMatrixAt(i,combined);}mesh.instanceMatrix.needsUpdatetrue;mesh.computeBoundingBox();mesh.computeBoundingSphere();group.add(mesh);}包围体这一步会影响视锥裁剪和拾取。构建后如果又通过setMatrixAt()移动了实例需要重新检查包围体不能只更新矩阵缓冲。官方包围体与矩阵更新说明整片场景塞进一个超大批次也有代价批次的整体包围球只要进入视野就可能提交很多实际看不到的实例。场景扩大后可以按空间区域拆批再比较增加的提交次数和减少的几何工作量。本文示例针对普通静态模型按 Y 轴为高度使用常规平移、旋转和正均匀缩放。骨骼、变形动画、镜像/剪切、自定义顶点位移和复杂透明排序需要单独处理不能直接套这个函数。4. 共享模型时清理责任比遍历更重要实例批次直接借用了part.geometry和part.material。此时退出一个场景如果遍历到什么就全部dispose()可能把其他批次还在使用的资源也处理掉。我按资源归属来拆清理职责资源由谁负责当前 InstancedMesh 的实例数据当前批次当前世界为改色等操作克隆的材质当前世界源 GLB 的几何、材质与共享贴图素材缓存或资产所有者独立示例返回一个带group和dispose()的句柄。释放时移除当前组调用各批次的InstancedMesh.dispose()清空节点引用不会对借来的几何和材质调用销毁。InstancedMesh.dispose()负责该实例对象分配的资源潜在共享的几何、材质和纹理需要另外管理。实例清理说明、共享资源说明在项目实际代码里这层关系对应AssetScope同一作用域内使用相同 URL 只登记一次引用共用正在加载的 Promise离开世界时先减少引用再按缓存策略处理零引用资源。引用归零可以成为回收条件但不要求立即回收。克隆材质也要继续分清贴图是谁的我的场景会调整部分树叶材质和颜色所以先克隆材质再修改参数。以标准材质为例constlocalMaterialsourceMaterial.clone();localMaterial.color.set(#78965c);在项目锁定版本的MeshStandardMaterial.copy()中颜色值被复制而map等贴图仍然引用源纹理。因此本世界拥有这个新材质不等于也拥有贴图。离开世界时释放localMaterial贴图继续由资产所有者管理。几何、材质、纹理是不同层面的资源不能因为对象层级被复制了一份就默认所有资源都变成独占。5. 用一致的渲染口径检查别只看一次 calls批量化后我会检查两类问题模型是否仍在正确位置以及绘制提交是否按预期变化。Three.js 的renderer.info提供渲染和资源统计。一个可见帧包含多个渲染调用时可以关闭每次调用后的自动重置统一采样。统计接口说明renderer.info.autoResetfalse;renderer.info.reset();renderFrame();// 应包含这一帧实际使用的各个渲染调用。console.table({calls:renderer.info.render.calls,triangles:renderer.info.render.triangles,geometries:renderer.info.memory.geometries,textures:renderer.info.memory.textures,});比较时保持相同相机、画质、阴影和反射设置。只取主画面中的一部分调用容易漏掉额外通道的成本。memory.geometries和memory.textures是数量不是显存字节数。它们也不能代替 JavaScript 堆快照或 GPU 性能分析。若项目会重建 renderer还要分别看各实例以及跨世界保留的素材缓存。为了把矩阵和资源归属先验证清楚我另外做了一个独立示例用合成几何完成了 10 项自动测试覆盖嵌套变换、底部中心对齐、输入矩阵不被修改、多材质、重复释放以及共享资源不被误释放。它不创建 WebGL 上下文真实画面和性能仍需在浏览器里检查。这些处理思路用在我开发的闲钓小栈中目前是电脑端单人三维垂钓与学习预览。体验地址闲钓小栈。
