我确信如果你通过绑定缓冲区glBindBuffer()
,您可以放心地假设它保持绑定状态,直到目标通过另一个调用反弹glBindBuffer()
。因此,当我发现调用时,我感到非常惊讶glBindVertexArray()
将绑定到 GL_ELEMENT_ARRAY 目标的缓冲区设置为 0。
这是最小的 C++ 示例代码:
GLuint buff;
glGenBuffers(1, &buff);
std::cout << "Buffer is " << buff << "\n";
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buff);
GLuint vao;
glGenVertexArrays(1, &vao);
GLint bound_buff;
glGetIntegerv(GL_ELEMENT_ARRAY_BUFFER_BINDING, &bound_buff);
std::cout << "Bound before glBindVertexArray: " << bound_buff << "\n";
glBindVertexArray(vao);
// ^- an implicit glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0); ?
glGetIntegerv(GL_ELEMENT_ARRAY_BUFFER_BINDING, &bound_buff);
std::cout << "Bound after glBindVertexArray: " << bound_buff << "\n";
我在初始化 OpenGL 3.2 设备上下文后立即运行此代码并获得以下输出:
Buffer is 1
Bound before glBindVertexArray: 1
Bound after glBindVertexArray: 0
另一方面,GL_ARRAY_BUFFER 是not因通话而改变。我检查了 OpenGL 3.2 规范 (2.10)glBindVertexArray
并没有发现任何提及这种意想不到的副作用。
- 这种行为符合规范吗?
- 如果是这样,调用以下命令还会产生哪些其他副作用
glBindVertexArray
?
- 这背后的理由是什么?
我在带有 296.10 WHQL 驱动程序的 Win XPx64 机器上的 nvidia 卡上进行了测试。
使用 nvidia GT330M 在 OS X Lion 上进行的快速测试得出了相同的结果。
顶点数组对象 http://www.opengl.org/wiki/Vertex_Array_Object封装渲染顶点数据所需的所有状态*。因此,它们必须封装与属性关联的缓冲区(通过glVertexAttribPointer
), GL_ELEMENT_ARRAY_BUFFER (需要glDrawElement*
调用)等。
然而,我仍然感到有点困惑,因为我在文档中找不到任何关于这种副作用的提及。
规范清楚地解释了这一点,尽管需要了解规范的工作原理才能了解其工作原理。
OpenGL 是状态的集合,这意味着所有 OpenGL 函数(除了那些实际渲染某些内容的函数)都会修改 OpenGL 状态。你打电话时glVertexAttribPointer
,这个函数从概念上修改了一些内部 OpenGL 状态。
OpenGL对象 http://www.opengl.org/wiki/OpenGL_Object由它们封装的 OpenGL 状态片段定义。因此,如果函数修改对象封装的状态,那么该函数也会修改对象本身。绑定对象意味着用该对象的当前状态替换它们封装的当前状态。
The ARB_顶点_数组_对象 http://www.opengl.org/registry/specs/ARB/vertex_array_object.txt规范根据 VAO 封装的状态来定义它们。它基本上指向一个 OpenGL 状态表并说:“VAO 就是所有这些。”此功能的核心 3.x 版本实际上修改了状态表以使其更加清晰(相同的行为,其解释略有不同):
OpenGL 3.3 规范,第 2.10 节:
生成的顶点数组对象是一个新的状态向量,包含表 6.4 和 6.5 中列出的所有状态值。
我不打算重印表 6.4 和 6.5;你可以自己查一下。但它们显然包括GL_ELEMENT_ARRAY_BUFFER_BINDING
以及各种GL_VERTEX_ATTRIB_ARRAY_BUFFER_BIDNING
(它们是缓冲区对象)。
* 注意:VAO 不包含由glVertexAttrib http://www.opengl.org/wiki/GLAPI/glVertexAttrib功能。如果未启用属性数组,这些可能会影响渲染。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)