3

我试图了解 WebGL 用于渲染由 100K 三角形组成的大型室内场景的实用性。这些三角形分布在很多物体上，场景中有很多材质。另一方面，没有移动部件。而且材料往往相当简单，主要基于纹理贴图。有很多纹理贴图共享..例如场景中的所有椅子都将共享一个公共贴图。还有一些多重纹理 - 最多三个纹理覆盖在材料中。

我一直在做一些实验和阅读，并收集到在渲染过程中频繁切换材质会减慢速度。例如，一个具有 200K 三角形的场景会有显着的性能差异，这取决于是有 10 个对象还是 1000 个对象，假设每次显示一个对象时都会设置一个新材质。

因此，如果性能很重要，则似乎应该按材质对场景进行排序，以最大程度地减少材质切换。我正在寻找的是关于如何考虑各种状态变化的开销的指南，以及我在哪里可以获得最大的收益。例如，

  • gl.useProgram()例如, , gl.uniformMatrix4fv(),的相对性能成本是多少gl.drawElements()
  • 我应该尝试编写 ubershader 来最小化着色器切换吗？
  • 我应该尝试聚合几何以最小化gl.drawElements()调用次数吗

我意识到里程可能会因浏览器、操作系统和图形硬件而异。而且我也不是在寻找英勇的措施。只是一些已经有一些快速制作场景经验的人的一些指导。我要补充一点，虽然我过去在固定流水线 OpenGL 编程方面有一些经验，但我对 WebGL/OpenGL ES 2.0 的处理方式还是比较陌生。

4

1 回答 1

4

你读过批次，批次，批次吗？诚然，它专注于 directX，但其推理在较小程度上也适用于 Open/WebGL：每个 API 调用在 CPU 上都有很大的开销。建议是使用所有 API 的选项来共享纹理、使用实例化（如果可用）、编写复杂的着色器以避免许多绘制调用。因此，如果您可以在一次调用中将整个房子绘制为单个网格，那将比每个房间调用 1000 次要好。建议编写 ubershaders，但主要是因为它可能允许您删除绘制调用，而不是因为 GPU 状态切换很昂贵。

这假设最近的硬件。对于低端平台（iPad？）或英特尔 GMA 芯片，瓶颈将在其他地方（如软件顶点处理）。

于 2011-01-04T21:47:40.683 回答