3D高斯的失败

内容纲要

最近一两年,如果读者关注图形学方向,除去越来越多的AI for Rendering、虚拟人,大概会看到不少关于3D高斯的论文(3D Gaussian Splatting)。NeRF还未兴旺,3D高斯就将其全面超越了,并成为了新的发论文热点。3D高斯,在新视角合成任务上表现确实惊艳,根据RGB图像重建出的场景的新视角推理也相当有真实感,咋一看,似乎和现实几乎难解难分。

或许,不少人自然而然就有了个想法:既然3DGS这么快,如果在游戏引擎、传统的3D应用内加上3D高斯,那不是直接干爆蒙特卡洛,弯道超车,立地升天了?

当然不。

本文吐槽内容居多,比较偏激,充斥着个人研究失败的怨念和调动情绪暗示与叙事方式,但这也不代表3D高斯本身一点问题没有,不吐不快。

前言

已经许久没有写过新的博客了。时光如梭,2025转瞬及去。2024年年末,笔者的上一个研究(在RTGI管线的光探针上加入球面高斯基,与球谐基一同辅助着色)进展迟缓,实验做了一批又一批,最终渲染质量的提升却微乎其微。伴随着3D高斯爆火和对上一个研究愈发浓烈的失望感,笔者也在导师指点下,一头扎进3D高斯的大潮中。我们的思路很简单。首先,3D高斯很火,很新,很简单,很好发论文。其次,全局光照(或者,实时全局光照)虽然难做难发,但目前并未被引入或很少被引入3D高斯研究,而这正是我们所擅长的传统方向。那么,一个1+1=2的范式就呼之欲出了:做3D高斯的实时全局光照明。

尽管工程难度很高,但毕竟是1+1=2,所以免去了大量探索类工作。笔者花了三个多月的时间写了代码并在导师指导下完成了论文,投稿SIGGRAPH,然后因Novelty原因被拒,随后25年年中小改后继续投稿TVCG,最近才刚刚被接受。在此期间,笔者尝试继续推进3D高斯与实时全局光照的下一研究,投入了大量时间,但遇到了越来越多的困难。8月份时,笔者已经隐约感觉到事情不对,但并未深入思考,转而为了解决这些困难,又投入了更多的时间和精力。然而,新的问题一个接一个冒出来,似乎永无止境。

在11月份的性能实验完成后,笔者终于受不了了,并停止了进一步的实验和尝试。在数日的反复思想挣扎后,最终,笔者决定放弃这个研究了恰满一年的方向。

又经过一个多月的反思,笔者的结论是:3D高斯形式并不适合参与光照计算。在光照计算上,3D高斯的数据形式百害而无一利。

幻象与现实

3D高斯确实在实时辐射场渲染任务上出类拔萃,而且容易处效果,其超真实的渲染效果也能为人们带来无限幻想,也让无数研究人员投身其间。这个美好的 幻象 在世界互联网上通过各种演示视频和煽风点火者大胆的宣称愈加庞大和清晰,分毫毕现,似乎触手可及。但若将其捧为下一代图形的终极解决方案,在熟悉全局光照明(Global Illumination)的研究者眼中,是大有问题的。3D高斯的核心思路是把场景表示成一堆带颜色的3D高斯球,然后用软光栅/硬光栅快速喷溅到屏幕上。熟悉NeRF的人会将其称为“体渲染”的上位替代或高效近似,实际上,在传统光照研究中,这个过程称不上也并未发生任何真正的“渲染”——就连NeRF使用的“体渲染”一词都和光照中的“体渲染”意义不一。

首先,"带颜色"一词则代表光照计算的缺失,3D高斯更像使用画笔往画布上涂抹现实中看到的景象,而并没有真正“思考”光线在场景中的传播、散射、进入摄像机镜头的过程。简单而言,高斯体内烘焙了光照信息,类似于光照贴图——仅在静态场景下生效,一旦光照条件发生改变、场景物体发生移动,马上失真。其次,3D高斯的喷溅流程,和传统光照渲染中的渲染是相当失配的——这也暗示着在3D高斯场景中,接轨目前研究成熟的光照体系,使用传统的光传输算法会更加困难。

不过,有问题,自然就会有研究。如何在变动光照条件下渲染3D高斯,或者说,一个更大的问题是,在3D高斯场景里模拟光线传输,其实也是个活跃的研究话题,目前一般称为3D高斯重光照(Relighting)。目前,学术界大概有几条路线:

1.仍然是烘焙。在加入限制的情况下,一部分光照条件的参数空间会变小,或者对最终渲染结果的影响缩减——这导致可以使用激进近似。于是,将部分参数下的复杂光照通过一些经验性近似的光传输模型和点云追踪等某些方法预先算好,运行时直接查表或使用“以一盖全”(使用烘焙好的部分光照代替本来需要实时计算的部分光照)的近似,这就是烘焙路线。这种路线的缺陷是无法应当变动场景条件。

2.把3D高斯光照问题A转化为对称的经典全局光照问题B,通过求解B,得到解之后迁移到A上来求解A。其中最直接的做法是将3D高斯转化成传统三角网格,回到传统光照管线,称之为Proxy(代理问题)路线。这种路线的缺陷是会引入问题/解迁移带来的额外偏差。

3.发掘3D高斯“体”的特质,将3D高斯表示视作散射体的参数化表达形式,然后套入体光传输模型,使用“原生”3D高斯进行体渲染(注意和NeRF的“体渲染”做区分,这里指代的是全局光照的“体渲染”),也就是体点云路线。这种路线的主要缺陷是引入体光传输模型后性能开销太大,因为大幅改变了下层3D高斯对几何的表达模式,研究生态也不完善。这种路线实际离3D高斯喷溅已经很远了,笔者揣度或许只是假借其名号和热度进行投稿。

4.各种机器学习加持的杂糅方案,此类研究探索性较高,并不实用,难以归纳,探索难度也很高,不好参考。

上述多条路线在同一工作中并非只有一种,往往由多种路线交融而成(比如,南大2023年的开山之作Relightable 3D Gaussian内就包含烘焙路线和Proxy路线的内容)。它们是3D高斯与光照结合的先锋探索者与开路人,但也暴露了许多3D高斯的问题:渲染性能差、材质恢复质量不理想、支持光照自由度受限、在非合成场景(真实场景)下表现劣化、3D高斯表示形式带来的Overhead过大。同时,对于3D高斯光照模型的数学描述,各方仍未有一个类似于LTE的定论,往往是公说公有理,婆说婆有里,各自研究自成体系,没有一个权威的理论框架。

这一系列问题,可以寄希望于在后续研究中能被慢慢解决,但也可能成为挥之不去的顽疾。目前的现实是,3D高斯在光照任务中,几乎为网格几何表示的全面劣化版。然而3D高斯光照仍在学界和业界备受关注,其中不乏各路老板乃至投资人。幻象和现实之间,如此巨大的差距,竟然被忽略了吗?观者不知,清者不语,毕竟二者中间还填塞着无数没处发论文、如笔者一般的的硕博生。

性能死穴

3D高斯确实快,但这个"快"是有前提的——在新视角合成领域,它比NeRF快两个数量级,无需质疑。可一旦进入实时渲染的语境,对手变成了传统的G-Buffer光栅化,情况急转直下。

以FlashGS为例,除开较新的TensorGS,它是目前3D高斯光栅渲染的速度SOTA。对于约莫20万个视锥内3D高斯,在1080p分辨率下要花费1.4毫秒进行渲染。听起来不错?但同样数量、大小类似的视锥内的三角面做G-Buffer/Visibility(16 Byte)光栅化,在3090硬件下(相同硬件),时间开销不到0.2毫秒。差距此时来到10倍之多。
更麻烦的是,这还只是比较输出颜色的结果(对于每个像素,FlashGS输出4 Byte大小RGB颜色)。然而,做光照渲染需要的不止颜色,还有粗糙度、金属度、深度等等G-Buffer内的额外信息。考虑到高分辨率3D高斯光栅化(无论是硬光栅流水线还是软光栅)的瓶颈在输出合并(Output Merging)阶段,这是完全的一个额外乘区。因此,每多一张G-Buffer,开销几乎会成倍增长。更糟糕的是,如果需要使用自定义光栅化过程生成更好的G-Buffer来让上文中所述2号策略的Proxy问题迁移更加准确,性能也下降得更为厉害。

那么,如果用硬件光栅化代替软光栅,利用硬件单元的计算能力渲染3D高斯,会不会变得更快呢?会,但也不会。在笔者测试中,硬光栅方案虽然能大幅快于3D高斯原论文实现,却仍与FlashGS有一定距离(慢50%左右)。要命的是,3D高斯绘制场景中天量的Overdraw是硬件所忽略的场景。正如上文所说,输出合并阶段是3D高斯光栅化的瓶颈,G-Buffer增加会导致需要合并的Fragment成倍增加,让本就严重的Overdraw雪上加霜——笔者通过Profiling发现,这会彻底压垮硬件内预留不多的输出合并单元,性能下降速度也是和Fragment数量一样增加的。

这是第一步。真正的全局光照计算(Real Time GI,RTGI)还没上场呢。

首先,3D高斯光栅化可以用很小的、易于高度优化的CUDA核函数/Shader搞定,高度优化的单一核函数能带来良好的性能提升。可一旦开始走向复杂的RTGI,则会涉及到大量Shader和复杂的与下层场景数据(也就是3D高斯)的交互。此时,这些复杂的Shader不仅难以优化,数量还特别大,多达数千行,一个最小化全局光照明管线的Shader甚至能接近万行,此时,进行全面优化的工作量是完全无法接受的。这是工作量上的天堑。

其次,是点云表示与三角网格/体网格表示之间的差距。与3D高斯软光栅中有序、单一、可高度优化的3D高斯访问模式不同。光照之中,对于下层几何数据的访问是大量、多样、非结构化的。横览体网格、三角网格、3D高斯几种下层几何数据形式:在图形卡中,三角网格有着硬件级的访问优化,体网格则因为其稠密性和简单布局能提供O(1)随机访问操作。3D高斯这种点云结构恰巧两不沾——其新兴性和生态欠缺导致目前硬件缺乏对其的优化支持(在可见的未来,似乎也不会有),其稀疏性代表它不能像体网格一样被高效访问。最终,如果使用3D高斯直接作为光照算法的下层结构,就会天然带有巨大的、无法被缓解的访问开销。

最后,是点云表示本身的Overhead:相同数据量下,点云表示通常对有复杂拓扑和穿插的实心三维物体的表示能力弱于网格几何。不过这点我的确不好评价,毕竟点云表示的优化空间较大,而且笔者不是很了解此方面的工作。

笔者于2025年的研究是年初3D高斯实时全局光照明研究的延续。前者更多是Proxy路线,因此无可避免地面对问题迁移时带来的误差。笔者希望能通过使用求解“原生”的3D高斯光照(转向体点云路线)来从根本上根除此问题。然而,笔者低估了3D高斯结构进行光照本身带来的性能负担。它和体渲染模型带来的额外开销相叠加,引入了令人绝望的性能鸿沟。在11月算法主题编码和调试完成、性能测试的结果非常糟糕,仅3D高斯本身带来的时间开销就已经令整套算法失去了所有意义,直接导致笔者最终放弃了这个方向。

更现实的选择

上文中提到过3D高斯重光照目前的几种路线。其中,体点云路线的性能问题挥之不去,生态更是匮乏,实在难以动手。Proxy路线中,一类方法通过将3D高斯映射到代理几何体上,然后用传统方法算光照。这条路至少不会有严重的性能问题,而且可以直接利用现有算法生态。其问题在于,3DGS本身几何质量较差,Proxy难以构建,其材质重建也是个老大难问题(虽然目前已经有相当多研究,但仍然停留在较初级阶段)。最后,将3D高斯的体积表示转化为表面表示,表现力必然有损失。

一条更有趣的路线或许是MR(Mixed Rendering)路线。这条路线的基本假设是:使用Proxy计算光照差值的误差,小于直接使用Proxy计算光照的带来的误差。如此,便可以使用Proxy算出光照在不同光照条件下的差值,再使用某种方式将差值贴回3DGS的渲染结果上。这样就能同时规避开销巨大的3DGS的G-Buffer光栅化与3D高斯光照。关键取舍在于:多算一次光照的开销,要小于增加光栅化G-Buffer的开销。如果此路线基本假设成立,MR路线也可能缓解材质重建不理想的问题。目前此路线上已经有零星研究存在,但效果确实不是非常理想。

3D高斯的失败

写到这里,结论已经很清晰了:3D高斯适合做新视角合成,但不适合做原生光照计算。

3D高斯不适合进行光照的主因是性能问题,其根源在点云数据结构,它在光照任务里相对传统表示形式没有优势,几乎只有劣势。光栅缓慢、访问效率低、表示开销大。不成熟的硬件生态和光照理论体系,加之RTGI本身较高的实验难度,这一切叠加在一起,让3D高斯实时全局光照的研究举步维艰。

如果要做实时3D高斯光照,更务实的选择是:最小化3DGS对管线性能的影响——仅喷溅颜色,而把复杂的光照计算交给传统管线或Proxy表示,并尝试解耦喷溅的颜色和光照的关系,尽量最小化Proxy路线问题和解迁移带来的偏差。MR类似的方式也可能是另一种解决方案。

不过,无论如何,原生3D高斯光照对于实时应用而言都过于昂贵、过于不切实际了。

此条目发表在文章分类目录,贴了, 标签。将固定链接加入收藏夹。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注