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