我正在构建一个延迟渲染器,因为我想在场景中支持大量灯光,所以我查看了平铺延迟着色。
问题是我必须以 OpenGL 3.3 硬件为目标,而且它不支持 GLSL 计算着色器。
是否有可能使用普通着色器实现平铺延迟着色?
我正在构建一个延迟渲染器,因为我想在场景中支持大量灯光,所以我查看了平铺延迟着色。
问题是我必须以 OpenGL 3.3 硬件为目标,而且它不支持 GLSL 计算着色器。
是否有可能使用普通着色器实现平铺延迟着色?
平铺延迟渲染并不严格要求计算着色器。它需要的是,对于每个图块,您都有一系列将要处理的灯。计算着色器只是实现这一目标的一种方法。
另一种方法是为 CPU 上的每个截锥体构建灯光列表,然后将该数据上传到 GPU 以供最终使用。显然它比 CS 版本需要更多的内存工作。但它可能并不那么昂贵,它可以让您轻松地使用瓷砖尺寸来找到最佳尺寸。更多的瓦片意味着更多的 CPU 工作和更多要上传的数据,但每个瓦片的光照更少(一般而言)和更高效的处理。
对于 GL 3.3 级硬件,一种方法是使每个图块成为单独的四边形。作为每个顶点参数的一部分,quad 将被给出它在总灯光列表中的部分的起始索引以及该图块要处理的灯光总数。这个想法是有一个全局可访问的数组,每个图块都有这个数组的一个连续区域,它将处理。
这个数组可以是实际的灯光本身,也可以是第二个(小得多的)灯光数组的索引。您必须测量差异以判断是否值得在访问中使用额外的间接性。
主数组可能应该是一个缓冲区纹理,因为它可以变得非常大,具体取决于灯光和瓦片的数量。如果您使用间接路线,那么实际光数据数组可能会适合统一块。但是在任何一种情况下,您都需要在上传到它时使用缓冲流技术。