【问题标题】:Tiled deferred shading without compute shader没有计算着色器的平铺延迟着色
【发布时间】:2016-07-16 08:35:31
【问题描述】:

我正在构建一个延迟渲染器,因为我想在场景中支持大量灯光,所以我查看了平铺延迟着色。

问题是我必须以 OpenGL 3.3 硬件为目标,而且它不支持 GLSL 计算着色器。

是否有可能使用普通着色器实现平铺延迟着色?

【问题讨论】:

  • 我不这么认为。 Tilled 延迟渲染要求您在同一工作组中的着色器调用之间进行通信(例如,需要存储一个公共可见光列表),如果没有计算着色器,这是不可能的。
  • 嗯...好的。那有什么建议吗?我在考虑的另一种方法是光量,但我认为它不能很好地适应大量光。

标签: opengl deferred-rendering deferred-shading


【解决方案1】:

平铺延迟渲染并不严格需要计算着色器。它需要的是,对于每个图块,您都有一系列将要处理的灯。计算着色器只是实现这一目标的一种方法。

另一种方法是为 CPU 上的每个截锥体构建灯光列表,然后将该数据上传到 GPU 以供最终使用。显然它比 CS 版本需要更多的内存工作。但它可能不会那么昂贵,它让您可以轻松地使用瓷砖尺寸来找到最佳尺寸。更多瓦片意味着更多的 CPU 工作和更多要上传的数据,但每个瓦片的光照更少(一般而言)和更高效的处理。

对 GL 3.3 级硬件执行此操作的一种方法是使每个图块成为单独的四边形。作为每个顶点参数的一部分,quad 将被指定为它在总灯光列表中的一部分的起始索引以及该图块要处理的灯光总数。这个想法是有一个全局可访问的数组,每个图块都有这个数组的一个连续区域,它将处理。

这个数组可以是实际的灯光本身,也可以是第二个(小得多的)灯光数组的索引。您必须测量差异以判断是否值得在访问中使用额外的间接性。

主阵列可能应该是buffer texture,因为它可以变得非常大,具体取决于灯光和瓷砖的数量。如果您使用间接路线,那么实际光数据数组可能会适合统一块。但无论哪种情况,您都需要在上传时使用缓冲流技术。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-09-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多