Directx 再一次：三角形带与三角形列表

我决定在三角形列表上构建我的引擎，因为（不久前）阅读了索引三角形列表由于需要更少的绘制调用而表现得更好。今天我偶然发现了0xFFFFFF，它在DX中被认为是条带切割索引，因此您可以在一次调用中绘制多条带。这是否意味着三角形列表不再具有优异的性能？

可以在一次绘制调用中绘制多个面积为零的三角形条带。通过简单地重复上一条带的最后一个顶点和下一条带的第一个顶点，每个条带打断添加两个元素（两个零面积三角形），即可进行条带切割

Direct3D 10中新增了条带切割索引（用于索引几何体）和。两者都可以用来代替退化三角形方法，有效地降低带宽成本。（切割只需要一个索引，而不是两个索引。）

表现力 是否可以将任何基本列表转换为相等的条带，反之亦然？从条带到列表的转换当然是微不足道的。对于列表到条带的转换，我们必须假设我们可以切割条带。然后，我们可以将列表中的每个基本体映射到一个基本体子条带，尽管这不会有用

因此，至少对于三角形原语，条带和列表始终具有相同的表达能力。在Direct3D之前，不可能在线条中切割10条线条，因此它们实际上没有同样的表现力

内存和带宽 需要向GPU发送多少数据？为了比较这些方法，我们需要能够计算特定拓扑所需的元素数量

基本列表公式

N ... total number of elements (vertices or indices)
P ... total number of primitives
n ... elements per primitive (point => 1, line => 2, triangle => 3)

N = Pn

N, P, n ... same as above
S ... total number of sub-strips
o ... primitive overlap
c ... strip cut penalty

N = P(n-o) + So + c(S-1)

基本条带公式

N ... total number of elements (vertices or indices)
P ... total number of primitives
n ... elements per primitive (point => 1, line => 2, triangle => 3)

N = Pn

N, P, n ... same as above
S ... total number of sub-strips
o ... primitive overlap
c ... strip cut penalty

N = P(n-o) + So + c(S-1)

图元重叠描述相邻图元共享的图元数。在经典三角形带中，三角形使用前一个基本体的两个顶点，因此重叠为2。在直线带中，直线之间仅共享一个顶点，因此重叠为1。理论上，使用1重叠的三角形条带当然是可能的，但在Direct3D中没有表示形式

剥离惩罚是指开始新的子剥离所需的元素数。这取决于所使用的方法。使用条带切割指数，惩罚为1，因为一个指数用于分隔两条带。使用退化三角形，惩罚将是两个，因为我们需要两个零面积三角形用于条带切割

从这些公式中我们可以推断，它取决于几何体，哪种方法需要最少的空间

缓存 条带的一个重要特性是数据的高度。组装新图元时，需要从GPU内存中提取每个顶点。对于三角形，必须进行三次。现在访问内存通常很慢，这就是处理器使用多级缓存的原因。在最好的情况下，所需的数据已经存储在缓存中，从而减少了内存访问时间。现在，对于三角形条带，将使用上一个基本体的最后两个顶点，几乎可以保证缓存中已经存在三个顶点中的两个

易用性 如上所述，将列表转换为条带非常简单。问题是通过减少子条带的数量将列表转换为有效的基本条带。对于简单的程序生成的几何体（例如heightfield地形），这通常是可以实现的。为现有网格编写转换器可能更困难

结论

---

Direct3D 10的引入对strip vs.list问题没有太大影响。现在，线条条具有相同的表现力，并且略微减少了数据量。在任何情况下，当使用条带时，如果减少子条带的数量，您总能获得最大的收益。

在具有前后变换的现代硬件上，三条带并不能战胜索引三角形列表。唯一一次真正使用tri-Striping的是非索引原语，这些原语是由一些不需要计算条带的东西生成的，例如地形系统

---

相反，您应该对索引三角形列表进行顶点缓存优化，以获得最佳性能。已经实施了，或者您可以查看

您似乎是对的，尽管我没有任何证据。然而，您必须在条带化的预计算中投入更多的精力。条带化主要需要一个非平凡的数据结构。但如果你能负担得起，你可能是对的。