<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF
	xmlns="http://purl.org/rss/1.0/"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel rdf:about="http://feeds.garagegames.com/rss/blogs/developer/4590/">
		<title>Blog for Rene Damm at GarageGames.com</title>
		<description>Blog feeds for Gamers and Developers in the GarageGames community.</description>
		<link>http://www.garagegames.com/</link>
		<image rdf:resource="http://www.garagegames.com/images/GarageGames_logo_small_w.gif" />
		<dc:date>2008-09-05T23:14:08+00:00</dc:date>
		<items>
			<rdf:Seq>
				<rdf:li rdf:resource="http://www.garagegames.com/blogs/4590/14581"/>
			</rdf:Seq>
		</items>
	</channel>
	<item rdf:about="http://www.garagegames.com/blogs/4590/14581">
		<dc:format>text/html</dc:format>
		<dc:date>2008-04-09T06:24:07+00:00</dc:date>
		<dc:creator>Rene Damm</dc:creator>
		<title>Displacement Mapping with Atlas - Part I</title>
		<link>http://www.garagegames.com/blogs/4590/14581</link>
		<description>Since I have this place, why not just use it...&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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(*).&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;Hooray!  A solution!&lt;br&gt;&lt;br&gt;A solution?  Not really...&lt;br&gt;&lt;br&gt;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!&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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 &amp;quot;Gosh!&amp;quot; feeling that makes you want to linger and take a closer look.&lt;br&gt;&lt;br&gt;&amp;lt;To be continued&amp;gt;&lt;br&gt;&lt;br&gt;(*) You can of course do it the other way round which I'm still thinking about.  More on that in Part 2.</description>
	</item>
</rdf:RDF>
