by date
Displacement Mapping with Atlas - Part I
Displacement Mapping with Atlas - Part I
| Name: | Rene Damm |  |
|---|---|---|
| Date Posted: | Apr 09, 2008 | |
| Rating: |  4.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Rene Damm |
Blog post
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.
<To be continued>
(*) You can of course do it the other way round which I'm still thinking about. More on that in Part 2.
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.
<To be continued>
(*) You can of course do it the other way round which I'm still thinking about. More on that in Part 2.
Submit your own resources!| Stefan *Shaderman* Greven (Apr 09, 2008 at 09:45 GMT) |
| Henri Aalto (Apr 09, 2008 at 11:05 GMT) |
Your vision sounds interesting, I totally agree with your opinion on the medicority of the terrain in games (I'm aiming for a desert themed terrain so there won't be much foliage to hide the terrain anyway). I think the one crucial element the altas is currently lacking is the ability to import true 3D meshes from modeling applications instead of a mere heightmap, it would allow many nice terrain features. Also, a real UV mapping setup would be needed with such a setup to get rid of the hideously stretching textures. Dynamic lighting / shadows (or at least blending between multiple lightmaps) would also be nice.
I'm currently experimenting with a 2049x2049 (@ 1.0m spacing) terrain using single RGB lightmap and a normal mapping pass for the details. Some of the normal maps are accompanied by an additional diffuse texture for a crispier look. I think this setups has more potential than the regular blended atlas (or the legacy/Megaterrain) in the visual department, though I'm artistically inclined anyway.
The needs of my terrains are within the 2x2km range (for now) so the setup suits me fine. I've kept also the lightmaps small, 2048x2048 or 4096x4096, to keep the atlas-file sizes smaller. As I'm not as fluent in atlas code as you, I'm trying to base my setup on pretty much the standard unique atlas terrain and a modified atlasDetail shader for the normal maps.
Looking forward to Part 2 :)
Edited on Apr 09, 2008 11:07 GMT
| Bobby Leighton (Apr 09, 2008 at 13:43 GMT) |
| Gerard Prudhomme (Apr 09, 2008 at 15:36 GMT) |
One method I have learned about to add variation to Atlas terrains is to colour the light map, that way you get a bit more variation on the terrain textures.
| Henri Aalto (Apr 09, 2008 at 16:54 GMT) |
i177.photobucket.com/albums/w204/hkaalto/FL_red_cliffs_04.jpg
i177.photobucket.com/albums/w204/hkaalto/FL_red_cliffs_05.jpg
i177.photobucket.com/albums/w204/hkaalto/FL_red_cliffs_06.jpg
| Rene Damm (Apr 09, 2008 at 17:32 GMT) |
Thanks for all the kind words. Seems I'm not alone in the quest to add some depth to those maps.
By the way, normal mapping is great, but I want the whole thing. Relief mapping. I don't care if my crappy X1300 stutters along at 0.5 FPS.
@Stefan
Glad to be of service :)
@Henri
Completely agree that Atlas lacks a pure-geometry import option. A mesh importer for Atlas is on my TODO list and may, depending on what my content pipeline will eventually look like, be the next thing after fixing. It won't be much work as most of the stuff is already there in Atlas.
Seems like you are doing some fine work there. Stick to it. You will see some issues with unique textures, but these will hopefully all be fully resolved in the upcoming point update.
Looking at your shots, your textures seem rather blurred to me. Is your texel ratio that low or is Atlas dropping details? I've posted a short section on TDN that helps with LOD dropping and I've put up a fix for miplevel shifting on the Atlas Fixing/Improvement thread.
@Bobby
Your post seems to be cut off :(
Ves's resource unfortunately does away with clipmapping and works off a blended approach. He did great work there, to be sure, but I feel a proper solution for Atlas must embrace clip mapping.
@Gerard
Interesting find. In my case, I won't be going for a separate lightmap but rather bake lighting into the color map. This is acceptable to me as I don't need in-engine relighting. For people that do, the system will have to be extended.
However, in general, I think with Atlas one should move away from in-engine level editing and do the whole thing outside of Torque. Mission editing is a different thing, though.
Edited on Apr 09, 2008 18:31 GMT
| Henri Aalto (Apr 09, 2008 at 17:46 GMT) |
Actually most of the color comes from the relatively low resolution (1 texel per meter) RGB lightmap of the unique atlas and there's a rather smooth normal map applied to the cliffs together with a seaparate diffuse map which is also quite smooth. The ground texture is just a quick mock up with bad scaling. I found smooth textures much more forgiving in artistic sense :D
| Jargon (Apr 09, 2008 at 17:48 GMT) |
Edited on Apr 09, 2008 17:55 GMT
| Jargon (Apr 09, 2008 at 17:50 GMT) |
Edited on Apr 09, 2008 18:00 GMT
| Rene Damm (Apr 09, 2008 at 18:34 GMT) |
Sorry, I spelled your name incorrectly the last time. Just corrected it.
For decent results, you will probably have to go *way* beyond this resolution. I'm curious to hear about your experiences and results.
| James Brad Barnette (Apr 10, 2008 at 19:44 GMT) |
as of TGEA 1.7 you could build cliff pieces or land bridges in Maya and import them as polysoup objects
Quote:
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.
why can't the displacement data be saved in the alpha channel of the color data.
Edited on Apr 10, 2008 19:49 GMT
| Rene Damm (Apr 11, 2008 at 23:02 GMT) |
Sorry for the delay...
The displacement data is a full set of RGBA values. RGB for the normal map and alpha for the depth map. And since the shaders need this data directly, we have to pipe it all the way along the geometry pipeline. That's why it needs two clip maps.
| James Brad Barnette (Apr 12, 2008 at 03:23 GMT) |
| James Brad Barnette (Apr 12, 2008 at 17:41 GMT) |
| James Brad Barnette (Apr 12, 2008 at 18:04 GMT) |
watch the road tool in action here :
youtube.com/watch?v=IEB31hVhU7E
the second thing is decals that allow material to be projected onto surfaces.
youtube.com/watch?v=siH6nWPzveM
This can be used to hide things like stretching and to break up tiling
I think that these things could be added I personally do not have the skill and the only person I know of that has experience with this type of thing is Jeff Faust.
Personally I believe that have these type of things is the only real way to bing the fidelity of TGEA up to par and give us the ability to make the types of games that we all want to make.
Perhaps would could start an effort towards this end. I know jeff has been very helpful in the past and has contributed many feature back to TGEA.
Edited on Apr 12, 2008 18:08 GMT
| Rene Damm (Apr 13, 2008 at 18:46 GMT) |
As I understand, you are an artist. Thinking as such, what do you prefer: being able to just paint your entire model however you want or having to choose from a fixed set of textures and only being able to choose one single direction for each texture and determine where it shows through?
With unique texturing, you as the artist are entirely in control again, free to texture however you want. It isn't so much that it is impossible to create good-looking terrain with blending, but rather that it requires a lot more skill and work.
Also, unique texturing extends to more than just terrains and will probably be something that in future will more and more become the norm for mapping needs in games.
And as a final remark (sorry, James, for the lengthy reply): displacement has very different needs from color. Displacement is almost dependent on unique texturing or you basically restrict yourself to just breaking up the surface a bit. This is why a hybrid approach that does the inverse of what I presented above (displacement unique, color blended) may not be unattractive at all.
| James Brad Barnette (Apr 16, 2008 at 12:43 GMT) |
| Rene Damm (Apr 16, 2008 at 17:27 GMT) |
| Rene Damm (Apr 18, 2008 at 21:21 GMT) |
I've taken a casual look at Crysis and it turns out it is not using a blended approach at all but rather doing unique texturing like Atlas.
| Bill Vee (Apr 28, 2008 at 02:17 GMT) Resource Rating: 5 |
Quote:
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.
I could not agree more.
I like the way Spore has decided to tackle there terrain system.
| Rene Damm (Apr 28, 2008 at 17:35 GMT) |
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!!
| Kevin Rogers (May 06, 2008 at 20:11 GMT) |
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. =)
Edited on May 06, 2008 20:13 GMT
| James Brad Barnette (May 07, 2008 at 14:55 GMT) |
| Rene Damm (May 07, 2008 at 16:49 GMT) |
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 :)
| Kevin Rogers (May 08, 2008 at 18:10 GMT) |
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?
Edited on May 08, 2008 18:17 GMT
| Rene Damm (May 08, 2008 at 19:29 GMT) |
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.
| Kevin Rogers (May 08, 2008 at 23:38 GMT) |
You must be a member and be logged in to either append comments or rate this resource.
