When the tessellation shaders are active, we can only render one kind of primitive: the patch (GL_PATCHES). Rendering any other kind of primitive (such as triangles, or lines) while a tessellation shader is active is an error. The patch primitive is an arbitrary chunk of geometry (or any information) that is completely defined by the programmer. It has no geometric interpretation beyond how it is interpreted within the TCS and TES. The number of vertices within the patch primitive is also configurable. The maximum number of vertices per patch is implementation-dependent, and can be queried via the following command:

glGetIntegerv(GL_MAX_PATCH_VERTICES, &maxVerts);

We can define the number of vertices per patch with the following function:

glPatchParameteri( GL_PATCH_VERTICES, numPatchVerts ); 

A very common application of this is when the patch primitive consists of a set of control points that define an interpolated surface or curve (such as a Bezier curve or surface). However, there is no reason why the information within the patch primitive couldn't be used for other purposes.

The patch primitive is never actually rendered; instead, it is used as additional information for the TCS and TES. The primitives that actually make their way further down the pipeline are created by the tessellation primitive generator (TPG), which lies between the TCS and TES. Think of the tessellation-primitive generator as a configurable engine that produces primitives based on a set of standard tessellation algorithms. The TCS and TES have access to the entire input patch, but have fundamentally different responsibilities. The TCS is responsible for:

• setting up the TPG
• defining how the primitives should be generated by the TPG (how many and what algorithm to use)
• producing per-vertex output attributes.

The TES has the job of determining the position (and any other information) of each vertex of the primitives that are produced by the TPG. For example, the TCS might tell the TPG to generate a line strip consisting of 100 line segments, and the TES is responsible for determining the position of each vertex of those 100 line segments. The TES would likely make use of the information within the entire patch primitive in order to do so.

The TCS is executed once for each vertex in a patch, but has access to all vertices of its associated patch. It can compute additional information about the patch and pass it along to the TES using output variables. However, the most important task of the TCS is to tell the TPG how many primitives it should produce. It does this by defining tessellation levels via the gl_TessLevelInner and gl_TessLevelOuter arrays. These arrays define the granularity of the tessellation produced by the TPG.

The TPG generates primitives based on a particular algorithm (quads, isolines, or triangles). Each algorithm produces primitives in a slightly different fashion, and we will see examples of isolines and quads in the recipes in this chapter. Each vertex of the generated primitives is associated with a position in parameter space (u, v, w). Each coordinate of this position is a number that can range from zero to one. This coordinate can be used to evaluate the location of the vertex, often by interpolation of the patch primitive's vertices.

The primitive-generation algorithms produce vertices (and the associated parametric coordinates) in a slightly different fashion. The tessellation algorithms for quads and isolines make use of only the first two parametric coordinates: u and v. The following diagram illustrates the process for an input and output patch consisting of four vertices. In the diagram, the TPG uses the quad tessellation algorithm with the inner and outer tessellation levels set at four:

The TES is executed once for each parameter-space vertex that is generated by the TPG. Somewhat strangely, the TES is actually the shader that defines the algorithm used by the TPG. It does so via its input layout qualifier. As stated earlier, its main responsibility is to determine the position of the vertex (possibly along with other information, such as normal vector and texture coordinate). Typically, the TES uses the parametric coordinate (u,v) provided by the TPG along with the positions of all of the input patch vertices to do so. For example, when drawing a curve, the patch might consists of four vertices, which are the control points for the curve. The TPG would then generate 101 vertices to create a line strip (if the tessellation level was set to 100), and each vertex might have a u coordinate that ranged appropriately between zero and one. The TES would then use that u coordinate along with the positions of the four patch vertices to determine the position of the vertex associated with the shader's execution.

If all of this seems confusing, start with the Tessellating a curve recipe, and work your way through the following recipes.

In the Tessellating a curve recipe, we'll go through a basic example where we use tessellation shaders to draw a Bezier curve with four control points. In the Tessellating a 2D quad recipe, we'll try to understand how the quad tessellation algorithm works by rendering a simple quad and visualizing the triangles produced by the TPG. In the Tessellating a 3D surface recipe, we'll use quad tessellation to render a 3D Bezier surface. Finally, in the Tessellating based on depth recipe, we'll see how the tessellation shaders make it easy to implement level-of-detail (LOD) algorithms.