3D扫描建模开发

项目背景

这是一条 3D 扫描重建的技术链路，横跨 8 个代码仓库，最后提交时间从 2024 年 6 月到 2026 年 5 月。链路从手机扫描端开始：Swift 负责 iOS 扫描，C++ 负责重建引擎，Python 负责模型处理，Java 加 Vue 组成业务平台（其中业务后端有 494 个 Java 文件，仓库内另有 101 篇 md 文档），JavaScript 做 H5 侧。整体是「端侧采集、服务端重建」的分工。

客户当时的状态

三维重建这件事有两个绕不开的矛盾。第一是耗时和体积：重建得越精细，耗时越长、模型越大，下游越难用；粗糙一点快，但做不了展示。第二是分工：手机上算力有限，全部放端侧做不现实；全部放服务端，又要解决采集质量不可控的问题——拍得歪、漏拍、光照不对，传上去重建出来就是个残模型。这两件事不定清楚，链路做出来也不能稳定产出可用的模型。还有一层是交付口径：模型最终给谁用、用来做什么，如果一开始没问清楚，重建参数就没有依据，做完了也难说是对是错。

我们的做法与取舍

第一个取舍是把采集与重建切开，端侧只管拍好，算力集中在服务端。端侧采集门槛低、覆盖广，重建这类重计算放在可控的服务端环境里，便于迭代算法而不必等 App 发版。

第二个取舍是在重建之后加一道模型处理环节，而不是把引擎的输出直接丢给下游。贴图、减面、格式转换这些事单独做，下游拿到的才是能直接用的模型。

第三个取舍是接受「精度与体积要按用途取舍」这个前提，不做一套参数打天下。展示用途和后续加工用途对模型的要求不同，参数要能按场景调。

系统怎么承载这条链路

链路分三段：扫描端负责采集与初步校验，重建引擎负责从采集数据生成模型，业务平台负责模型管理、处理与分发，H5 侧提供轻量入口。平台这一层是多语言拼起来的——Java 承载业务，Vue 承载界面，C++ 与 Python 在重建与处理环节各自负责擅长的部分。

交付状态与边界

代码处于维护状态，最近一次提交在 2026 年 5 月，最早可追溯到 2024 年 6 月。边界说明：我们能控制的是软件链路的稳定性，控制不了用户拍摄姿势与环境光线，采集质量差会直接反映在重建结果上；重建效果依赖具体设备与场景，我们不做「任何条件下都能还原」的承诺；扫描设备本身如果是专用硬件，其选型与采购不在开发范围内。