浏览器跑 UE5 + 高斯泼溅实测
来源：UEPlus（UIPower）官方实测报告 · UEPlus 官网 原文链接：https://it.sohu.com/a/1087246943_120514817
结论先行
厂商 UIPower（产品 UEPlus for HTML5）发布了一份实测报告，验证 UE5 + 高斯泼溅（3DGS）场景能否在浏览器里跑起来、且不依赖服务端的 GPU 渲染：
- 技术链路：UE5 项目 + Cesium for Unreal + LCC4Unreal（XGRIDS 的 3DGS SDK）+ 高斯泼溅场景 → UEPlus for HTML5 打包 → WebAssembly 编译 → Web 静态资源部署 → 浏览器加载并本地渲染；
- 实测结果：通过 UE5 自带的
Stat FPS观察，帧率可达 60fps 左右； - 同时验证：场景加载、Cesium 三维地形与建筑显示、高斯泼溅实景内容显示、人物漫游（自动/手动）与键鼠交互；
- 成本对比：与 Pixel Streaming（服务端渲染 + 视频流）相比，本地渲染无需常驻 GPU 服务器，交互不经过网络往返。
但必须把前提说清楚：这是厂商自测，报告没有给出硬件配置、场景规模、渲染分辨率、内存占用中的任何一项，测试时间是 2026 年 3 月（发布在 10 月）。所以"60fps"这个数字本身的可参考性有限——真正值得采信的是"这条路能跑通"这个定性结论，而不是那个具体帧率。
来源说明
本文的一手来源是 UEPlus 官方实测报告（发布于搜狐号，2026-10-13），补充来源是 UEPlus 官网的产品技术说明。
这是一份厂商内容，不是独立第三方测试。 发布主体是产品方自己，测试对象是自家产品，文中没有出现任何第三方见证或可复现的测试脚本。报告本身在结尾也承认了这一点："一次实测并不代表所有项目都能获得完全相同的运行效果，实际表现仍与场景规模、资源复杂度、终端设备及浏览器环境等因素有关。"
本文的写法：把它的技术链路和成本结构当作有价值的信息来拆解，把它的性能数字当作"未附条件的厂商口径"来标注，并在最后说明这些结论能外推到什么程度。
要点解读
1. 测试是怎么做的
报告给出的技术链路很清晰，值得逐段看：
| 环节 | 内容 |
|---|---|
| 基础引擎 | UE5 |
| 三维地球 | Cesium for Unreal |
| 高斯泼溅接入 | LCC4Unreal（域创新 XGRIDS 出品的 3DGS SDK），用于把高斯泼溅场景接入 UE5 项目 |
| Web 打包 | UEPlus for HTML5 |
| 编译产物 | WebAssembly |
| 部署方式 | 打包产物作为 Web 静态资源部署，服务器不承担 UE 场景的实时渲染 |
| 访问方式 | 浏览器访问本地 HTTP 服务（报告中为 http://127.0.0.1:5501/ZhiHuiJingQu5_3.html） |
流程本身没有门槛：在 UE5 编辑器里打开已接入 Cesium 与高斯泼溅的项目 → 确认打包环境与插件配置 → 点击 HTML5 打包 → 观察日志（资源打包 → 触发 WebAssembly 编译）→ 得到 Web 运行产物 → 部署到 HTTP 服务。
注意访问地址是 127.0.0.1——这是本机本地服务，不是公网部署。它说明测试验证的是"浏览器能不能跑起来"，没有验证"公网环境下的首次加载体验"，而后者恰恰是这类方案最容易被诟病的地方（产物体积与首屏等待）。
2. 两条路线的真正分野：渲染在哪一端
这份报告最有价值的部分，是把两条路线的差异讲清楚了。核心不是"浏览器能不能打开"，而是三维场景究竟在哪一端完成渲染。
| 维度 | UEPlus for HTML5（本地渲染） | Pixel Streaming（服务端渲染 + 视频流） |
|---|---|---|
| 渲染位置 | 用户设备（WebAssembly 本地运行） | 服务端 GPU |
| 服务器职责 | 只分发页面、程序与场景资源 | 实时渲染 + 视频编码 + 持续推流 |
| 成本结构 | 无常驻 GPU 服务器成本 | GPU 服务器 + 编码 + 带宽，随并发同步扩张 |
| 交互延迟 | 操作直接作用于本地场景，不经过网络往返 | 上行操作 → 服务端渲染 → 视频回传，受网络影响明显 |
| 终端要求 | 高（依赖用户设备性能与浏览器能力） | 低（只要能解码视频流） |
| 资产安全 | 资产会下发到客户端 | 三维资产留在服务端，不外泄 |
"成本随并发同步扩张"这句话，是做交付的人最该注意的一句。 云渲染的成本结构是线性跟随用户数的——上线时只有几个人用，成本很低；一旦推广开、并发上来，GPU 服务器与带宽账单是同步往上走的。而本地渲染把这个变量从服务器侧移到了用户侧：服务器只发静态资源，用户越多，边际成本越低。
代价也很明确：终端性能变成了硬门槛，资产会下发到客户端（涉密项目要慎重），首次加载体积是体验瓶颈。报告在 FAQ 里也承认了这个权衡，并建议"终端性能受限、三维资产保护要求较高或需要集中云端渲染的项目，可以进一步考虑 Pixel Streaming"。
3. 实测数据：只有一个数字
报告给出的量化结果，全文只有一处：帧率约 60fps。
而缺失的信息清单比给出的长得多：
| 项目 | 是否给出 |
|---|---|
| 帧率 | ✅ 约 60fps（UE5 Stat FPS 观察） |
| CPU / GPU 型号 | ❌ 未提 |
| 内存容量 | ❌ 未提 |
| 渲染分辨率 / 窗口尺寸 | ❌ 未提 |
| 场景规模（地形范围、建筑数量） | ❌ 未提 |
| 高斯泼溅数量（splat 数） | ❌ 未提 |
| 产物体积 / 首次加载耗时 | ❌ 未提（只有本地 127.0.0.1 访问） |
| 浏览器名称与版本 | ❌ 未提 |
"约 60fps"这个表述本身也偏宽泛：它既没有说明是稳定帧率还是峰值，也没有说明是空场景还是满载场景下测得。而且用的是 UE5 自带的 Stat FPS（引擎内部统计），不是浏览器端的帧时间测量——两者在"掉帧"与"卡顿"上的结论可能不同。
一个时间差也值得注意：测试时间是 2026 年 3 月，报告发布在 10 月 13 日，中间隔了七个月。这七个月里浏览器与 UE 版本都迭代过，测试环境是否等于当前环境，报告没有说明。
另有一处编辑层面的问题：报告第六节的标题是"高斯泼溅适合什么、不适合什么？"，但正文只写了一句话，内容全部在讲不适合的场景（"需要精确尺寸测量、几何计算、空间分析或模型结构编辑的场景，则需要结合其他三维技术实现"）——"适合什么"那一半没有写。这类标题与内容对不上的情况，通常说明该文是营销导向的快速产出，读者对它的严谨度应有预期。
4. 官网还宣称了什么（作为背景，非实测）
官网的产品技术说明比这篇报告激进得多，列出的能力清单如下（均为厂商宣称，无第三方验证，也未包含在本次实测中）：
| 宣称能力 | 厂商表述要点 |
|---|---|
| 引擎特性 | 全特性支持 Nanite 虚拟几何体、Lumen 全局光照与反射 |
| 三维 GIS | 完整适配 Cesium for Unreal，支持海量 3DTiles 与 WGS84 数据流送 |
| 渲染后端 | 支持 WebGPU，后端采用 Vulkan 语义做指令映射 |
| 着色器 | 自研 HLSL → WGSL 交叉编译管线，基于 AST 解析与代码重构 |
| 内存 | 采用 WebAssembly Memory64，宣称支持 128GB 及以上内存 |
| 多线程 | 基于 SharedArrayBuffer 与 Atomics 重写线程同步原语 |
| 资产轻量化 | 包体压缩至原来的 1/3 乃至 1/5 |
| 倾斜摄影 | 支持 OSGB 格式倾斜摄影模型 |
| 高斯泼溅 | 支持大规模 3DGS，含流式加载与轻量化压缩 |
| 信创适配 | 飞腾、鲲鹏、海光、兆芯、龙芯；银河麒麟、统信 UOS；景嘉微、凌久微、摩尔线程等国产 GPU |
| 工具链 | 深度定制 LLVM/Clang，新增面向 WebAssembly 的优化 Pass |
这张清单里，与本站主题关系最直接的是"支持 WebGPU、后端采用 Vulkan"这一条。 如果属实，它意味着 WebGPU 已经在工业级引擎的 Web 化路径上被实际采用——但需要指出：本次实测报告通篇没有说明使用了哪个渲染后端（是 WebGL 还是 WebGPU），也没有说明 Memory64 是否在本次测试中生效。官网的能力清单与实测报告之间，是两套不同性质的材料，不能混着读。
5. 关于"突破 4G 内存限制"
报告 FAQ 里提到该方案"已突破浏览器 4G 内存限制"，官网进一步给出"Memory64，支持 128GB"。
这里需要读者自己多走一步：WebAssembly 的 32 位内存模型确实存在单实例约 4GB 的上限，突破它需要 Memory64 提案的支持。但厂商没有说明这一能力面向哪些浏览器、哪个版本，本次实测也没有给出实际内存占用量。
结论是：这个说法目前只能当作"厂商宣称"，要用这条路线的人，应当先自行确认目标浏览器对 Memory64 的支持情况，而不是把 128GB 当成既定前提。这项核实本文未能取得权威公开结论，故不代为判断。
6. 报告列出的应用场景
报告认为这套组合适用于五类项目：数字孪生与园区可视化、实景三维与城市空间展示、文旅与景区数字化、虚拟展馆与数字资产展示、虚拟仿真。其中"虚拟展馆"这一类被特别点出——已采集完成的实景空间可以直接用高斯泼溅展示，再用浏览器访问降低进入门槛。
本站判断
第一，最可靠的信号不是 60fps，而是"这条路不止一家在走"。 站内此前写过 SimplyStream——用 WebGPU 把虚幻引擎项目编译进浏览器标签页，同样是本地渲染、同样在算"省掉多少云渲染账单"。两家互不相关的产品选择了同一条技术方向，比任何单次实测都更能说明问题："把 UE 编译到浏览器本地跑"已经是一个真实存在的产品类别，不再只是概念验证。
第二，60fps 这个数字要拆开看。 它缺少硬件、场景规模、分辨率三项前提，不具备跨项目外推的能力。但它旁边那几项定性验证——场景能加载、Cesium 地形能显示、3DGS 实景能显示、人物能漫游、键鼠能交互——反而更有参考价值。因为对一个要交付的项目来说，"能不能用"的优先级高于"跑得多快"；而这几项恰恰是"能不能用"的门槛。
第三，对做交付的人，真正该拿走的是成本结构的差异，不是帧率。 云渲染的成本随并发线性增长，本地渲染把这块成本换成了"终端性能 + 首次加载体积"。这个换算在什么规模下划算，取决于项目的用户数曲线和终端分布——一个人浏览的园区展示，本地渲染明显更省；面向大量低配终端的公众项目，云渲染反而更稳。报告给了对比框架，但没给换算的边界条件，这部分要自己算。
第四，本地渲染不是无条件的胜利，有三个硬约束。 ① 资产安全：场景资源会下发到客户端，涉密或资产价值高的项目要慎重；② 终端门槛：用户设备性能直接决定体验，这一点在政企项目里往往比想象中更棘手；③ 首屏体积：报告测的是 127.0.0.1 本地服务，完全绕开了网络传输这一环，而真实项目的首屏等待几乎全在这一环上。
第五，读这类材料的方法论。 厂商实测的价值在"证明可行"，不在"给出性能"。把它的结论当方向确认，把它的数字当待验证的线索——这是唯一安全的读法。这份报告连测试硬件都没写，任何把它当作选型依据的做法都缺少基础。真要做决策，正确做法是拿自己的场景、自己的目标终端，让厂商配环境跑一遍，并索要硬件与场景规模明细。
第六，对站内 WebGPU 内容线的一个提醒。 官网宣称支持 WebGPU 并把后端映射到 Vulkan 语义，还自研了 HLSL → WGSL 交叉编译——如果属实，这是"WebGPU 承载工业级引擎"的一个少见样本，比游戏和演示更有产业意义。但它没有被写进这份实测报告，所以本文只把它作为背景列出，不作为结论。值得后续跟进。
参考来源
- UEPlus 官方实测报告《浏览器能流畅跑UE5+高斯泼溅场景吗？实测分析报告》（2026-10-13）：https://it.sohu.com/a/1087246943_120514817
- UEPlus for HTML5 官网产品技术说明（厂商宣称，本文第 4 节表格来源）：https://www.ue5plus.com/
- 相关产品：LCC4Unreal（域创新 XGRIDS 的 3DGS SDK，用于将高斯泼溅场景接入 UE5）
- 站内对照：SimplyStream 把虚幻引擎编译进浏览器标签页（同为"UE + 浏览器本地渲染"路线的另一个产品）
- 背景知识：高斯泼溅（3D Gaussian Splatting）由 Kerbl 等人发表于 SIGGRAPH 2023，通过大量三维高斯基元表达场景，经高斯光栅化实现新视角实时渲染
