目前我已经使用OpenGL实现了延迟渲染，它现在相当简单。然而，由于目前使用模板传递(至少在我目前使用它的方式中)，我遇到了主要的性能问题。我主要使用ogldev。Atspace教程(每篇文章只有2个链接，对不起!)作为参考，以及其他文章中的几十个花絮信息。
它的工作原理如下:
- Gbuffer通道(渲染几何和填充法线，漫反射，环境等)
- 每个灯模板传递2b)光通
- 切换到屏幕
以这种方式使用模板通道会产生巨大的成本，因为我需要在场景中的每个光的光通道模式和模板模式之间进行切换。这是很多GL状态互换。
没有模板传递的另一种方法如下所示:- Gbuffer填补
- 设置光通道
- 计算所有灯光
- 切换到屏幕
这样做跳过了为场景中的每个灯交换所有OpenGL状态(和缓冲区清除等)的需要。
我已经使用CodeXL和基本fps的std::cout'来测试/分析这个。使用模板传递方法的状态改变函数占用了我的GL调用的44%(相比之下，绘制和纹理的调用分别为6%和6%)，缓冲区交换/清除等也花费了相当多的%。当我使用第二种方法时，GL状态变化下降到2.98%，其他方法也下降了相当大的幅度。FPS也会发生巨大的变化，例如我的场景中有65~盏灯，动态移动。如果我幸运的话，在发布模式下，Stencil Pass的帧数可以达到20-30帧(渲染占了总时间的大部分)。第二种方法给了我71~(渲染时间占总时间的一小部分)。
为什么不直接使用第二种方法呢?它会导致严重的光线问题，这是我第一次遇到的问题。我不知道怎么摆脱他们。下面是一个例子:
第二个非模板版本(它本质上是在其范围之外的东西上流血和重叠):https://i.stack.imgur.com/fIRqG.jpg
第一个模板版本(应该是什么样子):https://i.stack.imgur.com/PDlOL.jpg
所以我的主要问题是，有没有一种方法可以避免使用模板传递(并使用类似于第一个没有图形故障的东西)而不完全改变算法，如平铺延迟渲染?
如果不是，他们是一个替代延迟渲染方法，这不是太多的跳跃从延迟渲染器的风格，我正在使用?
摆脱模板传递对我来说并不是一个新问题，当我第一次实现它时，我在寻找一个替代方案，大约6个月后，我认为它可能对我的想法来说有点太大了。但我当时找不到任何东西，现在也找不到。
另一个在Doom3中用于照明的技术如下:
http://fabiensanglard.net/doom3/renderer.phpFor each light
render the geometry affected only by 1 light
accumulate the light result (clamping to 255)
作为优化，你可以添加一个剪刀测试，这样你将只渲染每个光的几何可见部分。
与模板灯相比，它的优点是，如果你想的话，你可以进行复杂的光计算，或者只保留简单的光。整个工作是GPU，你没有多余的状态改变(你只设置一个着色器，一个vbo，你每次只改变光和剪刀测试区域的统一参数重新绘制)。你甚至不需要G-Buffer