浅谈XR渲染

浅谈XR渲染 - 知乎

背景

有段时间没更新了，被派去支持vr项目几个月。之前对于vr挺好奇的，正好有这个机会，也算是对于VR有个初步的认识。我支持的项目pico视频，主要解决接入直播融合本地渲染互动场部分的渲染问题。

PicoVR｜郑钧VR私人唱聊会倒计时2天：舞美公开！科技感在线！_哔哩哔哩_bilibili​www.bilibili.com/video/av299010859/?vd_source=c68972e5e46a1ee3cd8b9b4a5f3996b3​编辑

时间比较短，并且事情特别多，基本都在处理一些琐事，也没太多精力去研究底层渲染。所以，本文很多内容都仅仅是猜测，没有过多验证。考虑到身边不断有游戏行业的人想进入到vr行业，向我询问这边的情况，我这里写一下作为一个移动游戏行业渲染方向从业者怎么进入vr行业，也写一些我个人对于xr渲染的看法。

本文某些观点，可能并不成熟，仅供参考。

VR：Virtual Reality(虚拟现实)，文中提到的VR大部分指代VR头显。
XR：Extended Reality(扩展现实)。包括虚拟现实（VR）、增强现实（AR）和混合现实（MR），文中主要特指VR。

XR渲染原理

以Pico Neo3为例，他的镜片分辨率是1832*1920*2，在使用unity urp，renderscale设置成1的情况下，eyebuffer是1440*1584*2。

unity先在一个1440*1584*2的RT上渲染

这里就正常的渲染，只是对于multipass和multiview有些许不同，后面会讲。在这里，你就理解为左右眼各画一次得到两张分辨率为1584*1440的RT。

这两张RT是不能直接显示在VR上的，因为在VR上，图像要进行畸变，大概是一个往上下左右都鼓出，大概长这样。

从unity的eyebuffer输出的是正常的2D RT，他会做一次类后处理的图像畸变。猜测做法类似density map的做法，把屏幕分成格子，每个格子有各自的uv映射，将2D平面图畸变成VR图像。最终会得到一个1832*1920*2的RT。

这个图像就可以直接在VR镜片上显示了。

MultiPass和SinglePass（MultiView），SinglePassInstanced。

上面的渲染流程，我们能干预的仅仅是渲染到eyebuffer的过程。比较直接的是，跟画CSM的处理方式一样，把左右眼分别处理，用两个不同的pass来渲染，这种方式就是multipass。

这样的话，左右眼就完全无相干了。

按照unity的文档来说，左右眼会分别剔除和计算shadowmap，也就是说完全相当于两个相机了。

其实，双眼相对于场景来说，离得很近，且视口方向一样，是存在一定的相关性的。那么我们是可以，两只眼一起处理，然后使用一个Pass画两个Slice的方式。

相比于multipass，我认为剔除和shadowmap这些处理得好，两边应该是一样的。最主要的是，节省了切换渲染状态的消耗。至于多slice，我之前没有研究过，开始我以为是mrt，研究发现并不是，因为slice和mrt是能共存的，我大概理解为RT是TextureArray。每次提交时，Multiview这个扩展允许GPU驱动程序在纹理数组的N个不同的切片（slice）执行N次绘制调用。它在XR中通过单次绘制调用来在2-deep纹理阵列绘制左眼和右眼。

GL创建TextureArrayRT API

RenderDoc Slice显示

unity还提供一种SinglePassInstanced，现在是preview版本。我的理解是singlepass相当于SRPBatcher(底层API帮我们做)，singlepassInstanced相当于drawInstance，这里的instanceCount总是2。

这几种方式在unity的设置在ProjectSetting里控制

这么看来，MultiPass没有存在的必要。实际以我的经验来看，项目最后上线，肯定都要切换到singlepass。但是有很多vr项目都是从移动项目转过来的，项目初期为了快速出效果，可以先在multipass下，multipass的兼容性比较好。

移动渲染 vsXR渲染

大家比较关心的，从手机平台迁移到XR平台，需要注意什么。

xr平台优势

兼容性

我们做移动平台，特别是Android平台，为了支持所有机型，在兼容性上要做非常多的努力。对于vr平台来说，现有vr设备就那么几款，他们之间几乎没太大区别，且各个平台现在商店是比较封闭的，就我现在遇到的情况来讲，一般项目成立之初就已经有确定的平台。

XR2

现在主流的Oculus Quest2和Pico neo3，都是高通专门为VR研发的XR2的芯片，宣传说相当于865。

且，对于VR设备来讲，电池方面不存在问题，也不存在散热问题。

我刚看到这相当于小米10的渲染能力时，狂喜。

xr平台劣势

基础消耗

unity空场景直接打包，在pico上运行，测试发现gpu的消耗有50%左右，也就是说我们只剩一半的性能用来渲染我们自己的东西。

分辨率

vr对于分辨率的需求极高，在renderscale为1的情况下，frameBuffer：1440*1584*2。在我看来这个分辨率其实还不太够，如果你的项目gpu消耗压力不大，建议renderscale开到1.3~1.5，低于1是完全没法忍受的。并且，msaa必须要打开，不开的话锯齿超级严重，测试下来在renderscale=1，4xMSAA才能有一个比较好的效果。

可能有人会有疑问，为啥镜片的分辨率才1832*1920，我从1440*1584畸变过去不是正好吗？其实不然，畸变过去，大部分地方会出现拉升，如果把frameBuffer的分辨率提高，最终在镜片上显示的效果会好很多。

在移动平台做游戏时，我们一般会缩减分辨率，最多到2K，差一点的就1k，某游戏甚至720P。

帧率

vr对于帧率同样敏感，Oculus和Pico都是72帧，设备还有高帧率模式，以Pico neo3为例，有72帧，90帧，120帧三个档位。从体感来看，72帧在我看来也是勉强够用，且绝对不能掉帧，一旦掉帧，恶心加头痛强烈，因为错过了一帧vr是不会去等待的，他会直接用上一帧的结果矫正也就是说直接掉到36帧。这方面，Oculus要求所有上商店的APP必须满帧。

不满帧时，Unity的Profiler表现

移动上的话，一般30帧就够用了，最多在指定机型能有60帧选项，且偶尔掉帧，也能接受。

上面说的这两点，对于做移动游戏的优化来说屡试不爽，在VR上确是完全不能碰的红线。而且，不仅仅对于渲染本身，跟其相关的所有优化手段都得慎重考虑，比如：TAA，Dither，棋盘格渲染等。

TBDR

xr2的芯片也是tbdr的架构，意味着在移动上遇到的带宽问题，在这如此高分辨率的情况下，更甚。

片上缓存（OnChip Buffer），EarlyZ这些特性都要更加重视。

HDR对性能的影响就更加严重了，建议是不要开。特别是在pico上，掉帧特别严重，Oculus上要好一点，可能是pico的bug，或是Oculus可能做了其他优化（他们的芯片都是xr2）。

Blit操作一定要非常慎重，在开启主RT渲染后，就不要有任何切换RT的操作了。

渲染功能开发

说了那么多，那么实际开发的时候跟手游有啥区别呢？

在用urp的前提下（推荐使用urp），如果不需要自定义Renderfeature的话，就不需要修改任何urp的东西，unity都给你处理好了。在添加renderfeature的时候需要注意，首先，通过renderingData.cameraData.xr.enabled判断是否当前是xr的渲染，因为还需要在编辑器下正常显示。然后后处理换全屏，既不能使用Blit也不能用DrawFullMesh，需要使用DrawProcedural，如：

遇到问题，可以参考urp的写法。

Shader部分，全局变量unity_StereoEyeIndex，左眼是0，右眼是1，但是我们大部分时间好像并不关注，除非根据左右眼有不同显示，比如：显示VR视频流等。

然后，计算ScreenSpace需要注意，好在unity帮我们封装好了很多方法可以直接调用，具体可以参考unity文档。

如果使用SinglePassInstanced，那么还得在vs和ps里声明，跟声明其他Instance变量一样，这里建议都加上，不用的话，unity会通过宏帮我们剔掉。

vs，ps数据声明

Instance变量提取

渲染标准参考

参考前面的pico参数，大概能总结：小米10的一半性能，要渲染1440*1584*2的分辨率，且帧率稳定在72帧以上，能干哪些活。

模型面数

面数对Pico来讲，不是很吃紧，因为vr只是分辨率高，面数的计算跟手机没有太大差别。在piconeo3上，同屏面数到80w，基本还能满帧。但是，该控制还是要控制一下的，因为面数还会引发QuadOverDraw这种。

光照模型

就现在来说，整个行业基本都已经PBR了，经测试，unity内置的Lit，使用简单PBR勉强能支持到。建议项目组，不要无脑使用，需要做一定的优化，比如：压缩通道，禁止Detail等。灯光数量最多一盏，或者直接去掉主光源计算（unity的lit，即使在场景中无主光源也会使用lightcolor为黑色参与计算），只保留lightmapGI，反射天空盒，或者干脆用BakeLit。lightmap使用Dirctional模式也会对性能有明显影响。

阴影

阴影的渲染应该跟手机一样，问题在于采样阴影会有些消耗，大概就是光照模型上再加一张图的消耗，由于项目没有使用阴影，这部分没有深入测试。

HDR

必须关闭，特别是在Pico上，对性能的影响非常大。

MSAA

如果renderscale设置成1的话，4xMSAA是必须的。经过测试，renderscale=1.3，NoMSAA，性能和效果都不如renderscale=1,4xMSAA。2xMSAA在我看来都有点不够用，如果项目性能实在是优化不了了，可以试试。也可以看看其他AA，跟后处理有关的AA基本不用考虑。

后处理

常驻的传统后处理基本可以告别了，多一次后处理，至少得多一次全屏计算。如果不做特殊处理，还会多一次FinalBlit。项目只有在转场的时候，加了一个淡入淡出。

常驻好用的后处理其实也就一个Bloom，这个也是美术比较在意的，对于提升整个画面的氛围感极其重要。这里可以参考VR游戏节奏光剑的做法。

对于一个这样的画面

他会先找出场景中发光的物体，使用主相机将其渲染到一张512x512的RT上，这个材质可以是指数雾和高度雾那样的做法，甚至如果性能够用，用伪的体积雾都可以，毕竟像素比较低，能接受。最终，得到一张这样的RT

然后跟Bloom的做法一样，从512尺寸一级一级DownSample到2x2，再把上面的阶梯贴图，在一级一级UpSample到512*512，将其晕开。

在渲染场景的时候，就可以把这张图当成一张环境图传入shader中，进行采样叠加。

这样就最后得到一个这样的画面

这样做相比传统bloom的好处在于，一是在正常渲染之前做bloom，可以避免切换主屏幕大RT，二是渲染到一个可控的RT上，固定分辨率能让这一步效率大大提升，如果直接拿上一帧颜色图，缩放到512x512的话，采样就会多很多，还得增加一次copy消耗和一个大RT的内存显存消耗。

调试工具

unity的profiler是都可以使用的，所以调试cpu问题，基本直接用unity原生的就够用了。gpu问题的话，在手游经常使用的RenderDoc和Snapdragon Profiler有部分功能不太好使。Pico和Oculus都维护了一份他们自己的Renderdoc，基本够用。

如果想要实时查看GPU占用，Pico还提供一个挺好用的分析工具，

1 统计工具 - 统计工具 0.1 文档​sdk.picovr.com/docs/MetricsTool/cn/chapter_one.html​编辑

这个工具挺好用的，建议人人安装，就后台开着，录屏啥的，也都能录上，出问题可以直接看到画面卡顿时的各项数据。

VR行业看法

行业门槛低

就现在来讲，至少VR上的游戏基本都普遍低端，我这里说的低端不是说游戏类型，就显示效果来讲，一股粗制滥造的味道。游戏行业的TA进入，很容易出效果。但最近启动了不少项目，过不了多久估计也会卷起来。

硬件问题

设备重量问题和眩晕问题比vr设备刚出那会好多了，但是依然存在。一次连续使用的极限，我个人来讲是三十分钟。从这来看，不太适合做太重度的游戏，可能更适合做一些诸如过山车这类的应用。

现在的算力确实不太够，按照我的体验来讲，现有的分辨率其实都不太够，也是因为性能不够不得已的一种妥协。即使按照现在的分辨率，很多效果都没法开，VR本身确实对于性能要求太高。希望在苹果进入后，这方面会有所突破。这方面，我倒不是太悲观，只要有足够的市场，硬件的发展肯定能跟上，并且，VR的功耗和芯片大小问题要比手机小多了。

关于这个问题，有人提出过，那我能不能使用PC串流呢？这个我从下边这个问题阐述为啥不行。

用户基数低

拥有vr设备的人还是太少，跟手机完全比不了，并且可以预期这个也不会多到哪里去。其中大部分买了vr设备的人也放家里吃灰，跟现在的生态不太健全有关，可能应用多了这部分会有所改善。应用场景小，只能在室内，而且某些游戏，还得最好比较开阔的地方，这里点AR就要好一点。这点我认为是VR行业最致命的一点，可以通过补贴缓解，但不是长久之计，羊毛出在羊身上，你还是得找到一个让用户花钱买内容的地方。最终还是转换到内容方面，内容呢，如果受众小，那么就只能出精品提升人均消费。就像，看电影的肯定比看电视的少，那么你制作的电影一定要比电视剧优质。但是，现在用户能买单的价钱范围内提供的硬件，根本不能支持做出精品内容来。

这也就解释了为啥不能用串流了，串流只会指数型暴露这个问题，所以现在的vr厂商，都在着力研发和推广一体机，我个人认为vr的未来是一体机（vr如果能发展起来）。

适合ToB，不适合ToC

现在说这句话可能言之过早，至少目前来讲，ToB的话，上面的这些都能解决。我觉得VR作为一个模拟仿真体验，或者教学类的，甚至当做现在街头已经比较流行的5D电影院这种，是有一定的市场的。但是，现在的资本市场介入，肯定是不满足于ToB的，元宇宙的提出就是冲着ToC去的。