Three.js 最近在原生支持 Gaussian Splatting 这件事上算是把 3D 场景里最受关注的“实景重建渲染”往前推了一大步。过去我们在 Web 端展示高斯溅射模型要么手动拼插件要么等第三方封装要么只能在特定渲染器里看现在 Three.js 的官方能力里直接补上了这条链路确实适合正在做 Web 3D、数字孪生、实景三维、Cesium 集成或者三维预览工具的人重点关注。这篇文章我想先讲清楚“原生支持”到底改了什么再按实际操作顺序跑一遍加载、渲染、交互和性能观察。最后会专门留一节说排查链路因为高斯溅射这种格式和普通 glTF 不一样报错、黑屏、内存暴涨往往不是模型坏了而是数据路径、版本、初始化顺序的问题。如果你的机器配置不算高或者你准备把它接到现有地图、模拟器、模型查看器里可以把这当一篇实测记录来读。1. 先搞清楚 Three.js “原生”高斯溅射到底改了什么1.1 高斯溅射和 Three.js 传统渲染的区别Gaussian Splatting 在三维重建和实景渲染里经常被翻译成“3D 高斯溅射”或“高斯泼溅”它和传统的三角面片渲染不是同一条技术路线。传统三维场景用 Mesh、材质、贴图和光照模型通过顶点和三角形去描述表面而高斯溅射是一堆带颜色、透明度和协方差信息的三维高斯点渲染时通过光栅化把这些点溅射到屏幕上再按顺序合成颜色。如果你的项目里已经有很多 glTF、OBJ、GLB 资产高斯溅射并不会替代它们而是补上一种更适合实景扫描、照片重建、稠密重建结果的表达方式。常见的来源包括手机扫描、开放场景照片集、无人机影像重建等。它不像传统网格那样有干净的拓扑结构和 UV但视觉上往往更接近真实拍摄效果尤其适合树木、墙面细节、复杂边缘和不规则物体。1.2 “原生支持”意味着什么在 Three.js 里说“原生支持”通俗地讲就是把以前需要额外引分支、改渲染管线、或者自己处理排序逻辑的工作收进了官方示例和加载器范围。你在一个相对较新的 Three.js 版本里可以加载高斯溅射格式的数据把它作为场景对象加入再走普通的相机控制、渲染循环、场景切换逻辑。这里要先泼一盆冷水原生支持不等于“所有版本都能直接用”也不等于“任意格式都能一键导入”。如果你打开官网示例发现需要额外依赖或者本地项目引入后报导出问题先别怀疑 Three.js 不行大概率是版本路径和 import 方式没有对齐。另一个常见误区是把高斯溅射当成“真实三维模型”来使用。它看起来像实景但它不是普通网格不能直接做布尔运算不能方便地编辑顶点也不能在所有浏览器和所有显卡上以同样效率运行。原生加载解决了渲染管线接入问题没有解决“后处理变网格”这种建模问题。2. 环境准备与第一个 Gaussian Splatting Demo 跑通2.1 先看运行条件浏览器、构建工具和基础依赖要把 Three.js 高斯溅射跑起来不需要特别夸张的硬件但要注意任务类型。纯查看单个模型普通开发机基本够用如果要做多模型、高分辨率大场景或者接入 Cesium 这类大场景引擎就要优先看显存、内存和标签页本身能占用的资源。我建议目前的本地运行环境按这个标准准备操作系统Windows、macOS、Linux 都可以主要靠浏览器跑 WebGL。浏览器优先 Chrome、Edge 和 Firefox 的较新版本不要用老版本内核。构建工具Vite 是最省心的选择也可以直接用 npm 或 pnpm 管理依赖。Three.js使用较新的版本至少要能通过three/addons/或等效方式引用官方示例模块。显卡有独立显卡会舒服很多。核显也能加载小模型但帧率、内存和交互流畅度会差不少。2.2 初始化项目并加载第一个高斯溅射模型第一步是初始化项目。我建议新建一个干净目录用 Vite 快速起一个基础工程npm create vitelatest splat-demo -- --template vanilla cd splat-demo npm install npm install three工程装好之后把入口文件里的示例内容清掉改成三件事创建场景、相机和渲染器创建轨道控制器加载高斯溅射模型并加入场景。加载方式在较新的 Three.js 中会以官方 addon 的形式提供。如果当前版本的官方示例里已经有高斯溅射相关加载器那么代码结构大致是import * as THREE from three; import { OrbitControls } from three/addons/controls/OrbitControls.js; import { SPLATLoader } from three/addons/loaders/SPLATLoader.js; const scene new THREE.Scene(); const camera new THREE.PerspectiveCamera(60, innerWidth / innerHeight, 0.1, 1000); const renderer new THREE.WebGLRenderer({ antialias: true }); renderer.setSize(innerWidth, innerHeight); document.body.appendChild(renderer.domElement); const controls new OrbitControls(camera, renderer.domElement); camera.position.set(0, 1, 3); const loader new SPLATLoader(); loader.load(path/to/your/model.splat, (splatMesh) { scene.add(splatMesh); }); function animate() { requestAnimationFrame(animate); controls.update(); renderer.render(scene, camera); } animate();这里要注意不同版本的 Three.js 可能在导入路径和对象类型上有差异。有的版本可能把高斯溅射加载器放在three/addons/loaders/下有的版本会用three/examples/jsm/路径。如果 import 报错第一件事是去当前安装版本的源码里确认目录结构而不是硬着头皮猜路径。3. 单模型跑通之后怎么验证效果和性能3.1 判断是否加载成功的标准新手最容易在这里卡住页面没报错但画面全黑或空白。这时可以先看控制台有没有SPLATLoader相关的网络请求再在加载回调里打印对象信息loader.load(model.splat, (splatMesh) { console.log(loaded splat:, splatMesh); console.log(point count:, splatMesh.geometry.attributes.position.count); scene.add(splatMesh); });如果控制台打印出来的对象存在且 count 大于 0说明数据已经进入 GPU 流程。剩下的问题通常发生在相机位置、场景背景颜色、灯光或者渲染顺序上。高斯溅射不依赖灯光所以不用给场景加环境光、平行光这些加了也不影响最终显示。从交互验证的角度看还可以做几个简单操作旋转相机看物体边缘是否出现明显分层或闪烁。缩放相机看近处细节和整体轮廓变化。连续旋转几分钟看帧率是否突然下降、是否出现页面卡死。打开浏览器任务管理器看显存或内存占用是否持续上升。这些验证看起来简单但很能说明模型本身是否完整、压缩参数是否合理、当前显卡是否兼容。3.2 理解 Level of Detail 和资源占用边界高斯溅射模型和传统模型不一样它没有一个“多边形数量”可以直接调。渲染开销主要取决于高斯点总数、当前相机视角下可见点数以及屏幕上的光栅化范围。同一个模型拉远看可能很流畅拉近看却明显变慢这是正常现象。如果你只是本地看一个模型可以直接观察加载耗时和交互帧率如果要在页面上批量展示多个模型就要把“单个模型点数”和“同时可见模型数量”控制好。举个例子几十万个点的模型单看还好十几个模型同时放入场景可能直接卡到个位数帧率。要让画面稳就得做视距裁剪、动态隐藏、按热点切换而不是把所有模型一股脑塞进场景。建议把第一次测试拆成三步。第一步只加载一个模型确认能转、能缩放、能看细节第二步加入第二个模型观察双模型共存第三步才去考虑多模型切换和性能优化。不要一上来就追求“所有模型同时显示”。4. 从单模型到多模型再到 Cesium 集成4.1 多模型共存时的命名、销毁和切换实际项目里基本不会只放一个高斯溅射模型。比如你要做一个城市级别预览一个建筑一个坑洞一个地面如果全都同时加载内存会非常紧张。更稳妥的做法是把模型按地理坐标或逻辑区域分组。用懒加载方式等热点区域进入视野再加载。不需要显示的模型直接从场景移除并调用对象资源的 dispose 方法。在 Three.js 里单纯scene.remove()往往不够因为 GPU 侧的资源仍然可能占用内存。高斯溅射模型本质上还是带 BufferGeometry 的对象所以需要把 geometry、材质等显式释放。这里没有特别神奇的 API核心就是不要在切换时只改可见性。如果你的场景里有大量动态点、大量点云或频繁加载新模型建议单独封装一个SplatManager类把加载、缓存、显示、卸载统一管起来。这样可以避免同一个模型被重复加载也能减少切换时临时对象的构建和 GC 压力。4.2 和 Cesium 共享 GL 上下文的思路搜索热词里有一个很常见的组合cesium three.js 共享 gl 上下文。这里先给结论Cesium 和 Three.js 是两套渲染引擎不能直接把两个引擎的WebGLRenderer同时叠在一个 canvas 上互相穿透。常见的做法是共享同一个 WebGL 上下文让两个引擎分别渲染到不同的 canvas 或不同渲染通道再叠加合成。具体到高斯溅射如果你已经有一个 Cesium 数字地球应用想把某个实景区域的高斯溅射模型叠加到地球上建议先设计清楚坐标系和投影关系。高斯溅射模型的内部坐标系通常来自重建软件可能是局部坐标也可能是地理坐标。如果它不在标准地理参考系里就必须先做坐标转换否则模型会被摆在完全错位的位置。在这些场景里真正影响稳定性的不是“能不能画出高斯模型”而是两个引擎的上下文是否冲突、后处理顺序是否互斥、鼠标事件是否被覆盖。我的建议是先分开跑通单独页面跑 Cesium单独页面跑 Three.js 高斯模型二者都稳定后再做上下文共享和坐标对齐。不要一上来就直接改一个集成项目否则问题会混在一起很难定位。5. 常见问题排查先看现象再看输入再查环境5.1 黑屏、白屏、空白页的排查顺序很多报错都不是模型损坏而是使用环境没对齐。遇到问题我一般按这个顺序排查看控制台是否有404、module not found、import error之类的明确报错。确认模型文件路径正确文件名后缀和实际数据格式一致。确认加载器类型和模型格式匹配不要把.ply当.splat加载。确认浏览器支持当前 WebGL 特性webglreport这种检测工具可以辅助排查。最后才检查代码逻辑比如相机位置、场景背景、对象是否已经加入 scene。如果页面完全空白优先怀疑renderer.domElement没被添加到文档里或者 canvas 尺寸为 0。这个问题在模板工程里很常见刚开始造一个容器时没给宽度高度setSize之后仍然看不到画面。5.2 帧率低、卡顿、内存暴涨怎么查高斯溅射模型的内存占用比普通 glTF 更夸张。如果你发现一个模型就吃了几个 GB 显存先不要急着怀疑是 Three.js 的 bug先看模型本身点数。5.3 崩溃、溢出的保护策略如果加载模型后浏览器直接崩溃常见原因是点数过多或者多个模型同时加载。遇到崩溃我会先把“模型点数”和“显存占用”记录下来。然后按优先级降级减少同时加载的模型数量、降低视野内可见点数、改用更小的压缩模型、或者对模型进行裁剪重建。如果降低之后还崩溃就换一台显存更大的机器查看。开发阶段不要为了视觉丰富度把所有高精度模型一次全加载可以先用一个缩略预览点击后再加载完整版。这里再单独说一下报错处理。很多人看到WebGL context lost或context was lost就慌其实这类错误不一定代表代码写错。可能是因为多引擎共享上下文时初始化顺序冲突也可能是因为显存占用太高导致浏览器主动释放上下文。排查顺序通常是确认是否只有一个 WebGL 上下文多个上下文互相切换时要从底层排队。确认 GPU 进程是否被浏览器杀掉在任务管理器里看 GPU 进程状态。降低输入数据规模重新创建 context而不是直接刷新页面。如果一直出现 context lost不要继续堆模型先检查硬件加速、显卡驱动、浏览器版本和显存占用这几项才是真正的“事故现场”。5.4 文件名、格式和加载路径组合避坑高斯溅射数据不是只有一种格式。主流的格式包括splat、ply、ksplat、spz等。每种格式的解析逻辑不同加载器也不会自动兼容。你可以先用转换脚本或官方工具处理成当前 Three.js 加载器支持的格式再加载到场景里。如果转换后的模型出现颜色异常、位置漂移或整体偏黑要优先考虑生成工具的参数而不是去 Three.js 里调色。一条通用建议先把文件名统一成小写无空格、无中文路径放在public或静态资源目录下通过相对路径引用。任何奇怪的加载失败先怀疑路径、权限和后缀问题再怀疑加载器本身。6. 落地场景和边界什么需求适合用高斯溅射6.1 适合的场景如果你有实景扫描数据、摄影测量重建结果、或者开放的实景数据集想在网页里做沉浸式预览Gaussian Splatting 已经是一个很自然的选择。Three.js 原生支持之后至少减少了渲染器层面的障碍你不需要再去写自定义着色器或者引入非官方维护的大型渲染库。具体适合的场景可以这样理解数字城市和地理信息预览配合 Cesium、Mapbox 或现有地理底座把局部实景区域以高斯溅射形式叠加展示。静态物体展示文博、汽车、装修、室内设计类的在线预览效果比普通照片全景更接近真实尺度。巡检和存档对现场环境进行拍照重建把结果挂到 Web 端方便多人远程查看。快速三维汇报不需要精确测绘只需要“看起来真实”的现场情况时高斯溅射的生成和后端处理链路很省事。6.2 不建议的场景如果是频繁修改模型轮廓、要做切割、室内外精细编辑或者需要在浏览器端做复杂物理交互高斯溅射就不是最优解。它更适合“看”和“展示”不适合“建模”和“编辑”。如果你的核心需求是尺寸量测、拓扑修改、精确遮挡计算还是得先转回传统网格或者点云再做后续处理。我这里不是劝退而是提醒一句性能边界和功能边界要分开看。加载快、显示真、效果好是优势但这些都建立在数据来源可靠、点数合理、目标设备可用、渲染流程稳定的前提下。低估这些前提很容易在项目中期卡在性能优化和兼容性修补上。7. 最后留几个排查和落地建议如果你现在正准备把 Three.js 高斯溅射引入项目我建议把下面这几条刻在项目计划里先做最小可行性测试用一个点数在几十万以内的模型走通加载、旋转、缩放、卸载全流程确认目标设备的帧率和内存可接受。把数据流程和渲染流程分开线上预览尽量走预转换格式不要在浏览器端临时做高开销解析。统一资源管理模型地址、版本、坐标系、清晰度、可见范围都要登记清楚否则多模型项目后期很难维护。日志和异常要提前埋点加载成功、加载失败、点数、耗时、内存水位、context lost这些信息在优化阶段最关键。不要把性能优化放在功能完成之后因为高斯溅射的渲染开销是非线性的等到页面卡死再加裁剪和卸载改造成本会很高。另一个值得提前想的问题是数据合规和来源。项目里用于展示的三维扫描数据、图片重建数据最好都有明确授权避免在测试阶段使用来源不明的大体积数据。尤其在企业项目里数据体积大、路径长、格式乱一旦进到生产环境修复成本非常高。如果只是想学习不涉及太多业务默认加载一个示例模型就能把原理和流程摸清。如果是要长期使用就要把任务队列、资源释放、日志监控和坐标系管理都考虑进去。我在实测后的总体感受是Three.js 原生支持让高斯溅射的 Web 端落地门槛一下子降了很多但能不能在真实项目里稳定运行仍然要看你对数据尺度、加载策略和目标设备的掌控情况。先跑通单个再谈批量先观察资源再开高并发。这是所有 Web 3D 高性能方案通用的稳妥路线。