Evening all,

My quiet spell has almost been broken now as I've spent pretty much all of bank holiday Monday writing up my Direct3D 11 tessellation algorithm for terrain rendering. Probably the most productive day I've had in weeks, which is a little disappointing [headshake]

Anyway, two new YouTube videos for you to check out:

">D3D11 Terrain Tessellation Demo 2 - Solid and

">D3D11 Terrain Tessellation Demo 2 - Debug.

The former video matches up with the

">wireframe video I posted a while back after figuring out what the [partitioning("")] attribute really did. I recommend you check the

">solid rendering out as it is nearly impossible to tell where the geomorphing occurs - watching the silhouette of horizon geometry and/or some shading artefacts are your only clues and they tend to be subtle enough that you wouldn't see it in a 'production' implementation.

I'm genuinely quite impressed at how well the fixed function tessellator works in this case. The only dampener could be if performance of fractional_[odd|even] is somehow significantly worse than integer when hardware finally arrives.

">YouTube video

The above image is more what I wanted to discuss this evening though.

Today I wrote up 17 pages of A4 describing my adaptation of Greg Snook's Interlocking Terrain Tiles algorithm; including various code snippets and diagrams to make it as straight-forward as possible.

For my encore I want to write up an enhancement that I shamelessly 'borrow' from a GDC slidedeck from Nvidia (can't find the link right now). In it they have a single slide indicating that pre-processing with a CS can provide useful weighting for terrain tessellation.

I've yet to work on the actual implementation here but have started to scope it out and decide what I want to do - but more on that in a future journal entry.

For now, the above screenshot (and associated video) were created as my justification for this extension.

Basically, a simple linear mapping of LOD's based on camera distance doesn't work very well at all. The above image takes the inner tesselation factor and shades it red for high detail, green for middle detail and blue for low detail. As you can see, there is little (if any!) red in the image and of the final screen real-estate there are a large number of pixels generated that come from low-detail geometry.

For a given performance budget it is quite clear that the camera distance heuristic does not spend wisely. My current implementation has the Hull Shader determining LOD's and the Domain Shader performing displacement mapping - specifically the Hull Shader has no visibility of the data that actually makes up the final surface!!

I want to put in a CS-based pre-processing step to down-sample the heightmap to a per-tile set of coefficients that allow the Hull Shader constant function to extract more information about the surface it'll eventually end up representing.

If nothing else it means that I can play with the Compute Shader and have a Direct3D 11 sample that exercises every single shader unit available [cool]