我正在尝试了解 WebGL 在渲染由 10 万个三角形组成的大型室内场景方面的实用性。这些三角形分布在很多物体上，场景中的 Material 也很多。另一方面，没有移动部件。而且 Material 往往相当简单，主要基于纹理贴图。有很多纹理贴图共享......例如场景中的所有椅子将共享一个公共(public)贴图。还有一些多重纹理 - 最多三个纹理覆盖在一个 Material 中。
我一直在做一些实验和阅读，并了解到在渲染过程中频繁切换 Material 会减慢速度。例如，具有 200K 个三角形的场景将具有显着的性能差异，这取决于是否有 10 个或 1000 个对象，假设每次显示一个对象时都会设置一个新 Material 。
因此，如果性能很重要，那么场景应该按 Material 排序，以尽量减少 Material 切换。我正在寻找的是有关如何考虑各种状态更改的开销的指南，以及我从哪里获得最大 yield 的指南。例如，
gl.useProgram()、gl.uniformMatrix4fv()、gl.drawElements()的相对性能成本是多少>- 我应该尝试编写 ubershaders 以尽量减少着色器切换吗？
- 我是否应该尝试聚合几何以尽量减少
gl.drawElements()调用的次数
我知道里程可能因浏览器、操作系统和图形硬件而异。而且我也不是在寻找英勇的措施。只是一些已经有一些快速制作场景经验的人的指导方针。我要补充一点，虽然我过去有过一些固定管道 OpenGL 编程的经验，但我对 WebGL/OpenGL ES 2.0 的处理方式还是比较陌生。
最佳答案
你读过batch, batch, batch吗？ ？不可否认，它侧重于 directX，但推理在较小程度上也适用于 Open/WebGL:每个 API 调用都会对 CPU 造成很大的开销。建议使用所有 API 的选项来共享纹理、使用实例化(如果可用)、编写复杂的着色器以避免多次绘制调用。因此，如果您可以在一次调用中将整个房子绘制为单个网格，那将比每个房间调用 1000 次要好。推荐编写 ubershaders，但主要是因为它可以让您删除绘制调用，而不是因为 GPU 状态切换很昂贵。
这是假设最近的硬件。对于低端平台(iPad？)或英特尔 GMA 芯片，瓶颈将出现在其他地方(如软件顶点处理)。
关于performance - 通过最小化着色器/状态更改来优化 WebGL 性能的指南，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4520768/