引擎不做建模器,复杂模型交给外部工具
一、判断信号
代码里出现这种「建模」写法,就是分不清职责:
// 手写顶点与面:引擎在充当建模器
const geometry = {
vertices: [[0,0,0],[2,0,0],[2,1,0]],
faces: [[0,1,2]]
}
手写顶点、面、法线很容易错,而且肉眼调比例极其痛苦 —— 复杂模型效果差,本质原因就在这里,不在渲染算法。
二、正确分工
| 环节 | 工具 |
|---|---|
| 建模 | Blender(导出 glTF/GLB)或网页建模工具 |
| 加载 | Three.js GLTFLoader 读 .glb / .gltf |
| 计算 | 现有引擎对每个 mesh 应用切割 plane,再算截面 |
GLB 适合 Web/H5:一个文件包含 mesh、材质、层级,移动端加载也方便。
题目数据里只需声明引用:
{ id: "q80", model: { type: "glb", url: "/models/q80.glb" }, cutMode: "free" }
引擎侧补的是「加载 → 遍历 mesh → 应用 plane → 算截面」,而不是新增建模能力。
三、边界
- 简单图形不值得建模 —— 参数化就能生成,交给人工建模是无意义的开销。
- 这条只对复杂模型成立:难点在复杂模型怎么变成一个可信的 3D 数据。
- 反过来,用外部工具也不等于还原正确:类型(参数体 / 方块体 / 自定义多面体)选错,模型再精细也是错的。
相关
- 几何题3D化的题库定位 —— 本条服务的场景:模型由题目决定
- 一次循环只做一个可体验的v1能力 —— 先跑通「外部建模 → 前端加载 → 切割」的最小闭环
- 手搓编辑器核心逻辑到深处要评估换社区方案 —— 同源:核心职责该不该自己写,判据是「是否在重写成熟能力」