New Terrain Early Shots

[sinbad]

Some of you already know I'm working on a new core terrain system, and it's starting to finally bear some visual fruit.

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

The example material generator will support normal / parallax mapping and specular mapping on all splatting layers, given the appropriate hardware. Provided I can fit it into the instruction limits, we should be able to apply up to 6 layers in one pass in this fashion. Here's some of my early tests (not polished yet, just tech proofs really).
[edit]Shots updated 18 June[/edit]

newterrain_6.jpg (121.04 KiB) Viewed 53985 times

newterrain_7.jpg (135.2 KiB) Viewed 53985 times

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.

[KungFooMasta]

Awesome! I can't believe I'm the first to reply on this thread! As we speak I'm fixing up my project to remove the old terrain solution and start learning how this new system can fit into my framework.

[nikki]

Awesome! I can't believe I'm the first to reply on this thread! As we speak I'm fixing up my project to remove the old terrain solution and start learning how this new system can fit into my framework.

Argh... I saw it before you replied, then I was thinking "I'll reply later, gotta eat.".

Anyway, nice stuff Sinbad! Not much of a terrain guy myself, but I'm sure it'll be useful for many other people.

[spong3bob]

Thats exactly what i was searchin for
cant wait for the first released version..
will there be a limit on how many different materials there can be splatted?

[Praetor]

Looking really good sinbad. I'm just waiting for a signal that this is ready for initial testing I'll try it out. As for your shader problems, I'll direct you here: http://blog.gamedeff.com/?p=78. 8 lights, diffuse, specular, attenuation, normal map with SM2.0. Impressive to say the least. Luckily he chronicles how he does it, and perhaps some of the techniques he has in there you can use to cut down your instruction count.

[Kencho]

Ooooh great!I'm not a terrain-guy either but this is getting me interested

[buckED]

I have been looking for a good terrain solution forever.
This sounds promising. Waiting to see more
Thanks a lot for this great addition.

[Jabberwocky]

Very cool. These are great improvements. I'm looking forward to building some larger terrains than allowed by the old TerrainSceneManager. It will be interesting to see how the batch count helps framerate, particularly on a fully-populated landscape where batch count is a key performance issue. What sort of controls are provided to specify LOD transitions?

Is a "material generator" some c++ code that outputs a material, perhaps generating some shader code based on some kind of config file parameters?

Requiring ps_2_x for normal mapping would be a non-issue for me. I wonder if any card unable to support ps_2_x would have performance issues with a normal mapped terrain anyway.

The paging component is really exciting as well. You've done a great job designing it in such a way that it will be useful for other non-terrain-based scenarios in the future.

[nikki]

Is a "material generator" some c++ code that outputs a material, perhaps generating some shader code based on some kind of config file parameters?

Yup. You could stitch a shader together instead of doing it the '#define's way, for example. Also, often you have to create many materials for each permutation of shaders (Plain, NormalMapping, Shadowed-Plain, Shadowed-NormalMapping, etc.), it could help with that too.

[denreaper]

This is exactly what Ogre3D needs. Most other paging terrain solutions are bloated, buggy, or incomplete.

Awesome job, sinbad!

[sinbad]

Thanks for the feedback.

will there be a limit on how many different materials there can be splatted?

There is theoretically no limit, but it depends on what your material generator has been designed to handle. I'm concentrating on high-quality terrain, so whilst if I was doing basic splatting I could probably do 12 layers in one pass, I can only realistically do 5, maybe 6 with normal/parallax and specular mapping plus shadows. Now, you can of course do more than one pass if you want more, but with my generator I'm shooting for primarily single-pass terrain if I can. This is all changeable with pluggable material generators and you're free to define your own texture layouts if you want.

@praetor: thanks - I have the extra challenge of generating based on the number of actual layers so hand-tweaking is a little more awkward, but I'll see if I can't learn something from that link. I've seen it before but it's always good to review these things.

What sort of controls are provided to specify LOD transitions?

It's a max pixel error metric again - this seems to be the simplest, and of course it automatically adapts based on the viewport size (better than the old TSM did).

Is a "material generator" some c++ code that outputs a material, perhaps generating some shader code based on some kind of config file parameters?

Yes. It's a 2-way thing - the generator is a C++ class which tells the Terrain object what information it needs (normals, light maps), and the terrain tells the generator how many layers there are, and what is in them. The generator also uses a 'profile' class which is sort of like a material technique or material scheme, but higher level because each one can request different types of data. A fixed-function profile might request a fully generated static lightmap for example, whilst a higher end profile would request a global normal map plus use shadow maps instead so it can use dynamic lighting.

Requiring ps_2_x for normal mapping would be a non-issue for me. I wonder if any card unable to support ps_2_x would have performance issues with a normal mapped terrain anyway.

I'm glad you feel that way - I was leaning towards this after I wrote this post, especially as the data overhead for adding normals and tangents to the vertices would not be insignificant for large terrains (and we'd still need the global normal maps for distance anyway). So I'm going to stick with generating the tangent space in the pixel shader, it adds a fixed overhead to the pixel shader but it actually runs really well (see the frame rates in the shots, on a 9800 GX2), and each layer doesn't add too much more cost.

[DanielSefton]

I've been closely following every commit - seeing a screenshot is refreshing. This is going to be a massive boost for my project, which requires gigantic terrains.

Using PLSM I noticed that it has quite a performance hit (high batch count oddly) - that's even without any material stuff. I'm shocked seeing your ~20 batch count! Also the obvious fact that it's difficult to get the terrain surface looking good with PLSM, and PSSM shadowing is a royal nightmare.

I'm watching MyRiddin's plugin too, but it's obvious that your approaches are more efficient. I guess the main difference is the extra shaders. We're going to be spoilt for choice soon.

It's as good as I can get it looking with PLSM; bring on normal mapping.

[jacmoe]

I saw the Ogre development tweets about shiny rocks (and waxed grass) - I've been expecting some screen shots!

It looks far better than I could have imagined!
Say hello to details.

I love your work, Sinbad. Really looking forward to using it.
And greetings to the contractor, making it possible.

[Nauk]

AhaaaAa... Getting somewhere, looks very good this far Is this the latest SVN in the screenshots or still a private version?

@DanielSefton: Very nice screenshot

[trilobite]

Sinbad, your new terrain system is going to be be a huge step forward for Ogre. We are all hungry like wolves for meaningful progress in the Ogre terrain department.

Beauty is one thing, physics is another. A big question of mine is how to get existing physics (OgreNewt, for example) to shadow and match dynamically rendered terrain. (Is this the solution nVidia is seeking by "integrating" PhysX?)
Or, will this new terrain rendering system simplify physics integration? (Now I'm really dreaming.)
Or, will existing physics (OgreNewt, OgreOde, nxOgre, OgreBullet) need to be modified in order to work with this beautiful terrain renderer?
Or, will we be needing a whole new kind of physics model altogether?

Thankful so many creative people are involved here...

[mikeInside]

I've got nothing original to say, but I would like to echo the following sentiments:

This is going to be a massive boost for my project

seeing a screenshot is refreshing.

Looking really good sinbad. I'm just waiting for a signal that this is ready for initial testing & I'll try it out.

This is exactly what Ogre3D needs

And greetings to the contractor, making it possible.

Awesome job, sinbad!

[koirat]

Great job.
This is a good news to me.

You could just add nicer textures to better advertise your work (my 5 cents)

[stealth977]

Well, its great job

I think the screenshots are from your private demo since the Playpen test doesnt show normal maps etc (PS 3.0 here)...

I already implemented a test class CPagedTerrainEditor in the new framework of Ogitor, will keep you updated about the problems i come across (already posted the first problems as PM)

Anyway it was nice seeing it in Ogitor, gives energy to implement more of it

ismail,

[sinbad]

Beauty is one thing, physics is another. A big question of mine is how to get existing physics (OgreNewt, for example) to shadow and match dynamically rendered terrain. (Is this the solution nVidia is seeking by "integrating" PhysX?)
Or, will this new terrain rendering system simplify physics integration? (Now I'm really dreaming.)
Or, will existing physics (OgreNewt, OgreOde, nxOgre, OgreBullet) need to be modified in order to work with this beautiful terrain renderer?
Or, will we be needing a whole new kind of physics model altogether?

I've (I think) made it easy to extract the data you need from the terrain geometry in order to build physics objects from it. At the end of the day the terrain is one big patch of triangle strips, which I just split up to fit within 16-bit index limits (for efficiency and compatibility) and batch up based on an internal quadtree. You can extract all this information from the terrain page so physics integration is doable. You can also perform height queries and ray tests using the internal calculations.

I think the screenshots are from your private demo since the Playpen test doesnt show normal maps etc (PS 3.0 here)...

Nope, this is the PlayPen demo. But as I say, all WIP, there may be hardware incompatibilities yet (and GL needs fixing which I'll be doing today). I'm only testing this so far on a GeForce 9800 GX2 right now.

[sinbad]

Using PLSM I noticed that it has quite a performance hit (high batch count oddly) - that's even without any material stuff. I'm shocked seeing your ~20 batch count!

That's slightly contrived because the shots were taken to show the normal mapping rather than the distance rendering, which currently looks a bit dull because of the lack of atmospherics and some obvious texture tiling (which will be reduced using a separate global colour map later - I was going to use vertex colours but thinking about it that will look crap with the LOD just like vertex normals would).

However, even though that's contrived the worst case scenario on this terrain is about 40 batches when you're close up (although that includes the overlay and skybox too, which account for 10 ish). As you get further away it drops off, theoretically to 1 batch eventually if you let it get far enough away, but I expect mid-distance pages will sit at around 4-12 batches each which isn't too bad.

Batching is also highly configurable, since you set a 'min batch size' and 'max batch size'. These 2 metrics determine how much the terrain is split up. A batch is any patch of triangles at a hierarchy level. The leaves of the quadtree that represents the hierarchy can range from the maximum batch size, to the minimum batch size at their lowest LOD, and then after that 4 adjacent patches at the min batch count get grouped into one parent patch at the min batch size to drop LOD. So, a large difference between the min and max batch size gives you more LOD levels at lowest level of the quad tree, so more flexibility in LOD picking (because each low-level patch can make its own LOD decision - when moving up the tree all 4 patches have to agree that it's time to drop LOD for it to happen), but at the expense of less efficient batching. You can tweak the absolute and relative values of these batch sizes to get the balance you need between vertex count and batch count.

I'm not sure if this is a 'new' technique at all but I couldn't find any good papers on doing it like this, so I wasn't sure how well it was going to work. It seems to be working out well though.

[sinbad]

You could just add nicer textures to better advertise your work (my 5 cents)

Hmm, these were what I consdered 'nicer' textures to demo this, they're from the NVidia texture library and I generated normal/height and specular maps for them. But, I realised I screwed up the lighting calculation and my ambient was washing out the diffuse somewhat so they didn't look as nice as they should. Here's a better shot:

newterrain_4.jpg (134.13 KiB) Viewed 54418 times

I need to get more interesting fading between the layers rather than the smooth fade here, but it's programmer art and generated in code (generating the blend map via a simple height-based fade) Hopefully you'll be able to get better results when editors start using it.

[bishopnator]

Hi, it looks awesome ) I am working on heightmap rendering in our product (golfblaster3d). Unfortunately I can't share source codes but I want share some ideas

1. reducing draw calls
It is possible to improve performance by batching lower LODs to singe draw call. I prepared "special" vertex buffer which contains same terrain block copied multiple times. For example for lowest LOD vertex buffer contains 4 vertices per block. Number of blocks depends on number of contant register which can be used for shader instancing. Each vertex contains except basic parameters (position - without height (just xz), uv, ...) also instance index and vertex index. Vertex shader has "special" input parameters - array of data for instances (transformation), array of heights). If in camera there are visible 20 blocks in lowest LOD and shader supports 40 instances, all blocks can be rendered by single draw call.

Sample shader (from my implementation):

Code: Select all

VS_OUTPUT  main_ver1_vp(VS_INPUT i,
                   uniform float4x4 worldViewProjMatrix : register(c0),
                   uniform float4 vInstancePos[40] : register(c4),
                   uniform float4 vInstanceHeight[205] : register(c45))
{
	VS_OUTPUT o = (VS_OUTPUT) 0;
  
	// compute world position
	o.vPos.xz = i.vPos.xy + vInstancePos[i.vInstanceData.x].xy;
  
	// packed heightmap data
	o.vPos.y  = vInstanceHeight[i.vInstanceData.y].x;
	o.vPos.w = 1.0f;
  
	// transform the position 
	o.vPos = mul(worldViewProjMatrix, o.vPos);
		
	// pass texture coord
	o.vUVColorMap = i.vUVColorMap + vInstancePos[i.vInstanceData.x].zw;

	return o;
}

This approach can be applied also to lower lods - it depends only on amount of vertices in blocks. My shader needs only 4 registers for transformation matrix. Using vs_2_0 model it is possible to use 256 constant registers. These regs must be splitted to heights array and array with transformation for instances. Equation for computing number of instances supported by shader: N = 252 / (V + 1) where V is number of vertices per block in given LOD.
LOD0 (lowest) needs 4 vertices per instance, N = 50
LOD1 needs 9 vertices; N = 25
LOD2 needs 25 vertices; N = 10
etc.

As you can see, only one float from heights registers is used in shader - using other components (yzw) significantly increases number of supported instances per shader. If each vertex contains also index of component (0-3), than it is possible to set correct height value in vertex shader.

Code: Select all

  // compute world position
  o.vPos.xz = i.vPos.xy + vInstancePos[i.vInstanceData.x].xy;
  
  // packed heightmap data
  if(i.vInstanceData.z == 0) {
    o.vPos.y  = vInstanceHeight[i.vInstanceData.y].x;
  } else if(i.vInstanceData.z == 1) {
    o.vPos.y  = vInstanceHeight[i.vInstanceData.y].y;
  } else if(i.vInstanceData.z == 2) {
    o.vPos.y  = vInstanceHeight[i.vInstanceData.y].z;
  } else {
    o.vPos.y  = vInstanceHeight[i.vInstanceData.y].w;
  }
  o.vPos.w = 1.0f;

With this modification it is possible to draw up to 252/2 = 126 terrain blocks in lowest LOD in single draw call (1 reg is used for instanced data (block's transformation) and 2nd reg contains all 4 heights for vertices). In my implementation I created 4 different versions of vertex shader - 1st uses only 'x' component from register for heigths, 2nd uses 'xy', etc. because adding 'if' conditions to shader adds a lot of instruction to compiled asm shader. Vertex shader type used for rendering is determine only by amount of visible terrain blocks which can be batched using this technique.

2. material LOD
It is nothing special ) I just rendered whole terrain into single 4096x4096 texture (or in maximum supported size) and switch pixel shader for further blocks. It reduces splatting / paralax mapping / normal mapping on whole terrain. Our shaders are not very fast and this approach significantly improved fps because these slow shaders are used only in short distance around camera.

3. memory reduction
I existing TerrainSceneManager vertices contains XYZ (floats), UV, normal, etc. (maybe some componets are optional, but it is not important). Using floats are really not very efficient. I am using following vertex format which I think it is sufficient for most implementations:

Code: Select all

struct VS_INPUT
{
  short2 pos    : POSITION;     // xz coord
  float  height : TEXCOORD0; // y coord
};

Vertex shader than accept 4 floats for transforming grid position to world position:

Code: Select all

uniform float4 vTerrainBox - xy = offset, zw = square size

float4 world_pos;
world_pos.x = vTerrainBox.x + i.pos.x * vTerrainBox.z;
world_pos.y = i.height;
world_pos.z = vTerrainBox.y + i.pos.y * vTerrainBox.w;
world_pos.w = 1.0f;

UV for mapping textures can be computed also in vertex shader from vertex's world position:

Code: Select all

float2 computeUV(float2 worldPosXZ, float4 vOffsetTilingColor)
{
  float x = (worldPosXZ.x - vOffsetTilingColor.x) / vOffsetTilingColor.z;
  float y = (worldPosXZ.y - vOffsetTilingColor.y) / vOffsetTilingColor.w;
  return float2(x, y);
}

If you want only planar texture mapping this is enough - it is not necessary to get UV from vertex buffer. So classic vertex (XYZ and one UV = 20 bytes per vertex) can be reduced to 8 bytes.

[stealth977]

I wanted to post the first screenshot of the OgreTerrain (except the creators screenshot)

ogreterrain.png (201.77 KiB) Viewed 54327 times

BTW, the FPS is at DEBUG build, and i am on a laptop with a not so decent GPU!!!!

ismail,

[sinbad]

@bishopnator: thanks for the ideas. The instancing could be tricky with the batching I'm already doing but I'll certainly think about it.

Better vertex compression is definitely on my list of early enhancements. I'm still passing a single UV because it was easy, but I already multiply it out by a per-layer scaling to allow different tiling levels per splat layer so parameterising if from world position would be fine too.

@stealth977: good to see in another application Your washed out textures will be fixed if you update from SVN though.

[AshMcConnell]

Looks fantastic Sinbad, keep up the good work!
All the best,
Ash