0

目前我已经使用 OpenGL 实现了延迟渲染，它现在相当简单。但是，由于目前使用模板通道（至少以我目前使用它的方式），我遇到了主要的性能问题。我主要使用 ogldev.atspace 教程（抱歉，每个帖子只有 2 个链接！）作为参考以及其他文章中的几十条信息。

它的工作原理如下：

  1. Gbuffer pass（渲染几何和填充法线、漫反射、环境等）
  2. 对于每个灯 2a) 模板通道 2b) 灯通道
  3. 换屏

问题是以这种方式使用模板通道会产生巨大的成本，因为我需要为场景中的每个灯光在光通道模式和模板模式之间切换。所以这是很多 GL 状态交换。

没有模板通道的替代方法如下所示：

  1. Gbuffer 填充
  2. 设置光通
  3. 计算所有灯光
  4. 换屏

这样做无需为场景中的每个灯光交换所有 OpenGL 状态（和缓冲区清除等）。

我已经使用 CodeXL 和基本 fps 的 std::cout'ng 对此进行了测试/分析。使用模板传递方法的状态更改函数占用了我 GL 调用的 44%（相比之下，绘制为 6%，纹理为 6%），缓冲区交换/清除等也花费了相当多的 %。当我使用第二种方法时，GL 状态变化下降到 2.98%，其他的下降幅度也相当大。FPS 也发生了巨大变化，例如我的场景中有 65~ 个灯光，动态移动。如果我在发布模式下幸运的话，Stencil Pass 给我大约 20-30 fps（渲染占用了大部分时间）。第二种方法给了我 71~ （渲染占总时间的较小部分）。

现在为什么不直接使用第二种方法呢？好吧，它会导致严重的照明问题，这是我第一次没有得到的。我不知道如何摆脱它们。这是一个例子：

第二个非模板版本（它基本上会流血并重叠在其范围之外的东西上）：http: //imgur.com/BNn9SP2

第一个模板版本（它应该看起来如何）：http: //imgur.com/kVGRwH2

所以我的主要问题是，有没有办法避免使用模板通道（并使用类似于第一个没有图形故障的东西）而不将算法完全更改为平铺延迟渲染之类的东西？

如果不是，他们是否是另一种延迟渲染方法，这与我正在使用的延迟渲染器的风格没有太大的区别？

摆脱模板通行证对我来说并不是一个新问题，当我第一次实现它时，我正在寻找一个替代方案，大约 6 个月前，我认为这对于我所拥有的东西来说可能有点过多的开销心里。但我当时什么都找不到，现在仍然找不到。

4

1 回答 1

0

Doom3 中用于照明的另一种技术如下：

http://fabiensanglard.net/doom3/renderer.php

For each light
    render the geometry affected only by 1 light
    accumulate the light result (clamping to 255)

作为优化，您可以添加一个剪刀测试，以便您只为每个灯光渲染几何图形的可见部分。

与模板灯相比，它的优势在于您可以根据需要进行复杂的灯光计算，或者只保留简单的灯光。整个工作都是 GPU，您没有多余的状态更改（您仅设置 1 个着色器，仅设置 1 个 vbo，并且每次仅更改灯光和剪刀测试区域的统一参数）。你甚至不需要 G-Buffer。

于 2015-07-12T07:44:49.917 回答