目前，我已经使用OpenGL实现了延迟渲染，这一点非常简单。然而，由于目前使用模板传递，我遇到了重大的性能问题（至少在我使用它的当前方式中）。我主要使用ogldev.atspace教程（每个帖子只有2个链接atm抱歉！）作为参考以及来自其他文章的几十个花絮。
它的工作原理如下：
以这种方式使用模板通道会产生巨大的成本，因为我需要在光通过模式和模板模式之间切换场景中的每个光。因此很多GL州交换。
没有模板传递的替代方法如下所示：
这样做可以避免为场景中的每个灯光交换所有OpenGL状态（以及缓冲区清除等）。
我使用CodeXL和基本fps的std :: cout＆＃39; 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个月左右，并认为它可能有点过多的开销因为我的想法。但我当时找不到任何东西，但仍然无法做到。
答案 0 :(得分：0)
Doom3中用于照明的另一个tecnique如下：
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。