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.
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.
About the author
#2
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 :)
04/09/2008 (4:05 am)
Hi Rene.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 :)
#3
04/09/2008 (6:43 am)
I started out taking Ves's resource for adding normal mapping to the Atlas terrain, but the cost of FPS can be great on some machines so I have been working on just getting the textures to have really great shading like how WOW does their terrain textures mostly because of what you said above, this led to what I
#4
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.
04/09/2008 (8:36 am)
Interesting stuff, I have been struggling with much the same problems...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.
#5
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
04/09/2008 (9:54 am)
@Bobby: how does WoW do it? I recall reading something about a specular map, but what else do they use? Here is what I got at the moment and there's a lot of room for improvement so all clever tricks are welocme :)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
#6
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.
04/09/2008 (10:32 am)
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.
#7
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
04/09/2008 (10:46 am)
@ReneActually 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
#8
04/09/2008 (10:48 am)
#9
04/09/2008 (10:50 am)
#10
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.
04/09/2008 (11:34 am)
@HenriSorry, 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.
#11
as of TGEA 1.7 you could build cliff pieces or land bridges in Maya and import them as polysoup objects
why can't the displacement data be saved in the alpha channel of the color data.
04/10/2008 (12:44 pm)
@Henri Aalto :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.
#12
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.
04/11/2008 (4:02 pm)
@JamesSorry 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.
#13
04/11/2008 (8:23 pm)
ok
#14
04/12/2008 (10:41 am)
man I hate this system I'm so sick of it eating my posts!
#15
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.
04/12/2008 (11:04 am)
ok we ll the short of what my post was that I don't think that the problems with any of the TGEA terrains be it atlas or mega is the tiling Crysys one of the most advanced engines int he market today has tiling. that they use to get around and give the look of very high fidelity is Decals and spline based roads and paths.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.
#16
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.
04/13/2008 (11:46 am)
Hmm, don't think we agree on this. Just because Crytek managed to get good looks despite tiling doesn't prove the soundness of the approach to me.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.
#17
04/16/2008 (5:43 am)
I don't to I would take tools like th path tool and the decal over having the painted on the surface any day of the week. As for displacement of terrain. I think this is a purely academic exercise. I think that the practicality of it is many years away. But good luck with it.
#18
04/16/2008 (10:27 am)
We'll see :)
#19
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.
04/18/2008 (2:21 pm)
@JamesI'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.
#20
I could not agree more.
I like the way Spore has decided to tackle there terrain system.
04/27/2008 (7:17 pm)
@Rene Damm 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.
Torque Owner Shaderman