![]() However, the set of triangles produced will completely cover theĭomain, and no portion of the domain will be covered by multiple triangles.īased on that paragraph, as well as the entire section of Vulkan's specification dedicated to tessellation, it is my understanding, that there's in fact no guarantee as to how the tessellated patch will be divided and it is in fact implementation-dependent, meaning that the tessellation could possibly be performed differently on different GPUs or even on the same GPU for different Vulkan/driver versions. The algorithm used to subdivide the rectangular domain in (u,v) space into individual triangles is But according to Vulkan's specification ( ): Vulkan spec, chapter 22.7 - Quad Tesselation: ![]() This wouldn't be a problem, if there was any guarantee as to how the subdivision is performed. The resulting mesh could take completely different shapes based on how the subdivision is performed. Therefore, I fail to see how we can get any predictable results when using tessellation if we don't know the way the patch is going to be subdivided into triangles. The effect is even more dramatic for a more complex mesh if we tessellate the patch into many triangles. So already for such a simple case, the way the triangles are generated within the tessellated patch has a huge effect on the resulting geometry. If we perform the split like on the image on the left, the resulting geometry will end up being a sort of trench caving down:Īnd if we perform the split like on the right, we'll get more of a tent shape spiking up, like so: Let's consider, that points v0 and v3 are higher in the 3D space than points v1 and v2. The tessellation may be performed in 2 different ways:ĭepending on the way the quad is split into 2 triangles, the resuling geometry will be completely different (for the same points v0.v3). Let's consider a simple case of Quad Tessellation, where we tessellate a Quad into 2 triangles. ![]() Note that I'm using Vulkan and my issue is relevant specifically to Vulkan (based on Vulkan's specification), but I imagine this might be equally true for other rendering APIs.įor context - the specific case, which I'm considering right now, is generating a terrain mesh by tessellating a quad patch and then offsetting the resulting vertices using a heightmap (classic height-mapping). I'm currently considering using GPU tessellation for terrain rendering using heightmaps (as well as being interested in how tessellation can be used in general for various LOD solutions) and I have an issue with how tessellation works, that makes it seem utterly unpredictable and hence almost unusable for me, unless I misunderstand how it works. I'm working on a 3D renderer/game engine in Vulkan. Hi, this is my first post here, so welcome everyone :)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |