OpenGL呈现状态管理

Question

我正在开发一款小型iPhone游戏，并且正在将我开始为Mac开发的3D引擎移植到iPhone上。这一切都很顺利，Mac引擎的所有功能现在都出现在iPhone上。引擎完全没有完成，但现在至少我有基本的资源管理，场景图和构造，可以轻松地动画和移动对象。

我现在拥有的截图：http://emle.nl/forumpics/site/planes_grid.png。小飞机是我几年前制作的一个测试对象，用于我当时制作的游戏。它与我现在正在开发的游戏无关，但当然是3D引擎及其设施。

现在，我来谈谈材料的主题，纹理，灯光等属于可渲染对象的描述。这意味着每个对象都有很多OpenGL clientstate和glEnable / glDisable调用。您建议以什么方式最小化这些状态变化？ 目前我按材料排序，因为具有相同材料的对象根本不需要任何更改。我创建了一个名为RenderState的类，它缓存当前的OpenGL状态，并且仅在选择不同材质时应用不同的成员。这是一个可行的解决方案，还是当引擎成熟并且需要缓存越来越多的状态时，它是否会超出控制范围？

Answer 1

一些建议。只需编写游戏所需的代码即可。不要花时间编写通用渲染引擎，因为它很可能你不需要它。如果你结束写另一个游戏，那么在那时将有用位提取到引擎中。这会更快。

Answer 2

如果OpenGL ES中的状态数量与标准版本一样高，则在某些时候难以管理。

此外，如果你真的想要最小化状态更改，你可能需要某种状态排序概念，以便具有相似状态的drawable一起呈现，而不需要它们之间的很多glEnable / glDisable。然而，即使在PC硬件上也可能难以管理（想象一下状态排序成千上万的drawable），盲目地改变状态可能实际上更便宜，具体取决于OpenGL的实现。

为了进行比较，这是OpenSceneGraph采用的方法：

基本上，场景图中的每个节点都有自己的状态集，用于存储材质属性，状态等。好处是状态集可以由多个节点共享。这样，渲染后端可以根据其状态集指针（不是stateset的内容！）对drawable进行排序，并将具有相同stateset的节点一起渲染。这提供了一个很好的权衡，因为后端不会受到管理单个opengl状态的困扰，但如果相应地生成场景图，则可以实现几乎最小的状态改变。

我建议，在您的情况下，您应该在坚持使用解决方案之前进行大量测试。无论你做什么，我都相信你需要对OpenGL状态进行某种抽象。