引擎不做建模器,复杂模型交给外部工具

**当渲染引擎需要在代码里手写顶点和面来造模型时,说明分工错了:引擎应该只负责「切模型 / 渲染模型」,建模交给外部工具,产物用标准格式(Blender → GLB)导入。**

一、判断信号

代码里出现这种「建模」写法,就是分不清职责:

// 手写顶点与面:引擎在充当建模器
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能力 —— 先跑通「外部建模 → 前端加载 → 切割」的最小闭环
  • 手搓编辑器核心逻辑到深处要评估换社区方案 —— 同源:核心职责该不该自己写,判据是「是否在重写成熟能力」