Some of the things that it benefits from over the old TerrainSceneManager:
- SceneManager-independent, separate optional component (OGRE_HOME/Components/Terrain)
- Integrates with (optional) Paging component
- Inherently editable - a lot like ETM
- Hierarchical geometry batching; batch counts reduce at lower LODs as well as vertex count. At the lowest level of detail, the entire terrain page is a single batch which has obvious advantages for large paging terrains over the fixed tiles previously used. There's also the opportunity to go to a lower overall resolution and to drop detail geometry in the far distance compared to non-hierarchical approaches.
- Skirts are used instead of stitching to avoid cracks in geometry; this means fewer indexing arrangements & lower overall index buffer usage
- In-built support for splatting layers, configurable sampler inputs and pluggable material generators
- Support for generating global normal maps and light maps in a background thread
- Saving & loading of terrain built in, including loading / processing in a background thread
- LOD now adapts in real-time to camera settings (viewport sizes & LOD bias) so you can use the same terrain with multiple views efficiently
Shots updated 18 June[/edit] You can probably make out the normal mapping and specular mapping there (big rocks are shiny, dirt is not). Parallax mapping isn't in there yet, but is trivial to add. I'm packing diffuse and specular textures into one sampler, and the same with normal/displacement. Shadow mapping and atmospherics are also missing so far, but the lighting is fully dynamic.
The issue I have at the moment is that I've avoided using vertex normals and used a global object-space normal map instead, because when LOD is involved vertex normals produce obvious lighting variations as the geometry simplifies. A global normal map gives 100% consistency at any distance, but the downside is that I have to generate the tangent space basis in the pixel shader. With the normal mapping too, I've found that I can't fit inside the ps_2_0 instruction limit and am currently using ps_2_x. Any modern card will handle this easily of course, but it would be nice to be able to support ps_2_0 too.
I already have to investigate material LOD later, since it's a total waste to be doing normal / parallax mapping all the way to the horizon. My current thought is that I might use the object space normal map for the non-normal mapped distance version, and use per-vertex normals and tangents close up, when tesselation might be stable enough not to be an issue. However, this would make the per-vertex overhead of each terrain page increase by a large amount (currently I just store position, UV and will add optional vertex colour later). So, I may not go down that route and just require ps_2_x or above for full normal mapping.
Obviously we'll have fallback fixed-function options too. And, you can write your own material generators - a deferred render material for example.
It's not ready for prime time yet, but it's getting there. Feel free to play with it (test is PlayPen), but bear in mind it has a number of minor bugs and I'm not finished yet. But, I think it's going to be pretty cool.