

#CONSTRUCTION OF TRIANGLE TESSELLATION PATCH#
If no TCS is active in the current program or program pipeline, then the patch data is passed directly from the Vertex Shader invocations to the tessellation primitive generation step. Therefore, for each patch provided by the application, one patch will be provided to the next tessellation stage. However, a TCS cannot discard a patch (directly it can do so indirectly), nor can it write multiple patches. The TCS can change the size of a patch, adding more vertices per-patch or providing fewer. Perform any special transformations on the input patch data.Determine the amount of tessellation that a primitive should have.

The first step of tessellation is the optional invocation of a tessellation control shader (TCS). Main article: Tessellation Control Shader Fortunately, the Post-Transform Cache should help mitigate the performance impact of providing more indices. If you need to do something like triangle strips, you should use Indexed Rendering to get similar behavior, though it will not reduce the number of vertices in the index list. So for a given vertex stream, every group of value number of vertices will be a separate patch. Patch primitives are always a sequence of individual patches there is no such thing as a "patch strip" or "patch loop" or such. The maximum number of patch vertices is implementation-dependent, but will never be less than 32. With GL_PATCH_VERTICES as target and a value which has is on the half-open range [1, GL_MAX_PATCH_VERTICES). Void glPatchParameteri(GLenum pname, GLint value) The number of vertices per patch can be defined on the application-level using: A patch primitive is a general-purpose primitive, where every n vertices is a new patch primitive. Tessellation stages operate on patches, a primitive type denoted by the constant GL_PATCHES. The Tessellation Evaluation Shader (TES) takes the tessellated patch and computes the vertex values for each generated vertex.
#CONSTRUCTION OF TRIANGLE TESSELLATION GENERATOR#
The tessellation primitive generator takes the input patch and subdivides it based on values computed by the TCS or provided as defaults. The TCS is optional default tessellation values can be used if no TCS is provided. Without this protection, gaps and breaks in what are supposed to be contiguous patches can occur. So if you have two adjacent patches that need to have different levels of tessellation, the TCS invocations for the different patches need to use their tessellation controls to ensure that the shared edge(s) between the patches use the same level of tessellation. Therefore, the TCS is primarily responsible for ensuring continuity across patches. The Tessellation Control Shader (TCS) determines how much tessellation to do (it can also adjust the actual patch data, as well as feed additional patch data to later stages). Each stage of the tessellation pipeline performs part of this process.

Generally, the process of tessellation involves subdividing a patch of some type, then computing new vertex values (position, color, texture coordinates, etc.) for each of the vertices generated by this process. They are described below, in the order they are processed. Two of the stages are programmable between them is a fixed function stage. The tessellation process is divided into three stages which form an optional part of Vertex Processing in the rendering pipeline. Note: This describes the OpenGL 4.0 feature, not the old gluTess* tessellation functionality.
