The important part is that the hull program can take into account all of the control points when computing the further transformed output control points. After all, we did already transform the control points in the vertex shader. You might be wondering what the point of the hull program is. The hull program is run per control point, but unlike the vertex shader, it can see all of the control points for the entire patch. The patch constant function is responsible for computing data that remains constant over the entire patch. The hull shader consists of two parts: a patch constant function and the hull program. Once all 16 control points have been transformed, the hull shader executes. The same principle holds when using tessellation: the next stage isn't executed until all 16 control points have been transformed by 16 executions of the vertex shader. For example, when using the triangle primitive type, the next stage is run once per every three executions of the vertex shader. When not using tessellation, the next shader stage is executed once the vertex shader has operated on all of the vertices of a single primitive. Similar to the non-patch primitive types, the vertex shader can only see one control point at a time it cannot see all 16 of the control points on the patch. The vertex shader is executed once per control point, and each execution is given one control point worth of data from the input assembler. This buffer is bound to the input assembler as usual. Since we're rendering one patch, we'll need a buffer with 16 points in it - in this context, these points are control points. That is, it's possible to describe a patch with anywhere from 1 to 32 control points.įor the purpose of this example, say we've configured the input assembler to handle patches with 16 control points, and also that we're only rendering one patch. D3D11 adds 32 new primitive types: each represents a patch with a different number of control points. It turns out that it is quite elegant to add new primitive types for patches. Normally, the input assembler can be configured to handle points, lines, line strips, triangles and triangle strips. Input assembler -> Vertex shader -> Hull shader -> Tessellator -> Domain shader -> Pixel shader To solve this problem, D3D11 adds two new programmable stages: the hull shader and the domain shader. The vertex shader by itself isn't particularly well-suited for handling the manipulation of patches we could store the control points in a buffer and index with SV_VertexID, but this is not very efficient especially when dealing with 16+ control points per patch. ![]() Typically, the control points will contain at least positional information, but more likely than not we'd also want to store other things we'd find useful in the programmable shading stages such as color and surface normal data.ĭ3D11 allows us to go beyond three control points per patch. ![]() Think of the line primitive roughly as a patch consisting of two control points, and think of the triangle primitive roughly as a patch consisting of three control points. ![]() To relate control points and patches back to something more familiar, consider the standard primitive types such as lines and triangles. For example, we might define a control point as representing positional and color information. A control point consists of any data we might need during the construction of the curve or surface. A patch consists of an ordered collection of control points that we'll use in the construction of a curve or surface. Say, however, that we wish to process control points and patches instead. The vertex shader is executed once per vertex, and each execution is given one vertex worth of data from the input assembler. Input assembler -> Vertex shader -> Pixel shaderīuffers containing per-vertex data are bound to the input assembler. Consider the typical flow of data through the programmable pipeline:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |