Moving Beyond Fluttering Sheets

Higher-Order Surfaces in DirectX

This book will be released at roughly the same time as DirectX 9.0. Because of that, I have chosen to concentrate on DX8.1 rather than run the risk of talking about DX9 too early. Having said that, it is public knowledge that the higher-order surfaces will not be dramatically different. If you have already moved to DX9, the basic concepts of this section will remain the same, but you should read the DX9 documentation for new features.

In the near future, hardware support for higher-order surfaces will grow to the point where true NURBS or B-spline surfaces might be extremely attractive for many applications. In some cases, the hardware will support much more than simple surface tessellation. Some cards will support adaptive tessellation and displacement mapping.

DirectX supports both triangle and rectangle patches. They will be accelerated in hardware if your hardware supports them. If it does not, you can drop down to the reference device if you want to experiment with them. Both types of patches are defined by two structures, D3DRECTPATCH_INFO and D3DTRIPATCH_INFO . Both structures are defined next .

The offset values are offsets into the vertex buffer. They are explained visually in Figure 11.1.

Figure 11.1: Vertex layout for rectangular patches.

Once these structures are created, you can render the patches with a call to DrawRectPatch or DrawTriPatch .

 HRESULT DrawRectPatch(UINT Handle, CONST float  *pNumSegs  ,                       CONST D3DRECTPATCH_INFO  *pRectPatchInfo  ); HRESULT DrawTriPatch(UINT Handle, CONST float  *pNumSegs  ,                       CONST D3DRECTPATCH_INFO  *pRectPatchInfo  ); 

 

Table 11.1: D3DRECTPATCH_INFO Structure

Member	Data Type	Comments
Basis	D3DBASISTYPE	This parameter defines the type of surface. For example, DirectX 8.1 supports Bezier, B-spline, and interpolated surfaces.
Order	D3DORDERTYPE	This defines the order of the surface. You can choose linear, quadratic, cubic, and quintic. If you want to create a higher-order surface, you will probably have to do it yourself.
Width	UINT	This is the width of the control grid.
Height	UINT	This is the height of the control grid.
Stride	UINT	This is the number of vertices between successive rows of control points. In most cases, this value will be equal to the width value.
StartVertex OffsetWidth	UINT	This is the offset to the first vertex as shown in Figure 11.1.
StartVertex OffsetHeight	UINT	This is the vertical offset to the first vertex as shown in Figure 11.1.

 

Table 11.2: D3DTRIPATCH_INFO Structure

Member	Data Type	Comments
Basis	D3DBASISTYPE	This parameter defines the type of surface. For example, DirectX 8.1 supports Bezier, B-spline, and interpolated surfaces.
Order	D3DORDERTYPE	This defines the order of the surface. You can choose linear, quadratic, cubic, and quintic. If you want to create a higher-order surface, you will probably have to do it yourself.
NumVertices	UINT	This is the number of vertices in the triangle patch.
StartVertex Offset	UINT	This is the offset to the first vertex in the patch.

The Handle parameter of each of these functions provides a mechanism to deal with cached patches. If a patch is dynamic, it is best to call these functions with a handle value of 0. This tells the device not to cache the resulting patch. If the patch is static, you can call the function with a non-zero handle value. The next time you want to draw the same patch, call the function with the same handle value, but specify NULL for the last parameter. This will tell the device to use the cached patch.

The pNumSegs parameter specifies the number of segments in each side of the patch. In the case of rectangle patches, this parameter should be a pointer to a set of four floats. In the case of triangle patches, it should point to three floats. This gives you some control over how the patch is tessellated. Alternatively, you could specify NULL for this parameter and set the D3DRS_PATCHSEGMENTS render state.

These functions will obtain their control points from the current stream source. The current source should be a vertex buffer created with the D3DUSAGE_RTPATCHES flag. This tells the device that the vertices will be used to generate patches. The vertex structure is very simple. You only need to specify the position because everything else will be generated for you.

 struct PATCH_VERTEX {        float x, y, z; }; 

Finally, you must tell the device to generate the proper normal vectors if you want any lighting effects. You can do this by creating a custom vertex shader based on a special vertex declaration. The declaration below tells the device that it must generate vertex normals in addition to vertex positions .

 DWORD Declaration[] = {        D3DVSD_STREAM(0),        D3DVSD_REG(D3DVSDE_POSITION, D3DVSDT_FLOAT3),        D3DVSD_STREAM_TESS(),        D3DVSD_TESSNORMAL(D3DVSDE_POSITION, D3DVSDE_NORMAL),        D3DVSD_END() }; 

If you want, you can also create custom vertex shader code. In this case, I want to use this custom declaration, but I am only interested in the standard fixed-function pipeline. I can create a fixed-function shader that uses a custom declaration with the following line of code. This generates a shader handle that can be used when rendering the patches.

Note 

Tesselation can also apply to texture coordinates and other vertex attributes. See the documentation for a full explanation.

 m_pD3DDevice->CreateVertexShader(Declaration, NULL, &m_ShaderHandle, 0); 

You now have all the basic pieces needed to generate a patch: the information needed to define a patch, a function that can draw one, and the vertex specification. Now, I'll show you how to put it all together.