如何在没有着色器的纹理数组中使用glDrawArrays

Question

我试图通过将纹理组合成数组纹理来优化我的代码（我意识到我不能使用纹理图谱，因为大多数纹理都是重复的（在地面上等等）。我在PyGame和PyOpenGL中工作，以前从未使用过着色器。是否可以用glBindTexture(GL_TEXTURE_2D_ARRAY, texname)绑定一个数组纹理，并使用3d纹理坐标或其他东西来访问不同的层？甚至没有着色器也可能吗？在

目前，我有一个调用glDrawArrays的函数，用于每个纹理：

def DRAW(im, array):
    glBindTexture(GL_TEXTURE_2D,im)
    glTexCoordPointer(2, GL_FLOAT, 32, array)
    glNormalPointer(GL_FLOAT, 32, array[2:])
    glVertexPointer(3, GL_FLOAT, 32, array[5:])
    glDrawArrays(GL_QUADS,0,len(array)/8)

Answer 1

正如@derhass在回答中引用的规范所示，没有着色器就不支持数组纹理。在

然而，你可以使用3D纹理做几乎相同的事情。将每个纹理存储在3D纹理的一个层中。然后像往常一样使用前2个纹理坐标来确定纹理图像中的位置。第三个纹理坐标用于选择3D纹理内的层。在

要将图像加载到3D纹理中，请使用glTexSubImage3D()。例如，假设纹理的大小为512x512，并且要加载纹理索引20：

glTexSubImage3D(GL_TEXTURE_3D, 0,
    0, 0, 20, 512, 512, 1,
    GL_RGBA, GL_UNSIGNED_BYTE, data);

唯一稍微棘手的部分是正确计算第三个纹理坐标，因为纹理坐标是标准化的浮点。特别是如果你使用线性采样，你必须精确地击中一个层的中心，否则你会得到一个混合图像。在

如果3D纹理中有n层，层k的纹理坐标为：

^{pr2}$

例如，使用n = 4，4层的结果纹理坐标将是：

0.125f
0.375f
0.625f
0.875f

注意这些值是如何以0.25f为间隔的，正如您所期望的那样，并在间隔[0.0f, 1.0f]内对称放置

使用3D纹理的一个缺点是它们的尺寸限制较小。使用这种方法，请确保不要超过MAX_3D_TEXTURE_SIZE。在

我鼓励您学习使用着色器。一开始可能看起来有点吓人，因为对于非常简单的用例来说，这肯定要做更多的工作。但是你会发现，一旦你掌握了窍门，当你的功能变得更复杂时，它们会让事情变得更简单。编写GLSL代码来精确地执行您想要的操作通常要简单得多，而不是尝试如何正确地设置几十个状态值以获得所需的结果。当然，着色器允许您实现在固定管道中根本不可能实现的功能。在

Answer 2

纹理数组不能在没有着色器的情况下使用。它们从来不是固定功能管道的一部分。GL中没有GL_TEXTURE_2D_ARRAY启用位。在

固定函数片段处理在OpenGL 4.5 compatibility profile specification.的第16节中指定。第16.2节规定：

Array and multisample textures are only supported by shaders, and may not be enabled for fixed-function texturing.

在原始的GL_EXT_texture_array扩展中，您将发现以下语句：

(2) Should texture arrays be supported for fixed-function fragment processing?

RESOLVED: No; it's not believed to be worth the effort. Fixed-function fragment processing could be easily supported by allowing applications to enable or disable TEXTURE_1D_ARRAY_EXT or TEXTURE_2D_ARRAY_EXT.

Note that for fixed-function fragment processing, there would be issues with texture lookups of two-dimensional array textures with shadow mapping. Given that all texture lookups are projective, a total of five coordinate components would be required (s, t, layer, depth, q).

(3) If fixed-function were supported, should the layer number (T or R) be divided by Q in projective texture lookups?

RESOLVED: It doesn't need to be resolved in this extension, but it would be a problem. There are probably cases where an application would want the divide (handle R more-or-less like S/T); there are probably other cases where the divide would not be wanted. Many developers won't care, and may not even know what the Q coordinate is used for! The default of 1.0 allows applications that don't care about projective lookups to simply ignore that fact.

For programmable fragment shading, an application can code it either way and use non-projective lookups. To the extent that the divide by Q for projective lookups is "free" or "cheap" on OpenGL hardware, compilers may be able to recognize a projective pattern in the computed coordinates and generate code appropriately.

当数组纹理升级为OpenGL核心功能时，这一点没有改变。在