OpenGL ES 2.0是否可以进行延迟渲染/着色？

我在StackOverflow上问了这个问题，但在这里可能更有意义：

是否有人在OpenGL ES 2.0下实现了延迟渲染/着色？它不支持MRT，因此只有一个颜色缓冲区，因此不能以“常规”方式实现。

具体来说，我正在iPad，iPhone4（maaaybe iPhone 3gs）和Android上进行浏览。在iPad / iPhone4 / iPhone3gs上的GLESView应用程序上，存在GL_OES_RGB8_RGBA8扩展名，但我看起来还不是很深入，但是对于8bits /通道，这个想法很有趣：http : //www.gamedev.net/topic/ 562138-opengl-es-20和递延阴影/

还有其他想法吗？在性能方面，这是否值得做？

对的，这是可能的。但是，这并不是特别值得。

首先，除非您有权访问NV_draw_buffers扩展名（顾名思义，它仅适用于NVIDIA。所以，除非您在Tegra上运行，否则就没有它），ES 2.0下的帧缓冲区对象只能渲染到一张图像一次。因此，要生成G缓冲区，您将需要多次渲染场景，从而失去了延迟渲染的优势之一。

其次，移动平台上的带宽与甚至在中端GPU上所获得的带宽都不相同。带宽对于使延迟渲染（对于许多灯光）而言值得一想至关重要。如果没有该带宽，就性能而言，光通过确实会受到伤害。

第三，PowerVR硬件确实不是为这种事情设计的。它使用其基于图块的渲染硬件来优化渲染。因此，与传统的扫描转换体系结构相比，延迟渲染将没有太大帮助。

主要问题是Fillrate。在移动GPU上，填充率较低，无法以原始分辨率实时进行Deferred着色。

在iPhone 4和iPad 1上，填充率简直太荒谬了。唯一具有良好填充率的IOS设备是iPad 2，但我怀疑是否足够……在android上，只有Tegra设备具有GL_NV_draw_buffers才能使用MRT，但填充率也很低。马里400似乎是最好的填充率。如果您想哭，只需尝试以全屏分辨率填充一个彩色矩形4次即可。许多设备无法做到60 fps。

在台式机GPU上，填充率是移动GPU的10倍（或更多）。不要忘记，移动GPU与CPU使用相同的内存，并且您没有专用的内存。

WebGL（相同的API）中有一些示例，因此这不是API的限制。

确实，您必须考虑延迟渲染器所需的绝对最小值。如果您推迟使用延迟照明，它会减少需要存储在GBuffer中的数据量，实际上，它比3次或更长时间渲染一半场景以支持少量照明要便宜得多。

我会选择以下GBuffer格式：

• 重复使用深度缓冲区进行照明遍历，不确定是否在移动设备上支持深度缓冲，但这是自由深度纹理。
• 我将在其中存储一个GBuffer纹理：法线U，法线V，参数0，参数1。Lambert-Azimuthal编码对于法线而言确实不错，并将其压缩为仅两个分量，而且编码和解码也相对便宜。
• 照明变量的两个参数很多，如果硬件能够很好地进行动态分支，则可以将一个参数用作多个照明功能的枚举。

延迟照明与延迟渲染类似，不同之处在于您两次渲染场景：

1. 将几何深度，法线和照明参数渲染到GBuffer中。
2. 将灯光渲染到累积缓冲区中。
3. 使用材质着色器渲染几何体，也可以在此处合成照明。如果您擅长计算照明方程的逆运算符，则可以在此步骤中完成很多非常酷的事情。
4. 进行任何负担得起的后期处理，为确保效率，请务必在此处滥用深度和常规纹理以致死亡。

关于存储照明结果。我已经喜欢存储漫反射的颜色和镜面反射的亮度，因此累积缓冲区仅需要是标准的32位颜色纹理。您可以通过计算漫反射色的色度并将其与镜面反射亮度相结合来估计镜面反射颜色。

但是，最重要的部分是将深度模板缓冲区充分利用，确保不要在不需要的地方渲染任何照明代码。我什至会以某些术语将某些废弃语句添加到片段着色器中，这些术语会将光线可见性降低到设备的可显示范围以下（1e-3通常是安全的界限）。

考虑延迟照明。简而言之，延迟照明是一种使用简化版本的延迟阴影来计算屏幕空间光照贴图的技术。在第二遍中，使用屏幕空间光照贴图作为光照信息再次渲染几何体。

由于需要较少的属性，因此该技术用于减小G缓冲区的大小。它还为您带来了好处，即G缓冲区和屏幕空间光照贴图的分辨率可能低于屏幕。

我实现了一个严格的基于GLES 2.0的渲染器（尽管是实验性渲染器），并且设法将G-Buffer简化为一个RGBA纹理（是的，我使用了Texture2D而不是renderbuffer）。它包含屏幕空间法线贴图+ alpha通道中的深度缓冲区（据我所知，它是使用对数压缩的）。

可以使用以下事实计算位置属性（在此处称为“ 世界”），即在透视投影中，.xy由.z表示，因此：

我通过以下方法估算了位置属性的xy：

注意：我必须根据投影矩阵的设置进行进一步的调整。

另外值得注意的是，我能够省略法线向量的.z分量，因为由于法线向量已标准化，所以我可以从.xy重建.z：

使用这种技术，我能够释放RGBA G缓冲区中的另一个通道，并用它来存储屏幕空间的镜面贴图（或光泽度，如果可以的话）。

是的，这是绝对可能的。填充率不是问题，因为移动图形芯片设计用于处理非常高分辨率的屏幕。实际上，延迟渲染对此有所帮助，因为您的光照计算与场景复杂性无关，因此透支不会导致速度降低。这是我在第四代iPad上的实现：http : //www.youtube.com/watch?v=K4X1oF6b4V8

如果要获得四倍的性能，则仅是渲染纹理的分辨率的一半。无论如何，我在视网膜屏幕上看不到3D图形有什么不同。

移动图形芯片非常擅长延迟渲染，因为它们处理渲染到纹理的方式。与PC图形卡不同，PC图形卡通常在您开始渲染到纹理而不是窗口上下文时会导致巨大的性能下降，而移动图形设计为做到这一点不会对性能造成任何影响。因此，您可以获得延迟渲染器的可伸缩性，而不会在台式机图形卡上遇到初期的性能损失。

在实施时，OpenGLES缺少向多个目标的渲染，因此我不得不在单独的通道中绘制屏幕颜色和法线。这可能在较新版本的OpenGLES中已修复，但不知道该解决方案是否已在消费类移动硬件中可用。