Game Development Community

Displacement Mapping with Atlas - Part I

by Rene Damm · 04/08/2008 (11:24 pm) · 27 comments

Since I have this place, why not just use it...

Be prepared for a brain dump that probably asks a little too much in terms of readability, length, lack of imagery, etc. etc. Also, please be aware that this is not your graphics/game/something guru talking here, but rather just someone doing it for the pure fun in it.

The following are some thoughts (no more than that) on extending Atlas to do normal and relief mapping. Currently, unique texturing still has some issues that need to be ironed out, but once I'm done with that, it's time to spice the whole thing up a little.

Terrains in games traditionally have two distinctive properties: they are flat and they are blurry. You can do away with the latter by drastically increasing texel resolution, but that still does not change the fact that this bunch of stitched together planes has very little in common with its real-world counterpart. You could go the same way as with textures now and drastically increase resolution, but you will end up with exploding dataset sizes that when rendered still lack detail.

Of course, the solution here is no different to what is already being widely used for game models: create a low-res mesh for use in the game, use it to work towards a high-resolution mesh, and finally sample the high-frequency detail, pack the results into a map and then use the map at run-time to do some per-pixel magic.

With terrains, this creates an interesting problem of its own (how to realize a pure-geometry content pipeline that quickly goes into the hundreds of millions of polygons), but I will blog about that another time. The question in this post should be: how can this be realized with terrains.

Taking Atlas, one does not need to think for long to come up with a very straightforward first solution: use two separate unique texture maps, one for color and one for displacement (normal map and depth map for relief). Then just set up two separate clip maps and modify the shaders to use the additional data and do the appropriate mapping technique.

However, aside from some not-so-obvious technicalities, there is a big catch to this: resource usage. In order for the whole thing to look good, you will need to achieve a rather high resolution--for each of the maps. Add to this the cost of maintaining and feeding two separate (reasonably sized) clip maps and it is clear that this solution puts some serious strain on the whole system.

Hmmm, so back to the drawing board and up comes the next solution: do a hybrid! That is, use unique texturing for color maps and blending for displacement(*).

At this point you may throw in: why not just do the whole thing with a purely blended terrain? After all, adding displacement to this can be kicked off by just adding the relevant maps to tiles. Well, it may just be me, but I think blended terrain really sucks. I will come back to this in a minute.

So, in a hybrid solution, we'd still need two clip maps as we can't mix the displacement data into the color data, but at least we'd save plenty of resources with having only one big texture to stream from. The blending data can pretty much reside entirely in RAM all the time.

Hooray! A solution!

A solution? Not really...

Why? Because blending sucks. While with this approach, we get the advantage of unique coloring while at the same time profiting from the excellent resolution-to-resource-consumption ratio of blending, you will quickly notice that there is something awfully wrong with the system: your pavement has a single direction across the entire map!

Imagine doing a road and it makes a turn and the pavement just runs straight on. No good. Unfortunately, that's what you get with blending. Each layer has a single fixed direction that infinitely tiles across the entire terrain. And that's why blending sucks. You need to be really clever and use lots of carefully splatted layers in order to hide the tiling from the player. While it may work with color-only and maybe some bumping, it becomes very restrictive (or very obvious to the player) for displacement.

At this point, I should add another thing: I want terrain that looks good by itself. In most games, the mediocrity of the underlying terrain is hidden under lots of foliage and objects. I want terrain that even with nothing more in the level gives you this "Gosh!" feeling that makes you want to linger and take a closer look.



(*) You can of course do it the other way round which I'm still thinking about. More on that in Part 2.
Page«First 1 2 Next»
#21
04/28/2008 (10:35 am)
@Bill

Spore terrain looks great from a distance and their work on spherical stuff and zooming is just cool. Unfortunately, up close their terrain has the usual washed out looks. Solving that, though, is a rather tough challenge and definitely even more so in a game that goes from far out to close in.

BTW, I absolutely love the work you're doing with Day of War. Keep rocking!!
#22
05/06/2008 (1:11 pm)
Two things I want to point out...
First, Crysis uses parallax mapping, which does a spectacular job of creating surface detail. The first time I got a look at a rocky streambed, I did a double-take, "Whoa, displacement mapping!" Well no, it wasn't, but the parallax mapping is nearly as good; only by getting very close (crouching and prone) did the effect finally fail.

Second, Quake Wars uses John Carmack's Megatexture (similar to Atlas's texturing) to good effect. It provides good performance and decent detail -- roads (curves and all) and cliffs in particular look very nice. Especially since there is little to none of the texture distortion generally associated with terrain rendering.

I guess my take here is: By all means, if you can pull off fast displacement mapping on terrain, go for it! But the key word is "fast". We're at the point where visual effects are good enough. I'd rather see developers focus on creating better, interesting gameplay, i.e. more realistic, detailed interactions with characters and environments, than see effort spent on hyper-realistic visual effects that require 5 GPUs just to get above 30 fps. =)
#23
05/07/2008 (7:55 am)
yeah. personally I see no advantage to having displacement mapping on terrain. Development time would be better spent making things like the path tool and decals on the terrain.
#24
05/07/2008 (9:49 am)
- Mapping Techniques

My current system allows to seamlessly go from normal to parallax to relief mapping. Same data, different rendering paths. That's what I was talking about with "displacement mapping". I should have been more specific here. I don't mean just "true" displacement mapping but rather any of the above three increasingly "truer" displacement mapping techniques.

- Path tool

Hmm, what for?? Any good terrain tool (WM2, GC2) gives you this for free and definitely in a form *way* better than you can ever hope to do inside Torque. And with complete normal+depth information plus unique coloring, you get all the detail to show up in the engine.

- Decals

Agree on that. Better decals would be nice. But IMHO that's anything but an either-or here. It's something that would go nicely with the new system.

- Results please!!

Soonish or so. I'm about 50% done implementing a new multi-channel texturing system for Atlas that completely does away with the unique/blended distinction. Any channel can now be blended, unique, or both (that feature really makes sense only for the diffuse channel). This also includes a new generator that does away with the old chain of console functions and has some nice new features (like e.g. multi-file Atlas maps).

All this is 100% backwards-compatible.

@James
Hehe, James, you are free to use your development time any way you want.

@Kevin
Think you are overestimating the cost of relief-mapping a bit :)
#25
05/08/2008 (11:10 am)
Heh, I did exaggerate a bit, didn't I. But I think you get my point: Visuals need to take a back seat to game-play, not the other way around, as the trend seems to be these days. Especially if the performance cost is exhorbitantly high. If the ratio of perceived visual quality to performance cost is low, i.e. if displacement mapping only looks 5% better but costs 50% more performance-wise, why bother? (Yeah, I'm pulling numbers out of my butt here, but you get where I'm coming from, right? If you can give us some real world numbers that would be huge: Give us frame rates, normal map vs. parallax map vs. displacement map.)

And there seems to be some ambiguity regarding usage of the term "displacement mapping" here. I'm assuming it to mean actual displacement of points in space -- is this what you have in mind or are you using a different technique for "relief mapping"?

EDIT: Oh okay, you're probably doing something like this: www.inf.ufrgs.br/~oliveira/RTM.html. Correct?
#26
05/08/2008 (12:29 pm)
You definitely got me there, Kevin. Though focusing on the visuals at the moment, I agree that gameplay is more important and that it much too often has to take a backseat.

What I am going for is *enabling* high-quality results with Atlas. Atlas is very flexible and the way I'm doing at the moment, you can seamlessly switch between techniques. If performance is too low on your system, you can just flip a switch and you have the whole system running with just texture-mapped terrain using the same identical dataset.

Of course, that leaves the fact that these high-quality datasets somehow have to be created in the first place, but with the right tools that does not place an increased burden on the level creator since it can all be procedurally generated from the low-res data the artist is creating anyway.

The great thing is that all this requires just *one more* additional texture map for terrains which then enables all three aforementioned rendering techniques (normal, parallax, and relief mapping). Each technique is increasingly burdening the GPU, but all are completely optional, i.e. the user just selects what works best on his/her rig.

When talking about "displacement mapping", I meant any technique that applies a heightmap (depth map) to polygons and thus basically turns flat polys into 3D surfaces. Admittedly, that's a rather liberal use of the term and I could/should have just talked about relief-mapping in the title. Also, that definition would sort of make parallax mapping qualify as displacement mapping which it isn't.

I was definitely not talking about micropolygon stuff and such.

As for the link: yep, Oliveira's work is one source I'm basing this stuff on.
#27
05/08/2008 (4:38 pm)
Ok, things are quite a bit clearer now -- thanks for the clarification. Hope to see more, especially when you get to a point where we can see actual comparisons of quality vs performance for each of the techniques. (With screenshots of course.) =)
Page«First 1 2 Next»