文章

逃离Unity：用Web开发、无人机和3D高斯泼溅把建筑塞进网页

发表于 更新于
作者 Moear
22 分钟阅读

前言

上一篇 Quest 3 + Unity 的文章写的是“怎么把 VR 工程交接下去”。但咱们也得说句实话：Unity 开发这玩意，对接手同学来说还是太重了。

装 Unity、配 Android、配 SDK、配头显、打 APK、真机调试，哪一步没踩过坑都不好意思说自己做过 VR。更麻烦的是，学长一毕业，后面的人要是没 Unity 基础，项目就很容易变成“能跑，但没人敢动”的祖传工程。

所以学长又想到了一个鬼点子：能不能别老逮着 Unity 折腾？能不能直接用 Web 开发，把模型、点云或者 3D 高斯泼溅丢进网页里，浏览器打开就能看，Quest 3 也直接用浏览器进 WebXR？

别人已经有现成例子了。极客湾做过一个办公室 room tour，把办公室用无人机和高斯泼溅扫描出来，再做成可以互动游玩的赛博展馆。视频在这里：

他们的思路大概就是：把真实办公室扫下来，放到 roomtour.socpk.com，然后让大家像逛游戏地图一样进去看办公室、看藏品、玩互动。我们当然不一定要做得和他们一样花，但方向可以摸着这个过河：现实空间扫描 + Web 互动 + 轻量部署。

这篇文章就按这个思路来讲：

  1. 为什么 Unity 之外还有 Web 这条路。
  2. Web 3D、点云、3D 高斯泼溅现在大概是什么状态。
  3. 用无人机航拍视频/照片，怎么把建筑还原出来。
  4. 以 RealityCapture/RealityScan 为例，怎么从照片走到可用模型。
  5. 怎么把模型压缩后丢进 Web。
  6. 最后给一份最小 index.html：后面的人只要替换一个模型，移动和 WebXR 基础组件都已经写好了。

本文还参考了我之前的 web端海洋文博管 项目，开源代码在 https://github.com/Moeary/Vue_Ocean_Museum 线上参观渠道在 https://oceanmuseum.vercel.app/#/3d 。那个项目里已经有一个 OceanScene.vue，用的是 Vue 3 + Three.js，支持 GLB 加载、PC 鼠标锁定移动、手机触摸旋转和 Quest 3 WebXR 摇杆移动, 后来者可以仿照着做。

一、这个点子到底靠不靠谱

Unity 的优势是完整、成熟、适合做真正的 VR 应用；

Web 的优势是轻、快、好传播。我们想逃离 Unity，不是因为 Unity 不行，而是因为这个项目如果只是“看建筑、逛展馆、做轻交互”，每次都编译 APK 真的太折磨。

1
2
3
4
5

无人机航拍
  -> RealityScan / RealityCapture 处理
  -> Blender 清理、减面、压缩、导出 GLB
  -> Web / Three.js 再压缩处理
  -> 浏览器呈现 3D 场景，必要时接 WebXR

这条线的好处是很现实：

这样安排以后，大家分工也更清楚：

  • 会飞无人机的人负责把素材拍好。
  • 会 RealityScan 的人负责把建筑算出来。
  • 会 Blender 的人负责把模型收拾干净。
  • 会 Web 的人负责把 GLB 丢进 Three.js，并把移动、缩放、热点、WebXR 做出来。

别一上来就纠结“哪个技术最先进”。先问几个更朴素的问题：

  • 能不能在手机上开？
  • 能不能在 Quest 3 浏览器里开？
  • 模型能不能控制在几十 MB，而不是几百 MB？
  • 后面的人能不能看懂这个流程，并且替换自己的建筑？

很多项目最后不是死在算法上，而是死在一个 800MB 的模型、一个加载半分钟的网页，以及一句“我这边打不开”。我们这条路线的核心目标就一个：先让东西能打开、能看、能交接。

二、当前 Web 3D 的现状

经过几年的发展，Web 3D 不是小玩具了。商品展示、数字孪生、WebGIS、在线展馆、轻量 VR 预览，都已经有人在用。它的问题不是“能不能做”，而是“你能不能把资产控制到浏览器吃得下”。

1. Web 3D 的主力仍然是 glTF/GLB

在 Web 里，glTF/GLB 基本就是 3D 资产交付的默认选择。Khronos 官方也把 glTF 定位成高效传输和加载 3D 场景/模型的格式，.glb 则是把 JSON、二进制 buffer、贴图等打进一个文件里的二进制版本。

Three.js 的 GLTFLoader 对 glTF 2.0 支持很完整，并且支持常见扩展，例如：

  • KHR_draco_mesh_compression
  • EXT_meshopt_compression
  • KHR_mesh_quantization
  • KHR_texture_basisu
  • EXT_texture_webp

翻译成人话就是：你可以先用 RealityCapture/RealityScan 把建筑算出来，再经过 Blender / glTF-Transform / gltfpack 这些工具压一压，最后变成浏览器能比较舒服加载的 .glb。

2. WebXR 不是 Unity 的完全替代品，但很适合偷懒

WebXR 最大的爽点是不用安装 APK。你把网页部署到 HTTPS（因为浏览器限制没有证书就不能访问webxr内容），Quest 3 浏览器打开，就能进入VR沉浸模式。

Three.js 里开启 WebXR 的核心非常简单：

1
2

renderer.xr.enabled = true;
document.body.appendChild(VRButton.createButton(renderer));

但 WebXR 的短板也很明显：

  • 浏览器权限和兼容性要看设备（但只做前后移动的话倒不用担心兼容性问题，基本都照着meta quest那样的遥感手柄来设计的）。
  • 复杂物理、复杂 UI、手势交互不如 Unity/Unreal 省心。
  • 大的glb模型会受移动端 GPU、内存和网络限制。

所以它适合做轻量 VR 看模型在线展馆预览快速给老师同学看效果。

所以实际上开发可以以web开发为主，先把模型展示、移动、WebXR 跑通；等场景都打的差不多了我们再回到之前的unity+meta quest vr开发之中，unity能直接写插件写shader获得更好的表现效果

三、3D 高斯泼溅：为什么适合我们的项目

3D Gaussian Splatting，简称 3DGS。名字很吓人，先不用怕。你可以粗暴理解成：它不是用一堆三角面片去拼物体，而是用很多带位置、方向、尺度、颜色和透明度的“椭球状点”去表示场景。

为什么它适合我们这种“把现实空间扫进网页”的活？因为它很擅长把照片里的真实观感保留下来。极客湾办公室那个例子能让人眼前一亮，也正是因为它不是传统低模展馆，而是直接把真实空间那种杂乱、细节、光照味道都端上来了（也有弊端，用高斯的话基本不太好后处理，比如环境打光啥的，相机拍到啥就是啥样，没法模拟晚上关灯或者灯光全开时的视角）。

2023 年 SIGGRAPH 的经典论文《3D Gaussian Splatting for Real-Time Radiance Field Rendering》把这条路线带火了。它的关键优势是：

  • 输入可以来自多张照片或视频抽帧。
  • 训练完成后可以实时渲染。
  • 对真实场景的细碎纹理、树叶、栏杆、雕塑、反光材质表现很好。
  • 比早期很多 NeRF 路线更适合交互式浏览。

但现在做 Web 项目时要注意：3DGS 还不是传统意义上的“普通 3D 模型”，不要以为它能像 FBX/GLB 一样到处乱塞。

它的坑主要有：

  1. 格式还在快速变化：.ply、.splat、.spz、.ksplat、.sog 都有人用。
  2. 浏览器加载需要专门 renderer，不是 GLTFLoader 直接加载就完事。
  3. 物理碰撞、遮挡剔除、测量、编辑和材质系统还不如网格成熟。
  4. 文件可能很大，不压缩很容易几十到几百 MB。

好消息是标准化已经在推进。Khronos 在 2026 年 2 月发布了 KHR_gaussian_splatting 的 glTF 扩展候选，目标是让 Gaussian Splat 能进入 glTF 生态。这个很重要，因为一旦 glTF 生态接住 3DGS，以后工具链会少很多“这玩意只能在某某 viewer 打开”的尴尬。

对于我们的项目，我们目前没必要死磕他的格式，我们把3d高斯转出的模型都丢进blender里面后处理一下导出glb的就能用了

四、用无人机航拍还原建筑内外视角

Epic家的 RealityScan 软件很强，但它不是魔法。照片烂，软件也救不回来。很多人第一次做重建，问题不是不会点按钮，而是素材从一开始就拍崩了。

参考教程可以看 【【全】大型校园无人机倾斜摄影建模指南】 https://b23.tv/BV1W3411s72V

1. 拍摄原则

无人机拍建筑时，尽量做到：

  1. 相邻照片重叠率 70% 到 85%。
  2. 不只拍正上方，要拍斜向环绕，建筑立面需要 oblique 角度。
  3. 一栋楼至少绕 2 到 3 圈：低空立面一圈、中高空一圈、俯视一圈。
  4. 曝光和白平衡尽量锁定，不要一会儿亮一会儿暗。
  5. 避开强反光、雨天、雾天、大风和强烈移动阴影。
  6. 避开大面积玻璃幕墙、纯白墙、纯黑墙、重复窗格，这些区域要多角度补拍。
  7. 拍摄时尽量不要让路人、车、树叶大幅移动占据主体。

如果只有视频，也可以用视频抽帧：

  • 4K 视频优于 1080p。
  • 抽帧不要太密，一般 1 到 3 FPS 先试。
  • 模糊帧、转场帧、过曝帧要删掉。
  • 抽出的图片最好保持原始分辨率。

2. 航线建议

以一栋教学楼或展馆为例，可以这样拍：

航线作用
正射网格获得屋顶和整体平面结构
45 度斜拍网格获得屋顶边缘、立面上半部分
环绕立面获得门窗、柱子、墙面纹理
低空补拍补入口、牌匾、台阶、雕塑

如果建筑周围树很多，3DGS 可能看起来比网格舒服，因为树叶这类细碎结构对网格重建很不友好。但如果你要做碰撞和漫游，树可以单独简化，不要强行把每片叶子都网格化。真的，别和树叶较劲。

五、利用软件处理航拍数据

软件首推 RealityScan。它们都支持照片和视频输入，能自动对齐、重建、生成高模，还能输出贴图。RealityScan 是 Epic 免费提供的工具，适合快速上手

但这一部分不细讲，看其他人的教程更合适

b站其他人的教程：【RealityScan2.0 + Blender测量摄影 建模、修复、简化发布全流程】 https://b23.tv/BV12guwzdEkL

官方教程demo：https://dev.epicgames.com/community/realityscan/learning

1. 准备图片/视频

有需要的可以私聊我（如果你有我联系方式的话）获取相关建筑航拍素材作为参考

2. 导入并对齐

3. 设置重建区域

4. 生成高模

5. 简化模型

6. 贴图

7. 导出为 OBJ/FBX/GLB，转入blender做后处理

六、把建筑模型压到 Web 能跑

到这一步，建筑已经“捏”出来了，但还不能直接丢网页。RealityScan 算出来的东西通常很大，属于电脑看着都喘、浏览器看了想辞职的那种。

0. Blender后处理

把模型导入 Blender，检查比例、原点、朝向，清理飞面和无关区域，简化到 100k 到 500k 三角面，重新 unwrap 和贴图，最后导出为 GLB文件。

1. 目标大小

普通网页模型建议先按这个目标控制：

平台单模型建议大小
手机网页10MB 到 40MB
PC 网页30MB 到 120MB
Quest 3 WebXR20MB 到 80MB
校园内网大屏可以更大，但仍建议分块加载

如果一个模型压完还有 300MB，不是绝对不能用，但体验会很痛苦。尤其是 Quest 3 浏览器，因为要双目渲染，同时分辨率还高，内存和 GPU 都比台式机紧张。我们做场馆还原web路线，本来就是为了省事，不是为了换一种方式折磨自己。

2. glTF/GLB 压缩方向

Web GLB 常用优化有三类：

优化作用
Meshopt压几何、重排顶点、提升传输和加载效率
Draco强几何压缩，体积小，但解码成本更高
KTX2/BasisU纹理 GPU 压缩，降低文件体积和显存压力

Three.js 的 GLTFLoader 已经支持 Draco、Meshopt、KTX2 等扩展，但需要在代码里配置对应 decoder。

3. glTF-Transform 示例

安装：

1

npm install --global @gltf-transform/cli

先检查模型：

1

gltf-transform inspect building.glb

常规压缩：

1

gltf-transform optimize building.glb building.web.glb --texture-compress webp --compress meshopt

如果希望贴图走 KTX2：

1

gltf-transform optimize building.glb building.ktx2.glb --texture-compress ktx2 --compress meshopt

如果模型几何特别大，也可以尝试 Draco：

1

gltf-transform draco building.glb building.draco.glb

我个人对 WebXR 更偏向先试 Meshopt + KTX2。Draco 体积可能更小，但首屏解码可能更慢。具体还是以真机测试为准。

4. 简单验收标准

压完以后至少检查：

  1. PC Chrome 能打开，并且测试一轮 Chrome 浏览器自带的 Lighthouse，性能分数尽量达到 60 分以上。

  2. 手机 Chrome/Edge/Safari 能打开。
  3. Quest 3 浏览器能打开。
  4. 进入 VR 后不黑屏。
  5. 移动时帧率不明显掉。
  6. 贴图没有丢。
  7. 模型比例和朝向正确。

不要只在自己电脑的高配置显卡上看，那个不算数。

七、工作流总结

1
2
3
4
5

无人机航拍
  -> RealityScan 处理
  -> Blender 压缩并导出 GLB
  -> Web / Three.js 再压缩处理
  -> 浏览器呈现场景

这就是为什么前面要简化流程。我们不是为了炫工具链，而是为了让后面的人能照着做：换一栋楼，换一批照片，重新跑一遍，就能得到一个新的 Web 3D 建筑场景。

最后记住一句话：Web 端不是不能放大场景，而是要按 Web 的方式组织资产。

网格要简化，贴图要压缩，GLB 要继续优化，高斯泼溅和点云可以作为扩展路线。把主线跑通以后，再去加照片级 3DGS 展示、点云档案、WebXR 交互，这样才不会一开始就把项目复杂度拉爆。

Unity 那套工程当然还能继续维护，但如果只是想做一个能传播、能打开、能让人快速看到效果的建筑展馆，无人机航拍 -> RealityScan -> Blender -> GLB -> Three.js 这条路确实值得试。极客湾已经把办公室做成赛博展馆给我们看过一次了，我们没必要闭门造车。先摸着他们过河，跑通，再慢慢加自己的东西。

参考资料

Web, 3D
web3d three.js webxr 3D Gaussian Splatting point cloud RealityCapture photogrammetry
本文由作者按照 CC BY 4.0 进行授权