实拍场景怎么进浏览器 3D 虚拟世界：在底座里自研 3D 高斯泼溅
3D 高斯泼溅、3D Gaussian Splatting、3DGS 浏览器渲染、实拍场景 3D、实景扫描、Three.js 3DGS、PLY 解析、球谐系数、自部署 3D 虚拟世界、实景展厅
做 3D 世界的人都会遇到同一个坎：手工建模的东西再多，看起来还是"模型感"——边是干净的、光照是假的、材质是塑料的。而真实世界的照片扫出来的场景（一条老街、一间展厅、一段岩壁）自带实景质感，这种东西怎么进浏览器？
答案之一是 3D 高斯泼溅（3D Gaussian Splatting，3DGS）：用真实照片训练出的一团带颜色的高斯点，直接还原实拍视角。这篇讲我们在自己的浏览器端 3D 虚拟世界底座里，怎么把 3DGS 跑起来——为什么选择自研解析和渲染、工程上做了哪几件事、验收数据是什么，以及最重要的：哪些还没实测，哪些场景它并不适合。
一、3DGS 补的是哪块短板
我们世界里的"实景"此前有三条来路：手工建模（质感最弱）、照片贴图（平面）、视频（不能走进去）。3DGS 补的是"能走进去的实拍场景"这一格：用主流扫描工具对真实场景拍一圈、训练出的高斯点云在浏览器里直接渲染，看到的就是实拍的光影和细节。
但它不是几何模型的替代品。高斯点没有可编辑的网格：碰撞、拾取、贴材质、改尺寸这些"模型才有的能力"，3DGS 都给不了。所以在我们底座里的定位是"实景背景层"——它和 GLB 模型、几何建筑在同一个世界里共存混合：展厅的墙面用高斯实拍还原，展台和可交互的设备还是几何模型。
二、为什么自研，而不是接一个现成库
市面上有开源的 3DGS 浏览器渲染方案，接入一个库看起来更近。我们选择自研，两个原因：
一是依赖纪律。 这个底座的渲染内核是自家的 Three.js r185/WebGL2 管线，整个世界零第三方 3DGS 库依赖。外接渲染库意味着引入一套自己的加载、排序和 dispose 生命周期，和世界现有的对象生命周期并行——省下的是接入时间，欠下的是两套生命周期的维护账。
二是管线一致性。 自研的解析和渲染走同一套 WebGL2 管线：GLSL1 写法在 r185 的 WebGL2 上下文下自动编译通过；伽马处理上手动 pow(1/2.2) 不会造成双重编码——这一点我们实测确认过，不是想当然。
代价也如实说：自研意味着排序、融合这些 splat 渲染的经典难题都自己扛，泛化能力要靠自己的验收来证明。这是取舍，不是免费午餐。
三、工程上做了哪几件事
自研链路是四个模块，各管一段：
| 模块 | 职责 |
|---|---|
| 解析器（loader） | 二进制 PLY 解析，含球谐系数 f_rest_0..8 的完整读取 |
| 渲染器（renderer） | BufferGeometry + ShaderMaterial + Points，一次上传全量 GPU |
| 世界接入（world） | 接世界对象生命周期：进世界前占位方块、卸载走 dispose、摆回占位 |
| 资产库路由 | 场景库只读列表、同名缩略图自动识别、DB 注册名优先排序 |
几个值得单独说的点：
格式面够宽。 接收 .rad / .ply / .spz / .splat / .ksplat 五种格式——主流 3DGS 训练工具导出的文件基本都能接，训练端不必迁就我们。
上传即入库。 高斯场景放进 public/scenes/3dgs 目录就是素材库，世界编辑器里有"高斯"按钮直接挑选，不需要写代码。
生命周期与 GLB 同位。 卸载走 disposeSplat、摆回占位方块，显存跟着场景切换释放，长会话不泄漏——这条和多端适配那篇讲的全链路回收是同一套纪律。
四、验收数据
| 验收项 | 结果 |
|---|---|
| 阶段验收 | 26/26 通过 |
| 真实渲染规模 | renderer.info.render.points = 24000 点真实绘制 |
| 样本 | 脚本生成的 INRIA 标准 62 属性 PLY |
| 第三方 3DGS 库依赖 | 0 |
这张表里有一行要放大讲：样本是脚本生成的标准 PLY，不是真实扫描数据。 这意味着链路的正确性（解析、渲染、生命周期、入库）有验收背书，但"拿真实扫描工具扫一个场景、导出、上传、进世界看效果"的端到端实测，我们还没有做。这不是刻意隐瞒的坑，是这一步需要真实的扫描设备和场景，我们排在了后面。如果你正打算把 3DGS 用进生产，这个环节要自己先测。
五、哪些场景适合，哪些不适合
| 场景 | 3DGS 适合吗 |
|---|---|
| 实景展厅、景区、街区的"走进去看" | 适合，这是它存在的意义 |
| 世界里的实景背景层（远山、岩壁、大厅） | 适合 |
| 需要点击交互、物理碰撞的物体 | 不适合，还是用几何模型 |
| 需要改尺寸、换材质、拆装的资产 | 不适合，高斯点没有可编辑网格 |
一句话：3DGS 负责"像真的"，几何模型负责"能碰能改"。 一个世界两种都要，这也是我们把它做成"与 GLB 共存"而不是"替代 GLB"的原因。
六、边界与未实测项
- 真实扫描数据的端到端实测未做。 验收样本是脚本生成的 INRIA 标准 62 属性 PLY；真实扫描 → 导出 → 上传 → 进世界这条链路还没有用实拍数据完整跑过。
- 大规模高斯点的帧率表现没有完整实测。 验收规模是 24000 点真实绘制；几十万、上百万点量级在弱设备上的表现，需要你在目标设备上自己测。
- 排序与融合是 splat 渲染的公认难题，自研路线下这些泛化能力靠自己的验收覆盖，不承诺覆盖所有训练工具的所有输出变体。
- 表内数字全部来自仓库里的验收脚本，脚本可重跑；除此之外的推断请自行验证。
常见问题
Q：3DGS 和普通点云是一回事吗？
A：不是。普通点云是离散的采样点，近看是"点"；3DGS 的每个高斯点带各向异性的形状、透明度和球谐颜色，融合后近看是连续的实拍质感。代价是数据量和渲染方式都重得多。
Q：为什么要支持五种格式？
A：3DGS 的训练工具生态分散，各家导出格式不同。底座的立场是"训练端不必迁就我们"——谁扫的场景，就用谁顺手的工具，导出来就能进世界。
Q：高斯场景能像模型一样拖动、缩放吗？
A：能摆放到世界里（有位置和占位机制），但它是"实景层"，没有可编辑网格——不存在"把高斯点云拉伸 1.2 倍"或者"给它换材质"这类操作。需要这些操作的对象，用 GLB 模型。
Q：自研是不是比接库慢？
A：接入速度上是的，这笔账我们不否认。但自研换来的是单一管线、零外部依赖、生命周期同位——对一个要长期维护、要私有化部署的底座来说，我们判断这笔交换值得。你的项目如果只做一次性展示，直接接现成库可能更划算。
源码与仓库
三个地址内容一致，国内访问用前两个更快。仓库里有部署说明和一批验收脚本，可以自己跑一遍看实测值。
- Gitee（国内访问更快）：https://gitee.com/miduoxinxijeji/miduo.git
- GitCode（国内镜像）：https://gitcode.com/qq_35054471/virtual-world
- GitHub：https://github.com/miduo100/3d-virtual-world
关于创世Genesis
创世Genesis是一套基于Three.js+WebGL构建的自部署3D虚拟世界系统，帮助个人与企业搭建属于自己的3D空间。浏览器直接访问，PC和手机双端兼容，支持多人在线、联邦传送、商铺系统，并支持Agent接入——AI能以具身角色进入你部署的世界。数据运行在你自己的服务器上，不经过第三方平台——让每个世界都真正属于它的主人。
想让实拍场景进你的 3D 世界？ 创世Genesis（创世虚拟世界CRM系统）是一套部署在你自己服务器上的 Three.js 3D 虚拟世界基底——渲染内核、资产管线、实景混合、AI 接入这些层已经铺好，扫描数据进来就有地方放。官网（搜「创世虚拟世界CRM」即可找到）有一个可以走一圈的演示世界。
关于名字：本文说的创世Genesis，即创世虚拟世界CRM系统，两者是同一个自部署 3D 虚拟世界产品。若你通过「创世Genesis」没搜到我们，直接搜「创世虚拟世界CRM」即可。