顶点着色器后的OpenGL三角形退化？

Posted 2023-02-22

【中文标题】顶点着色器后的OpenGL三角形退化？

【英文标题】：OpenGL triangle degeneration after vertex shader?

【发布时间】：2016-05-06 09:58:59

【问题描述】：

参考那个question：

有几种方法可以提高大型网格的渲染速度。我尝试了以下实现：

仅渲染网格，无需任何优化或量化。 我决定将我的网格量化为 CPU 上的预处理步骤，并在运行时切换 LOD 级别（= 量化级别）。我提交整个顶点数据并使用 Drawcall(numberOfNotDegeneratedIndices) 进行渲染。 -> 比 (0) 快 我现在的想法：在顶点着色器中进行整个量化（所有顶点数据都用于计算和动态 LOD 切换）。三角形退化应该在顶点处理步骤之后自动发生。 Drawcall(numberOfAllIndices) -> 并不比 (0) 快

比较方法：提交的顶点数据量始终相同。 VS 调用：(0) == (2) > (1)

所以我想知道为什么方法 (2) 没有比 (0) 更快，尽管量化和导致三角形退化？

我想了解更多信息为什么它会这样，以及 GPU 上的瓶颈可能在哪里。

【问题讨论】：

如果您的三角形不接触像素中心，您已经无需支付像素着色成本或任何下游成本。无论您的瓶颈是什么，它都不是像素着色。它可能是顶点着色，它可能是获取顶点着色器输入的成本，它可能是上游的东西；无论如何，让您的顶点着色更昂贵 无济于事。减少 GPU 看到的顶点数量，如您的 (1) 所示。

当你说“量化”时，你到底在做什么？

量化：将位置映射到[-1;1]，乘以2^level，round()，除以2^level

【参考方案1】：

我不想提出显而易见的问题，但是您是否尝试过将帧缓冲区的大小调整为 1x1 之类的荒谬的东西，并确认瓶颈实际上是顶点处理？

鉴于没有截图或任何可参考的内容，我不得不猜测您要渲染的“巨大”网格是什么样子的；我可以想到很多场景，其中巨大的网格会导致大量过度绘制，此时您实际上可能会受到填充率的限制，并且使用不同的 LOD 几乎没有什么区别。

虽然听起来很有趣，但如果您绘制大量（可能不可见的）亚像素三角形，也可能会遇到光栅化性能瓶颈。许多人将永远无法在着色中生存，因为它们不满足覆盖规则，但是如果您在光栅化阶段获得足够的微小图元，您确实会付出与顶点处理无关的惩罚。 LOD 非常适合解决该问题，因此这不太可能是您的问题。