Displacement mapping and terrain rendering

We don't need megabytes upon megabytes of VRAM anyway, even with todays methods. When will people finally realize that heightmaps are old, obsolete, have tons of drawbacks, and look like sh... well, let's say it like this: they are visually unsatisfactory...

Procedural and parametric generation is your friend - high order surfaces, noise, fractals, all that can be done on todays hardware without using too many resources. VS3.0 will help to offload a lot onto the GPU what needs to be done on the CPU right now, but it won't change the fact that everything is still possible now (and has been for some years, btw). People just need to think out of the box sometimes, instead of writing yet another heightmap ROAM/CLOD/C2LOD/Geomipmap renderer... (no offense to all those that have developed such a renderer, of course, you know what I mean [wink])

*sigh*

[Edit] And yeah, of course vertex shaders with texture access will be cool, also for many other effects. Although we can partially do something similar right now, by using fully hardware accelerated render-to-vertex array.

Quote:

Original post by Yann L Procedural and parametric generation is your friend - high order surfaces, noise, fractals, all that can be done on todays hardware without using too many resources.

Please write something about it; last time I read about NURBs, I had no clue how to apply it to terrain [grin]

Quote:

Original post by Promit Quote: Original post by Yann L Procedural and parametric generation is your friend - high order surfaces, noise, fractals, all that can be done on todays hardware without using too many resources. Please write something about it; last time I read about NURBs, I had no clue how to apply it to terrain [grin]

Well, the principle is very simple, actually. NURBS (just as other parametric surfaces) define an arbitrarily smooth surface patch using a set of control points. The terrain is built by attaching several of those patches together, adjusting the control points in such a way, that the generated global surface is smooth and closed. The advantage is that such terrain is fully controllable, has a very small memory footprint, can be both procedurally and manually generated, and doesn't have any constraints on the shape or form (overhangs, caves, concave rocks, everything you can imagine). Each patch is then transformed into a mesh on demand ("tesselated"), and rendered as usual. Since parametric surfaces are basically partially defined continuous mathematic equations, they have a kind of built-in LOD system: dynamic, even anisotropic tesselation. Today, this tesselation is still done on the CPU, but future GPUs will be able to take over such tasks.

The problem with parametric terrain is that in its raw form, it is extremely smooth. That's why you should add local detail once the tesselation is done: mostly by using seeded fractal systems or local surface maps. This has another extremely interesting advantage over heightmaps: a terrain generated according to this principle has infinite details ! Means, the nearer you go with the camera, the more little details will reveal (in my engine, it can go down to 1cm large features, but technically, you could go even further down) without taking additional storage. That's the beauty of controlled fractal systems.

...wow.

Do you have any screenshots?

i googled for paramertic terrain, but little usefull came up.

do you happen to have any links on the subject? id be interested.

Quote:

Why are heightmaps outdated? There's a reason why governmental planetary data sets are represented by heightmaps (think, RADAR). It's just a smooth and elegant way of representing height information - nothing more tho.

outdated, for realistic high-quality terrain rendering in games perhaps? :)
depends on what you want to achieve, but they have many really annoying problems. heightmaps are not an "elegant" way of representing height information, it's just the basic, naive way, with all its drawbacks...

Quote:

You could also use the heightmap for creating a parametric normal mesh.

well, I guess that's the first step in the generation of the control grid ;)
if you've got a control grid that's 4096*4096 or more, I doubt you'll want to place or displace each control point manually, it would be much better to start with a real world heightmap, to get a realistic terrain shape, or whatever, then manually edit / add some control points where you need something more than what the heightmap can give you. for example, add caves...

When I said obsolete, I was obviously talking about heightmaps as intermediate data representation for realistic rendering in video games.

Quote:

Original post by sBibi Quote: You could also use the heightmap for creating a parametric normal mesh. well, I guess that's the first step in the generation of the control grid ;) if you've got a control grid that's 4096*4096 or more, I doubt you'll want to place or displace each control point manually, it would be much better to start with a real world heightmap, to get a realistic terrain shape, or whatever, then manually edit / add some control points where you need something more than what the heightmap can give you. for example, add caves...

That's exactly the idea, unless you want 100% procedural generation. The basic shape of the curve set is either given by a heightmap, by procedural systems, or by hand modelling - most likely a combination of all three. Additional details and terrain features are added by hand, or by dedicated and specialized automatic systems. As an example, we have a module we called "aqua digger" (don't ask ;), that will deform the surfaces according to a fluid dynamic simulation, to create realistic river beds and shorelines for lakes.

Quote:

i googled for paramertic terrain, but little usefull came up. do you happen to have any links on the subject? id be interested.

Not really, unfortunately. There is very little research in that domain. It has been used for offline CG productions, but that's all I know of. Perhaps someone knows about a project using something similar.

Quote:

Do you have any screenshots?

Not here, but I can generate a terrain and capture some.

Well I'm not sure about parametric terrain but the caltech multi-resolution group has some nice publications:

http://www.multires.caltech.edu/pubs/pubs.htm

Quote:

Original post by Anonymous Poster Why are heightmaps outdated? There's a reason why governmental planetary data sets are represented by heightmaps (think, RADAR). It's just a smooth and elegant way of representing height information - nothing more tho. You're not forced to directly use those heightmaps in a terrain renderer, you can derive data structures with an implemented LOD. You can mix static data with fractals for refinement etc. You could also use the heightmap for creating a parametric normal mesh. I mean, in the end, it's just a data format.

Have you ever worked with height maps before? Using a height map with a well-designed CLOD terrain implementation (which, keep in mind, is supposed to be optimized for height map use) results in common visual artifacts where the algorithm just runs out of information to grab from the height map, but can still spare a bunch of extra polys to render data. This tends to result in a weird-ass "stairstep" effect.

Being able to utilize on-demand geometry generation would be a very handy technique as far as outdoor rendering goes. What Yann described can definitely be done on today's hardware and, from what he said, it sounds like someone [Yann] has done it.

At a glance, it doesn't seem like it would be all that complicated to implement either. Sounds like the kind of project that may just get me back into terrain rendering... *cough*

Quote:

Original post by Yann L Well, the principle is very simple, actually. NURBS (just as other parametric surfaces) define an arbitrarily smooth surface patch using a set of control points. The terrain is built by attaching several of those patches together, adjusting the control points in such a way, that the generated global surface is smooth and closed.

How do you adjust these control points "in such a way that the generated global surface is smooth and closed?" I've been thinking about this problem lately, after I read an article in Gamasutra about Bezier patches for terrains, but I just can't work it out.

Quote:

Original post by cragwolf Quote: Original post by Yann L Well, the principle is very simple, actually. NURBS (just as other parametric surfaces) define an arbitrarily smooth surface patch using a set of control points. The terrain is built by attaching several of those patches together, adjusting the control points in such a way, that the generated global surface is smooth and closed. How do you adjust these control points "in such a way that the generated global surface is smooth and closed?" I've been thinking about this problem lately, after I read an article in Gamasutra about Bezier patches for terrains, but I just can't work it out.

The idea is to have the grid of control points in neighboring patches to match up. Say you have a 4x4 grid of control points and you have two of these patches next to each other. If the edges of each of these controls points have the same height, then it is C0 (C zero) continuity. This means that the surfaces will meet here, but not necesarily make a good transition at the patch boundaries.

If you take it a step further, and make the next row in on each of the control points collinear with the other patches corresponding next inner row, then the transition is much smoother and is C1 continuity. Not only do the patches meet but they are much closer to looking like all one patch instead of two different ones. (If you want more info Real Time Rendering section 12.2.5 has good explanation and visuals to help understand)

Quote:

Uhm nice, no linking allowed.

you could post links if you were registered and/or logged in...

Quote:

watch this, and shut up pls :)

oh.. you asked this so kindly...
thanks for sharing with us you wonderful and astonishing arguments.

before I shut up, I'd just like to say that your example isn't a realistic terrain example for games at all.
I've already seen this video, and all the other ones on that site... so what?
I didn't see any caves/overhangs, I didn't see a very high level of detail, considering the dataset size of that demo (5.7Gb uh???), would you seriously find this appropriate for a game?
give me infinite storage, I'll show you infinite detail...

you've still got all the drawbacks of heightmaps, none of the advantages of parametric surfaces / fractal refinement. great...
this kind of things is good for visualisations of finite, precise, static datasets, and that's not my definition of a "realistic high-quality terrain" for games.

Trent referred me to this thread from my original question concerning LOD on parametric surfaces (Here).

Does anyone have any input on LOD with parametric surfaces?

Jason Z

[edit] How the heck do I get a link to work??? [/edit]

There's no such thing as a link tag. Use standard HTML, a href.

I thought I'd seen something about this a few years back, might be relevant:

Clicky.

Quote:

Original post by Jason Z The idea is to have the grid of control points in neighboring patches to match up. Say you have a 4x4 grid of control points and you have two of these patches next to each other. If the edges of each of these controls points have the same height, then it is C0 (C zero) continuity. This means that the surfaces will meet here, but not necesarily make a good transition at the patch boundaries.

Yes, this is the problem I had with it. Although, I wasn't aware of the terminology. :)

Quote:

If you take it a step further, and make the next row in on each of the control points collinear with the other patches corresponding next inner row, then the transition is much smoother and is C1 continuity. Not only do the patches meet but they are much closer to looking like all one patch instead of two different ones. (If you want more info Real Time Rendering section 12.2.5 has good explanation and visuals to help understand)

Aha! Now this makes sense. So C0 is like a continuous function whose first derivative is not neccessarily continuous, while C1 is a continuous function whose first derivative is continuous as well. So I guess that C2 continuity means the second derivative is continuous as well, and so on. Thanks for the explanation.

Quote:

Original post by python_regious I thought I'd seen something about this a few years back, might be relevant: Clicky.

I have read this article before, but I was wondering if anyone had more direct experience with this topic. I personally thought that a continually recalculated patch would have been too expensive, but as the author notes there are several different schemes which can be used. Thanks for the link.

Any further comments?

Jason Z

Question for Yann:

Using your parametric method, how do you handle level of detail? Wouldn't this require updating vertex buffers every time something changes?

Considering the future of terrain rendering, that is huge space, small details, realism, combining water and vegetation etc ... CLOD, fractals, procedural techniques, for me heighmaps are not an evil as such. They could be kept to define the lowest LODs of extremely huge terrains. Higher (medium) details, such as caves can be combined with various production techniques.

I used quasi infinitely precise quadtrees with heightmap patches as nodes. Combined with fractals, the tree had a depth up to 24, thus a huge range of LODs, at min 1mm details, in the end replacing geometry by texture infos, as in a continuum.

Annymous said, "I mean, in the end, it's just a data format". I agree with him. More precisely it's just a particular data format well suited for optimizations exploiting regular steps, straight lines, implicit coords. But to me it's just one component of the global rendering issue, not a central concept. In clear, a heightmap can be seen as a particular case of nurb. I plan to extend my infinite terrain concepts, using nurb patches instead of heightmap patches.

And most of algorithms I used for on the fly fractal/procedural refinement, shadows, lighting, collision detection can be transposed. Instead of having x=k*u, y=k*v, z=f(u,v), each coordinate can use a general (polynomial) parametrization. Sure that patch tesselation will certainly be entirely done by GPUs but any modern CPU could also handle it anyway. The only constraint being that letting the harware tesselate does not cause discontinuities between the patches (cracks).

The challenges will be to combine many technologies into a coherent whole. Various techniques at different LODs, for water, trees, grass, ground, ... Thus even heightmaps might well survive combined with nurbs to save some RAM and CPU/GPU ressources. Yann, here in Auvergne, there aren't as many overhangs and caves as in Brittany.