All of this is statically known at compile time no dynamic run-time buffer management necessary.
#Tessellation graphics Patch
The other nice attribute of Hull Shaders is that, unlike Geometry Shaders, they don't have a variable amount of output data they produce a fixed amount of control points, each which a fixed amount of associated attributes, plus a fixed amount of patch constants. That by itself turns out to be tricky in some places I'll get to that later. All the HW needs to make sure is that it's possible to get watertight meshes, preferably with reasonable efficiency. If you do everything correctly, you'll get a nice watertight mesh, otherwise – well, that's your problem. The hardware doesn't care – it will process each patch by itself. The TFs for the inside of the patch can be chosen freely but if two patches share an edge, they'd better compute the exact same TFs along that edge, or there will be cracks. The basic mechanism is that each patch has multiple tessellation factors (TFs), which are computed in the Hull Shader: one or two for the actual inside of the patch, plus one for each edge. This is a topic all by itself and requires, among other things, great care in the Domain Shader code I'll skip all the details about expression evaluation in shaders and stick with the basics.
The solution – which you've already encountered if you've written a Hull or Domain shader – is to make all of the actual tessellation work purely local and push the burden of ensuring watertightness for the resulting mesh down to the shaders.
0 kommentar(er)
