Cached Recursive Tessellation for High Detail Terrain Rendering



Tessellation enables dynamically producing high levels of detail for geometry, without having to explicitly stream all the triangles needed from the CPU to the GPU. Support for tessellation has become standard in modern hardware. However, the available methods for tessellation have several shortcomings.

First, there are clear limitations on the number of subdivisions that can be modeled with hardware tessellation. For rendering extremely large scenes, like entire planets, the maximal amount of subdivision from a coarse base mesh is simply not enough to support all needed levels of detail. Second, hardware tessellation hinders adaptive behavior within input triangles. Consider large input triangles with displacement maps, e.g., a height field. By default, we cannot define a higher subdivision factor in areas of the triangle where there is a lot of displacement information. Third, if we use standard methods to try and cache/reuse previous tessellation results (e.g., stream-out), the size of the data quickly becomes prohibitively large.

We want to address this issue by making cached tessellation on the GPU fast and effective. The idea for doing so is based on an existing paper:
The fundamental idea there is to encode triangles with a single integer, which makes the tessellation results extremely compact and easy to reuse. The general concept can be realized via vertex, mesh or even compute shaders. As a side effect, an extremely level of subdivision is enabled (up to 2^64). However, while their original solution uses a recursive method for decoding triangles at runtime, we intend to move to a constant-time solution, to get better real-time rendering performance.


  • Familiarize yourself with the paper and existing code base
  • Write and test an application that implements the constant-time en-/decoding
  • (Try to) fix the vagueness in the existing solution regarding T-junctions and cracks
  • Port the developed methods into the existing code base
  • Thoroughly evaluate performance difference of the two methods
  • Ideally, the method can be added to our own in-house planetary renderer


  • Solid C++ programming skills
  • Interest in real-time rendering, GPU programming, basic graphics algorithms
  • Proficient with one of the common rendering APIs (preferably OpenGL)
  • More knowledge is always advantageous


The project should initially be implemented as a standalone application to test and optimize the basic operations of en-/decoding of triangles. Once done, they should be ported and evaluated against the original approach described in the paper. An existing project by the paper authors (OpenGL) can be used as a test bed to compare both versions. See

For inclusion in the planetary renderer, an existing code base is available as well. Porting the working version to this application would provide the perfect use case, since higher subdivision levels (2^30 and more) may be used there.


For more information please contact Bernhard Kerbl (