Unity中depth pass的优化以及谈谈unity中的Framebuffer

这个问题的来源是我发现在unity在移动平台上为了得到深度图,通常需要一个单独的pass,例如我们用到的一些后处理特效需要用刀场景深度信息,我们通过把camera的flag设置为depth tex 打开,unity就会在每帧用一个单独的pass绘制深度图,这其实很浪费,我们队全场景的顶点提交了两次,增加了大量drawcall。为了说明解决这个问题的思路,我们从framebuffer说起。

0. 关于framebuffer

我们知道把场景渲染出来的过程,最终就是把图像绘制到一个FrameBuffer上的过程,现代gpu支持多个framebuffer,显示器屏幕的framebuffer是默认的fbo,当然除了显示器屏幕我们还可以渲染到其他自己定义的fbo来实现渲染到贴图等等。在unity中可以放置多个多个摄像机,这些摄像机在不同情况下渲染的目的fbo也是不一样的。

我们需要知道一个fbo包括很多位面,通常至少包括两个color buffer(前和后双缓存用来绘制和展示),一个depth buffer

我们可以在不同的framebuffer之间拷贝(gpu上的互拷),包括渲染拷贝color或depth,至于gpu到cpu的拷贝我们可以把framebuffer拷贝回cpu内存,但是只限于color位面(截屏),很多底层不支持depth的cpu回拷

默认被激活的fbo就是屏幕的那个fbo,当然也可以切换激活到自定义的fbo来实现向自定义fbo的绘制。

默认的屏幕那个fbo里面的buffer不能被更改,例如gles中它不有gles提供,二是由egl提供,但是自定义的fbo就可以更改里面的buffer

1. unity的camera的fbo的定向规则:

① 对于一个单个最简单的摄像机,它的渲染的fbo就直接是屏幕的fbo

② 对于多个简单摄像机,也是按照摄像机顺序先后流到屏幕fbo

③ 对于带有屏幕后处理特效的单个摄像机,渲染先流到一个自定义fbo,然后一层层的经过后处理,每层后处理都流向一个新的自定义fbo,直到最后一层后处理自动留到屏幕fbo,

④ 对个多个带有屏幕后处理特效的摄像机,按照摄像机的顺序逐个渲染,对于第一个摄像机,先渲染到一个自定义fbo,然后一层层的经过后处理,每层后处理都流向一个新的自定义fbo,对于后面的摄像机,显然渲染到上一个的摄像机的最后后处理出来的那个自定义fbo,也一层层后处理下去,直到最后一个摄像机的最后一层后处理,会流向屏幕fbo

2. 改变摄像机的fbo流向

有很多方法和很多理由需要改变摄像机的fbo,例如渲染到rendertexture,例如我们最开始的那个问题

① 直接创建一个rendertarget,然后赋给摄像机的target,这样这个摄像机(包括加过后处理特效)的最终流向就到了这个rendertexture,因为本质上rendertexture就是一个自定义的fbo

② 通过camera.settarget(color,depth).,可以分别设置color和depth的buffer,这在底层其实是新建了一个fbo,然后把它激活,但是你不能把color定向到屏幕,而depth定向到别处,因为color和depth的buffer必须待在一个fbo上,而屏幕的fbo中的buffer又不能被更改。

对于被设置了settarget而重定向了buffer的camera的渲染的流向规则比较奇特是这样的:

① 如果没有屏幕特效,它直接渲染到自定义的fbo上,屏幕上不可见

② 如果有屏幕特效,它直接渲染到自定义的fbo上,然后一层层的后处理,知道最后一层后处理直接流向屏幕,可以说在这种情况下和我们的预期有些不符,因为这种情况下我们的自定义的rt上没有屏幕特效,而屏幕上出现了

③如果有多个摄像机,每个都被定向到自定义的fbo,每个都有后处理特效,那么第一个摄像机先渲染到定向的那个fbo,然后每层特效后渲染到一个新的自定义的fbo,如果不是最后一个摄像机,最后一层特效将重新流向定向的那个fbo,而对于最后一个摄像机,最终流向屏幕fbo。也就是这种情况下定向的fbo少了最后一个摄像机的特效,而屏幕出现了完整的结果

3. 如何从屏幕获取depth tex?

回到这个问题。我们自然的会想到为什么unity不直接使用上一帧刚刚在屏幕上绘制好的那个framebuffer中的depth?答案肯定是完全可以,unity没有这样做可能是出于为了得到一个它可控的深度图,例如如果我们在渲染场景时自定义了一些z的操作,那么这个z的深度图可能不准,但是事实上对于不透明物体我们几乎不会干这种事。于是我打算从屏幕直接获取刚刚写过的那个depth,而强制unity不用这个浪费的单独的depth pass。

如何做到?最简单的是直接利用fbo的互拷贝的从屏幕的fbo拷贝过来到一个自定义的fbo,然而使用blit这种操作并不能稳定的获取屏幕的z,查阅一些资料也有说从屏幕fbo拷贝z在很多设备并不稳定。那么我反过来实现,我自定义两个buffer,一个color,一个depth,然后把unity的camera的渲染定向到自己的这两个buffer(为什么不只重定向depth?前面说到color和depth不能一个出于屏幕,一个出于自定义)。这样每帧绘制完透明物体后,我把depth的buffer拷贝出来就得到屏幕的z,可以给程序其他地方用了,当然最后当绘制完毕还要把color blit给屏幕,这样屏幕才看得见图像。这种做法相比多了一个从把color从自定义buffer blit到屏幕的操作,但是显然相比重新来一遍深度pass性能要高很多。

当然这里有个坑,那就是如果你的摄像机上有后处理特效,那么就不要自己最后blit color回去了,至于为什么可以参考上面2.2和2.3的规则

版权声明:本文为CSDN博主「leonwei」的原创文章,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/leonwei/article/details/73927878

你可能感兴趣的:(Unity中depth pass的优化以及谈谈unity中的Framebuffer)