关于opengl：GL_QUADS有什么不好的地方？

What is so bad about GL_QUADS?

我听说GL_QUADS将在OpenGL版本> 3.0中删除，为什么？那我的旧程序将来会不会工作？我已经进行了基准测试，并且GL_TRIANGLES或GL_QUADS的渲染速度没有差异(甚至可能是GL_QUADS更快)。那有什么意义呢？

关键是您的GPU渲染三角形，而不是四边形。从两个三角形构造一个矩形几乎是微不足道的，因此，API不需要真正地具有原生渲染四边形的能力。 OpenGL正在经历一个重要的修整过程，削减了15年前有意义的许多功能，但不再匹配GPU的工作方式或GPU的工作方式。我相信，固定功能管道也从最新版本中删除，因为再次不再需要固定功能管道，并且它不再匹配GPU的工作方式(可编程着色器)。

关键是可以使OpenGL API变得更小和更紧密，供应商更容易编写健壮的高性能驱动程序，更容易学会正确有效地使用API??。

几年前，OpenGL中几乎所有的事情都可以用3-5种不同的方式完成，这给开发人员带来了很多负担，使他们无法确定哪种实现是最佳性能。

因此，他们正在尝试简化API。

相关讨论

好的答案，但是不同版本的OpenGL呢？例如。 OpenGL 1vs2vs3vs4？
@pst：OpenGL的不同版本呢？
@pst：那他们呢？我不确定你是什么意思。较早版本的API显然不会受到以后版本中发生的影响。
@Nicol Bolas主要是在进化和"简化"方面。拥有资源或趋势的小摘要将很有趣-其中一些已经发布，但没有绑定版本以供参考。
@pst：我仍然看不到你在说什么。你想知道什么？
在经历了近十年的停滞和非常小的更新之后，v3.0版将OpenGL的控制权转移给了Khronos组。从那时起，Khronos一直在努力：1)在特性和功能方面赶上DX，以及2)简化API，摆脱在现代GPU上没有意义的旧问题。
@jalf：从技术上讲，没有十年的停滞和微小的更新； GLSL几乎是次要的。 Khronos获得ARB的唯一原因(而Khronos ARB的大多数成员都是原成员)是因为AGI的前所有者SGI快要死了。不，停滞发生在ARB决定尝试重写整个API时。这花了2年，并没有真正发生。
@Nicol：请问，他们花了多长时间才获得2.0？ 2.1？在Khronos接手之前，OpenGL远远落后于Direct3D。那是化石。是的，他们设法使GLSL脱颖而出，但仍比HLSL和Cg的状态落后几年。
@jalf："处于状态的背后"与"使状态变得存在"之间存在区别。 GLSL的问题不是因为花费了很长时间。这是因为在其形成和标准化过程中做出了许多可怕的决定。如果做出了正确的决定，那么将花费相同的时间来生产，但结果会更好。时间不是GLSL的主要问题； GLSL是GLSL的主要问题。而且，HLSL和Cg都在GLSL的大约一年之内发布，因此并没有远远落后。
@Nicol GLSL，HLSL和Cg arent只是单个实体。这三个版本都有许多不同的版本，具有不同的功能和限制。而且我不确定为什么您选择专门关注GLSL。就像我说的，正在研究近十年来非常缓慢的进展。他们设法将着色语言排除在外的事实并不意味着整个OpenGL突然看起来不再像化石。很抱歉，如果您在情感上投入了API，但是当我说多年以来它们与3d世界完全不协调时，我没有做出弥补
@jalf：我同意OpenGL曾经"与3d世界不协调"。关于他们的失败，我什至写了一个半受欢迎的答案。问题是您首先说过"停滞了十年，并且进行了非常小的更新"，这是完全不同的事情。 ARB的问题并非未能更新API。 ARB的问题是错误地更新了它。如果您下坡，这不会停滞。
@jalf，我已经在三角形和四边形之间进行了大量测试，每次我发现四边形更快时。 GPU的工作方式是否有意义？在GPU内，四边形实际上是否比三角形更好？还是有关内存管理器的事情：三角形占用更多内存。但是我已经将我的VBO缓冲区设置为相同的大小...也许我渲染了多少个缓冲区？
@jalf，现在经过了更多测试，无论我有什么设置，GL_QUADS总是更快。我尝试将所有缓冲区计数设置为相同，将所有缓冲区大小设置为相同，依此类推。但是GL_QUADS总是取胜，当我将它们设置为使用完全相同的缓冲区数量时，这两者之间的差异最小：三角形为33fps，四边形为36fps。所以，还有其他人做过这样的测试吗？这让我想起为什么他们想摆脱它，甚至更快。
@Rookie：但是再一次，您没有在不同的操作系统下使用不同的GPU对其进行过测试。在所有这些情况下，您如何确定其速度更快？另一个重要的一点是，OpenGL始终将四边形转换为三角形，因为GPU只能渲染三角形。因此，在这种情况下，OpenGL不会做您无法高效完成的任何事情。因此，如果您的代码显示四边形更快，那么听起来好像三角形渲染代码的编写不如四边形渲染同上。 :)
这就是为什么将其删除。 15年前，四边形与三角形一样好，因为您可以在没有专用硬件的CPU上渲染，也可以在各种类似GPU的硬件上进行渲染，其中一些原生支持四边形。但是今天，没有GPU原生支持Quads。因此，OpenGL在现代实现中对四边形的支持归结为它在内部将每个四边形切成两半，并渲染生成的三角形。只是不需要3d API来做到这一点。如果您真的想要四边形，则可以轻松定义一个外部帮助程序库
@jalf，我的四边形/三角形渲染代码是相同的，除了我在三角形渲染代码中再压入了2个额外的顶点，然后导致了更大的缓冲区。另外，将四边形拆分成两半实际上会更快，因为它使用的内存减少了2个顶点，这会有意义吗？如果您有Vertex，Color，TexCoord，Normal，VertexAttr，那么在浪费这些时间的情况下，它可以使用已经读取的值……更不用说节省多少内存了！
@新秀：不，因为无论发生什么分裂。再次，GPU不了解四边形。因此，选择是拆分四边形，或者由OpenGL为您完成(在CPU端)。如果您的代码"完全相同"，那就是您的问题。您不需要发送更多的顶点。上载一个缓冲区，该缓冲区包含(可能在许多其他顶点中)定义了四边形的4个顶点。然后上传一个索引缓冲区，其中包含渲染两个三角形所需的6个顶点索引。如果您调用API的效率低下，则会导致结果倾斜。
@jalf，但我不想将任何内容发送到GPU ..我认为这就是使用VBO的全部要点：数据已经存在，不需要发送任何内容，这与顶点数组不同。
@Rookie：只有将数据以前发送到GPU时，数据才"已经在那里"。但是，让我改一下。为了渲染矩形，GPU在单个VBO中需要四个顶点，以及一个包含(至少)6个索引的索引缓冲区。 GPU仅看到每个唯一的顶点一次，但是对于其中的某些顶点(属于两个三角形的一部分)，它会遇到两个指向该顶点的索引。因此，GPU永远不会看到6个单独的顶点，就像您说的那样，这会更昂贵。它看到四个顶点，与在四边形情况下完全一样。
因此，您可以向GPU提供描述四个顶点的所有信息，然后告诉它"从顶点0、1和2绘制一个三角形"，然后"从顶点1、3和2绘制一个三角形"。那就是您的三角形渲染代码应该做的，这正是您的四边形渲染代码使OpenGL为您完成的工作。
@jalf，但是是否可以将索引一次上传到GPU？我找不到索引指针的功能(glIndexPointer用于颜色)，唯一的方法是使用glDrawElements()每帧再次发送它们？即使仅上传索引，在我的应用程序中也要花费150MB / s，我真的很想利用VBO的优势"一次上传"，并像显示列表一样使用它们，只是我可以轻松地修改他们。
@新秀：是的，这是可能的，甚至是标准做法。自从我使用OGL以来已经有一段时间了，但是我认为您只是在寻找索引缓冲区对象(IBO)。没有什么可以阻止您使VBO"一次上传"的，实际上，它们应该尽可能地远。但是您在这里混合了两种不同的讨论。 OpenGL渲染四边形的方法是在CPU端将其分割为4个顶点和6个索引，然后将其上传并从中渲染两个三角形。如果您不使用GL_QUAD，那也正是您应该做的，所以零额外开销
另一个问题是性能，在这里，当然，您应该尝试尽可能"上载一次"。顶点和索引都可以上载一次，然后渲染很多次，而这正是您应该做的。但是三角形和四边形都是这样
我只是用谷歌搜索，索引缓冲区是用glBufferDataArb(GL_ELEMENT_ARRAY_BUFFER_ARB, ...)创建的。那应该让您开始。
感谢您的帮助和耐心等待我的提问，请听取您的意见。
@jalf："包含(至少)6个索引的索引缓冲区" —一个旧注释，但是通过使用4个索引发送TRIANGLE_STRIP然后再发送一个重置索引，是否不可能发送5个索引？
Quads arent完全可以互换。插值不同：低多边形圆锥体-顶部平滑阴影
三角带和三角扇呢？它们也由三角形组成，因此应用相同的逻辑，也应弃用它们：q

人们已经很好地回答了您的问题。在他们的答案之外，不赞成使用GL_QUADS的原因之一是因为quads的不确定性质。

例如，尝试为点(0,0,0), (1,0,0), (1,1,1), (0,1,0)的2d正方形建模。这是扁平的四角形，向上拖动了一个角。用这种方法不可能画出普通的平面正方形。根据驱动程序的不同，它将以一种或另一种方式拆分为2个三角形，这是我们无法控制的。这样的模型必须用两个三角形来建模。 -三角形的所有三个点始终位于同一平面上。

相关讨论

它不是要去做任何事情。与许多其他功能一样，GL_QUADS在3.0版中已弃用，在3.1版中已删除。显然，如果您创建兼容性上下文，那么这一切都是无关紧要的。

任何人可能会因为弃用它们而给出任何答案，这纯粹是猜测。

相关讨论