引擎一旦选定，后面的数据生产方式、开发人员配置和服务器投入都随之确定，中途更换的代价很高。选型时要回答的核心问题其实只有一个：这个场景是不是“地球上的真实位置”，用户在什么设备上看。
三类方案的本质差异 #
| 维度 | 开源 Web 三维引擎 | 商业三维 GIS 平台 | 游戏引擎类数字孪生 |
|---|---|---|---|
| 代表 | CesiumJS 等 | 各厂商三维 GIS 平台 | 基于 Unreal Engine、Unity 的方案 |
| 坐标体系 | 原生地球椭球、地理坐标 | 原生地理坐标，含成熟 GIS 分析 | 以局部笛卡尔坐标为主，大范围地理场景需专门处理精度与坐标转换 |
| 数据标准 | 3D Tiles、glTF、WMTS、地形服务等开放标准 | 开放标准 + 自有格式 | 以引擎资产格式为主，需导入转换 |
| 渲染位置 | 浏览器本地 WebGL | 浏览器本地 + 平台服务 | 本地客户端，或服务端渲染后像素流推送到浏览器 |
| 终端与服务器 | 普通办公电脑即可 | 普通办公电脑即可 | 画质高；推流模式下每路并发占用服务端 GPU 资源 |
| 授权 | 开源（CesiumJS 为 Apache 2.0） | 按平台授权 | 引擎授权条款 + 推流服务器成本 |
| 典型用途 | 管网、城市、园区三维一张图 | 标准化程度高、分析需求多的政务与测绘项目 | 指挥大屏、展厅等视觉效果优先的展示 |
判断要点 #
地理精度要求。 管网、城市、园区要与影像、地形、矢量数据精确套合，需要双精度地理坐标与投影转换能力。游戏引擎在大范围场景中使用单精度浮点时会出现抖动，需要额外的大世界坐标方案。
数据是否标准化。 倾斜摄影、BIM、管线统一转为 3D Tiles 后，可以在多数 Web 三维引擎中加载，引擎更换时数据通常不必重做。数据以引擎私有格式存储，迁移成本就高。
并发与成本。 浏览器本地渲染时，服务器只提供数据，用户增加不显著增加服务器负担。像素流推送把渲染放在服务端，每一路并发都需要 GPU 资源，适合少量大屏而非大量日常用户。
部署环境。 内网离线部署要求引擎、底图、地形与三维数据全部本地化；国产化项目需在国产操作系统与浏览器上实测 WebGL 兼容性。
团队与维护。 开源引擎需要二次开发能力；商业平台有厂商支持但受授权约束；游戏引擎方案需要美术与引擎开发人员，长期维护成本较高。
用样例验证代替参数对比 #
参数表只能缩小范围，最终应以真实数据验证：
- 列出必须实现的 3–5 个功能，如开挖剖切、横纵断面、实时监测联动；
- 选取一小片有代表性的区域，准备影像、地形、倾斜摄影或 BIM、管线数据；
- 在候选方案中完成加载与功能原型；
- 用首屏时间、帧率、峰值内存、落位误差四项指标比较，方法见倾斜摄影加载慢怎么办；
- 叠加授权、服务器与维护成本做决策。
我们的做法 #
管网与园区类项目，我们使用 Web 三维引擎做业务二次开发，三维数据统一生产为 3D Tiles：倾斜摄影与 BIM 用星火 3D Tiles 模型转换工具，管线数据用星火管网智绘平台参数化建模。数据与应用解耦，后续更换或升级引擎时数据可以复用。开发服务见三维可视化与数字孪生开发。