我很快发现在 OpenGL 中准备渲染时必须考虑的组织因素之一是地形的类型和顶点的排列。
现在有一些有趣的方法可以将顶点组织成很长的数组，很好地使用交错数组、索引等，这样您就可以将大量几何图形倒入一个 OpenGL 调用中。
但在某些情况下，使用较小的顶点数组简单地迭代和执行多次调用要容易得多。
虽然我同意过早优化有点浪费的观点，但考虑到最小化 OpenGL 调用的重要性，特别是如果多次调用实际上每次调用涉及的顶点要少得多的话？
我可以看到这是在开发过程早期很重要的决定之一，因为它形成了许多顶点如何创建和组织的结构。
您发送到 GPU 的每个命令都会产生开销。通过对顶点进行批处理，您可以最大限度地减少开销，并允许驱动程序在将数据发送到硬件之前对您的数据进行小幅优化。它可以产生很大的不同，这也是 glBegin 和 glEnd 从 OpenGL 的更新迭代中完全删除的原因。
您应该尽量避免进行许多驱动程序状态更改和许多绘图调用。
编辑：考虑在三角形条带中使用退化顶点（也有助于最大限度地减少处理的顶点数量），以便您可以只使用一个绘图调用并渲染所有拓扑（除非您需要更改拓扑部分之间的某些驱动程序状态） .
您可以找到适合您特定需求的平衡点。但问题是等式中有很多变量。并且没有简单的解决方案（比如“总是将场景制作成一个大批量！ ”）。TraxNet给了你一个很好的建议——总是尽量减少 api 调用（无论是绘图还是状态更改）。但这不仅仅是几个电话。在现代 PC 上，每帧可能是数千个，而不是现代手机，也许只有几百个。TraxNet还提到了退化三角形（帮助形成条带）——尽管它们仍然是三角形（有点添加到渲染的“总”三角形计数中）——它们几乎没有任何成本，仍然有助于最大限度地减少绘制调用的数量。