DrawIndexedPrimitive函数的详细解释【转】

「爱情、让人受尽委屈。」 2023-06-05 11:17 4阅读 0赞

为了便于说明，首先假设存在下列的顶点缓冲和索引缓冲  
vb=  
\{  
\{-1.0, 1.0, 0.0\}, index 0  
\{ 1.0, 1.0, 0.0\}, index 1  
\{ 1.0,-1.0, 0.0\}, index 2  
\{-1.0,-1.0, 0.0\}, index 3

\{-2.0, 2.0, 0.0\}, index 4

\{ 2.0, 2.0, 0.0\}, index 5

\}  
和对应该顶点缓冲的一组索引缓冲ib  
  
初学D3D，DrawIndexedPrimitive这个函数是个难点，主要是MSDN中的解释不是很明确，这个函数共6个参数，下面对这6个参数进行一下详细的解释。

参数1：D3DPRIMITIVETYPE type-图元类型  
使用的图元类型，这个比较好理解，D3D只能绘制三种图元-点、线和三角形，其中线和三角形又细分为线列表（LINELIST）、线条带（LINESTRIP）、三角列表（TRIANGLELIST）、三角条带（TRIANGLESTRIP），根据实际需要选择使用某一种图元，这不会影响最终的绘制效果，但理论上讲，同样多边形数目的物体，使用三角形要比使用线绘制效率高（一个三角形=3条线），而条带比列表要节省顶点数量，同样n个顶点，线列表能绘制n/2条线，线条带能绘制n-1条线，同样，三角列表能绘制n/3个三角形，而三角条带能绘制n-2个三角形，不过经过D3D最优化处理后，绘制条带或列表的性能差别并不大。

参数2：INT BaseVertexIndex-起始顶点索引  
MSDN中的原话是这样：Offset from the start of the vertex buffer to the first vertex.  
“从顶点缓冲的起始位置到第一个顶点的偏移量”，第一个顶点不就是起始位置么？不一定是，DrawIndexedPrimitive这个函数接受从顶点缓冲的任何一个位置开始读入顶点数据，你可以从index0的位置开始读取顶点数据，那这时BaseVertexIndex就是0，也可以从index2的位置开始读取数据，那这时BaseVertexIndex就是2，如此类推。

参数3：UINT MinVertexIndex-最小顶点索引（这里MSDN应该是个笔误，写成MinIndex了，应该是MinVertexIndex）  
MSDN：Minimum vertex index for vertices used during this call. This is a zero based index relative to BaseVertexIndex.  
本次函数调用中，顶点缓冲中最小的顶点索引。MSDN解释中我认为最关键的一句是“relative to BaseVertexIndex”-“相对与起始顶点”，即MinVertexIndex实际上也是个相对偏移量，例如，起始顶点是index2，MinVertexIndex是0，那么实际是从index2读入数据，起始顶点是index1，MinVertexIndex是1，那么实际也是从index2读入数据，即实际上的第一个顶点位置在BaseVertexIndex+MinVertexIndex处，最终偏移量=BaseVertexIndex+MinVertexIndex，这里很容易产生误解，就是认为MinVertexIndex是指顶点索引的最小值，即总是0，如果这样那MinVertexIndex这个参数就没有意义了。当初MS如果把这形参声明为OffsetRelativeToBaseVertexIndex应该是更明确一点，不会让人产生误解。  
另一个问题就是，理论上这个偏移量如果是负值也可能是有意义的，例如BaseVertexIndex是1，而MinVertexIndex是-1就是指的顶点缓冲中的第一个顶点，这是有意义的，但实际中如果给MinVertexIndex赋负值我没有试验过。一般情况下MinVertexIndex都是0。  
  
参数4：UINT NumVertices-顶点数量  
MSDN：Number of vertices used during this call. The first vertex is located at index: BaseVertexIndex + MinIndex.  
本次调用所使用的顶点数量。MSDN的解释依然（依旧）模糊，第一个顶点位于BaseVertexIndex + MinIndex这个我已经知道啦，还写这个干什么？这里的顶点数量不是指的顶点缓冲中的顶点总数量，如vb有6个顶点，“The first vertex is located at index: BaseVertexIndex + MinIndex”这句话是要告诉我们，计算顶点数量是要从BaseVertexIndex + MinIndex开始的，例如，我要画一条从顶点index4到顶点index5的线段，那么参数应该是这样的：  
BaseVertexIndex=4

MinVertexIndex=0  
NumVertices=2  
NumVertices是2而不是6，即NumVertices不是顶点总数，而总是你绘制图元实际需要的顶点数，注意这个“实际需要”，指的是你用到了几个顶点，这取决于索引缓冲的绘制这个图形所使用的不同的顶点个数（可能不太好理解，看下面的例子就明白了）。1条线段需要2个顶点，所以就是2，也许这形参声明为NumVerticesUsedForDrawing更明确一些。

参数5：UINT StartIndex-起始索引  
又是一个Index，如果把这个形参声明为StartIndexOfIndexBuffer，我想就不会头晕了，这个起始索引指的是索引缓冲中的起始索引，也就是指索引缓冲数组的下标（顶点缓冲和索引缓冲都是用数组表示）-ib\[StartIndex\]。

参数6：UINT PrimitiveCount-图元数量  
这个没什么难度，有一点要注意，对于绘制的几何图形而言，n-2和n/3指的都是索引的数量而不是顶点的数量，也就是说n是索引缓冲中索引的数量。

好了，所有参数都明确了，现在终于可以自由运用DrawIndexedPrimitive绘制图形了！

先等一下，还有问题，怎么说好呢？DrawIndexedPrimitive这个函数依然存在逻辑陷阱，而这个问题的最大问题就是，虽然你写了有问题的代码，但在HAL设备下没有任何错误提示，编译运行没有任何问题，甚至有可能你的绘制结果和你的预期也是一样的，这个问题只有在REF设备下才能被发现。例如下面的例子：

顶点缓冲如同文章顶部的定义，我要使用vb前4个顶点绘制2个三角形，最后2个顶点绘制1条线段，所以我这样定义索引缓冲

ib=\{0,1,2,0,2,3,4,5,\}，0-5号索引绘制2个三角形，6、7两个索引绘制一条线段

进行编码，

DrawIndexedPrimitive(D3DPT\_TRIANGLELIST,0,0,4,0,2);//绘制2个三角形

DrawIndexedPrimitive(D3DPT\_LINELIST,4,0,2,6,1);//绘制1条线段

先看第一条绘制代码，根据索引缓冲的定义可以知道，前6个索引使用了4个顶点（0,1,2,3），所以NumVertices参数为4，起始索引为0，绘制2个三角形，没有任何问题。再看第二条绘制代码，线段的顶点数据是从vb中的第5个顶点开始的，所以起始顶点索引是4，最小顶点索引为0，使用了2个顶点（4和5）所以NumVertices为2，因为索引缓冲中的线段索引是从第7个索引开始的，所以起始索引是6，绘制1条线段，也没有任何问题。

运行，2个三角形出现了，线段呢？线段怎么没了？显然，第二个条绘制代码不正确，可参数完全是按照规则定义的啊，为什么不正确呢？原因在于，当第一个顶点的位置不是0时，也就是说起始顶点索引+最小顶点索引大于0时，且NumVertices值如果为实际需要的顶点数而不是顶点总数的时候，索引缓冲中对应顶点索引需要减去这个偏移量。回到上面的代码为例，当绘制线段的时候，第一个顶点被移动到了第5个位置（总偏移量为4+0），NumVertices为2是实际需要的顶点数，索引缓冲中的索引从第7（偏移量为6）个开始，对应index4号顶点，而这时index4号顶点对于索引缓冲来说已经不是4了，而是0，同样index5号顶点也不是5而是1，所以需要修改索引缓冲数据。另一种办法是不修改索引缓冲数据，指定总偏移量为0，NumVertices是全部顶点数。正确的代码应该是这样，上面说的有些绕，结合代码就明白了，

修改方法1：

ib=\{0,1,2,0,2,3,0,1,\}//将以前的4、5修改为0、1

DrawIndexedPrimitive(D3DPT\_TRIANGLELIST,0,0,4,0,2);//绘制2个三角形

DrawIndexedPrimitive(D3DPT\_LINELIST,4,0,2,6,1);//绘制1条线段

修改方法2：

ib=\{0,1,2,0,2,3,4,5,\}//保持索引缓冲数据不变

DrawIndexedPrimitive(D3DPT\_TRIANGLELIST,0,0,4,0,2);//绘制2个三角形

DrawIndexedPrimitive(D3DPT\_LINELIST,0,0,5,6,1);//NumVertices修改为顶点总数

上面那段错误代码HAL设备中是无法被触发的（池类型为托管池），在REF设备中会触发内存读写违例。为何HAL无法触发原因不明，可能数据写入显存后硬件会忽略这个错误，必定REF是用来调试的而HAL不是。

本文来自CSDN博客，转载请标明出处：[http://blog.csdn.net/bluekitty/archive/2010/12/10/6068093.aspx][http_blog.csdn.net_bluekitty_archive_2010_12_10_6068093.aspx]

转载于:https://www.cnblogs.com/emyueguang/archive/2011/06/17/2084005.html

[http_blog.csdn.net_bluekitty_archive_2010_12_10_6068093.aspx]: http://blog.csdn.net/bluekitty/archive/2010/12/10/6068093.aspx