Terrain Megatexture Approach

[ulf.schroeter]

Very interesting article on upcomming Leadwerks engine terrain megatexturing

[Guest shane.ploenges]

Thanks Ulf - Indeed very interesting, it will be good to see this in action.

[demostenes]

Very interesting, 4 texture per chunk limitation is pain in the ass of each artist.

[demostenes]

For example we have 25 channel splat map (for whole terrain) and when importing to unigne, we have to somehow merge these channels into 4. Sometimes it is possible (particular chunk has only 3 channels used), sometimes it is not and we have to manualy sacrifice some channels and do manual tuning/repainting for that chunk. Lots of work and we have "only" 256 chunks in our terrain. Of course all vegetation maps are derived from original 25 channel splat map, so you can imagine, that sacrificing some channels automatically means, that vegetation maps dont fit anymore and it again means manual repainting. Quite tiring process and in case we find out, that original texturing was not good enough, we have to redo it again.

 

This approach described above would solve all these problems (dynamical megatexture generation). We would just provide 25 channel splat and engine will prepare megatexture on the fly. It would mean better visual quality and 100x faster world texturing/vegetating.

[frustum]

This technology has several important drawbacks.

 

* The terrain pixel density is depend on camera position. For Any distant renders (for example viewports) an additional set of textures is required. Moreover we can't even zoom-in into new area of interest without textures regeneration.

 

* The performance impact of drawing six 1024x1024 textures with complex splatting shader is big. And if we need better quality we must use bigger textures like 2048x2048. And each texture require full stack of mipmaps for good visuals.

 

* All textures will be regenerated each frame after some camera movement velocity threshold. So high movement velocity is not available because of performance.

[frustum]

Single FullHD screen is 82MB.

Four 2048x2048 clip textures (diffuse + normal) is 128MB.

We have to shade 1.5 times more pixels on fast movement, generate mipmaps and read them back on rendering pass.

So it will be approximately: 128MB write + (128MB read + ~90MB write) + 82MB read for the each frame ~= 400MB per frame. It is 24GB/s memory throughput for 60FPS.

 

The bad thing that quality of four 2048x2048 clip textures is not enough for good pixel distribution.

 

Splat shading is enabled:

 

Splat shading is disabled:

 

Close view to four 2048x2048 clip textures:

 

Compare pixel density with the splat based shading:

 

The true that we don't generate clip textures each frame. But to keep same visual quality an additional 200MB of video memory is required.

Classic megatexture approach updates clip texture partially and don't utilize mipmaps (mipmapped sampling is emulated in the pixel shader from different clip levels it's an additional performance overhad during rendering).