Hiding seams between heightmap tiles

[woodb3kmaster]

Howdy again, folks! After some reflection and a lengthy trawl through the Middle-Earth DEM thread, I've decided to redo my Askath maps using this tutorial by Pixie and a growing collection of real-world DEMs at ~92-meter resolution (technically 3-arc-second DEMs converted to Mercator, so not necessarily that exact absolute scale). In order to get the level of detail I want, I intend to assemble the new heightfields at this same resolution but process them as 5° x 5° tiles in Wilbur. What I don't know, however (and what I've had no success finding any tutorials or advice on so far), is how I can make the finished heightmap appear seamless with this workflow. What would you folks do if you were in my position?

[Redrobes]

If you have a look at a tutorial I did for making seamless tiles out of anything then I show how a method to make any image seamless - although it works better on some images than another. I said in that you can use this method for 3D objects as well. You can also use the same method on height maps too.

So what we did in MeDem is to take in various mountainous range height maps from such places as the SRTM and make a seamless large expanse of height map mountains. I had to do this in 16bit or float format because as you have noticed with only 8bit greyscale images you get banding.

Once we had a 16 bit mountainous height map texture then we could apply that to high ground areas based on a mountains mask.

Not sure how you might do this with Wilbur tho, Waldronate is the chap to ask about that...

[waldronate]

Erosion is a global problem and you need information across the whole watershed, not just a little piece of it as you would find with a tile.

Doing tile-based operations in Wilbur won't be easy and will be a whole lot of work beyond just the basic Wilbur work. The "erosion" operations in Wilbur happen over the surface in memory and have no way to take into account any information that's not on that surface (e.g. neighboring tiles). Getting usable results with Wilbur requires that you constrain your problem to things that Wilbur can work with. That's probably going to mean that you need 20% or more overlap between neighboring tiles. You probably also want to start with a coarse map that covers your area of interest to get things connected up and then chop up that coarse map into smaller overlapping pieces, paying particular attention to areas with altitude changes (i.e. mountain ranges). Reassembling them would be a matter of fading across edges, ideally with a graphcut and Poisson blending technique (not present in Wilbur).

Always save your work in Wilbur as MDR files if you intend to process them further. The MDR format stores the full 32-bit floating-point internal representation that Wilbur uses in its calculations. Only when you get things to your desired endpoint should you export those files as things like 16-bit DEMs (PNG files work well) to allow blending in programs like Photoshop.

The tool that you really seem to want (which, to the best of my understanding, does not completely exist) is a sort of patch-based texture mapper. You start with your collection of DEMs as input patches. You pick a patch and start painting, rotating and scaling as needed. What the system stores is not the height values, but rather the patch ID and texture coordinates. As you zoom in and out, the system samples the original images to synthesize your heightfield on the fly. For a dedicated terrain system, it would extract information about river and ridge connectivity in the original patches and force these things to match in the synthesized heightfield (see Howard Zhou's article at http://www.howardzzh.com/research/terrain/ ) for an example. At a high level, drawn river definitions and terrain patches would define the overall landscape, with finer details providing points of interest like major mountain peaks and passes. By defining things using input coordinates, the system can synthesize things at any desired level of detail with fidelity up to the detail of the input data and can apply various synthesis techniques to generate some amount of detail beyond that. The primary benefit of a system such as I've described is that it can store a fairly small representation of the world and generate a potentially enormous image piecemeal from that representation and library. For terrain, it can also be retargeted across libraries because the patch coordinates can be easily converted to latitude/longitude values that can be used to index a new library.

[woodb3kmaster]

Thank you both for your advice!

If you have a look at a tutorial I did for making seamless tiles out of anything then I show how a method to make any image seamless - although it works better on some images than another. I said in that you can use this method for 3D objects as well. You can also use the same method on height maps too.

So what we did in MeDem is to take in various mountainous range height maps from such places as the SRTM and make a seamless large expanse of height map mountains. I had to do this in 16bit or float format because as you have noticed with only 8bit greyscale images you get banding.

Once we had a 16 bit mountainous height map texture then we could apply that to high ground areas based on a mountains mask.

Not sure how you might do this with Wilbur tho, Waldronate is the chap to ask about that...

Your work on MeDEM is truly inspirational, and its quality is something I hope to emulate. I noticed that you used a number of your own tools in making it, including some that were previously available for purchase (e.g. GeoTerSys, which seems to have vanished from the Internet, along with the rest of Viewing Ltd's site). I'm sure I'm not the only cartographer who wishes he had such high-quality tools...

Anyway, your point on making seamless textures and applying them with masks is much appreciated, and I'm sure I'll end up doing something similar, what with manually assembling collages proving to be a royal pain. About how big would you say such a texture should be to avoid obvious repetition? I'll likely make several different textures for different mountain range types and rotate some of them to better fit my desired terrain, but at such a large scale, I'm concerned my textures would need to be enormous to prevent obvious repetition. I also wonder how you'd recommend blending the textures into the surrounding terrain, to keep there from being any abrupt edges - maybe something like blurred masks or feathered selections?

Erosion is a global problem and you need information across the whole watershed, not just a little piece of it as you would find with a tile.

Doing tile-based operations in Wilbur won't be easy and will be a whole lot of work beyond just the basic Wilbur work. The "erosion" operations in Wilbur happen over the surface in memory and have no way to take into account any information that's not on that surface (e.g. neighboring tiles). Getting usable results with Wilbur requires that you constrain your problem to things that Wilbur can work with. That's probably going to mean that you need 20% or more overlap between neighboring tiles. You probably also want to start with a coarse map that covers your area of interest to get things connected up and then chop up that coarse map into smaller overlapping pieces, paying particular attention to areas with altitude changes (i.e. mountain ranges). Reassembling them would be a matter of fading across edges, ideally with a graphcut and Poisson blending technique (not present in Wilbur).

Always save your work in Wilbur as MDR files if you intend to process them further. The MDR format stores the full 32-bit floating-point internal representation that Wilbur uses in its calculations. Only when you get things to your desired endpoint should you export those files as things like 16-bit DEMs (PNG files work well) to allow blending in programs like Photoshop.

The tool that you really seem to want (which, to the best of my understanding, does not completely exist) is a sort of patch-based texture mapper. You start with your collection of DEMs as input patches. You pick a patch and start painting, rotating and scaling as needed. What the system stores is not the height values, but rather the patch ID and texture coordinates. As you zoom in and out, the system samples the original images to synthesize your heightfield on the fly. For a dedicated terrain system, it would extract information about river and ridge connectivity in the original patches and force these things to match in the synthesized heightfield (see Howard Zhou's article at http://www.howardzzh.com/research/terrain/ ) for an example. At a high level, drawn river definitions and terrain patches would define the overall landscape, with finer details providing points of interest like major mountain peaks and passes. By defining things using input coordinates, the system can synthesize things at any desired level of detail with fidelity up to the detail of the input data and can apply various synthesis techniques to generate some amount of detail beyond that. The primary benefit of a system such as I've described is that it can store a fairly small representation of the world and generate a potentially enormous image piecemeal from that representation and library. For terrain, it can also be retargeted across libraries because the patch coordinates can be easily converted to latitude/longitude values that can be used to index a new library.

I suppose I should have been more precise in my post - my intended use for Wilbur in the workflow I outlined is really just to apply the kind of global erosion processes I've used it for in the past, especially to hide irregular seams from the collage-building process in Pixie's tutorial. As incredible as it would be if there were a tool like the one you described (especially one that implemented Zhou's research), I'm content to do the more labor-intensive parts of cartography in Photoshop. Your point on using large overlaps between tiles is one I'll definitely use going forward. I wonder, however, if there's any kind of Photoshop plugin or action set that could apply the Poisson blending and graph-cut techniques you mentioned, or if one would have to be made from scratch (or simulated with a lot of labor).

[Redrobes]

...I noticed that you used a number of your own tools in making it, including some that were previously available for purchase (e.g. GeoTerSys, which seems to have vanished from the Internet, along with the rest of Viewing Ltd's site). I'm sure I'm not the only cartographer who wishes he had such high-quality tools...

Anyway, your point on making seamless textures and applying them with masks is much appreciated, and I'm sure I'll end up doing something similar, what with manually assembling collages proving to be a royal pain. About how big would you say such a texture should be to avoid obvious repetition? I'll likely make several different textures for different mountain range types and rotate some of them to better fit my desired terrain, but at such a large scale, I'm concerned my textures would need to be enormous to prevent obvious repetition. I also wonder how you'd recommend blending the textures into the surrounding terrain, to keep there from being any abrupt edges - maybe something like blurred masks or feathered selections?

Yes, MeDem had a whole suite of custom tools made for it. ViewingDale is a 2D mapping tool that does icon / patch / stamp (whatever you call it) based mapping. It was sold and was used to display the top down 2D final map but GeoTerSys was never released or for sale as it is a royal PITA to work with. In terms of MeDem it was used in the process but not very much and not in the bit that were talking about. The custom tools were not released as they were in quite a lot of flux during the time making it. The three tools I used in this particular process were 1) a tool that could slice a large bitmap into tiles with optional overlap, 2) the tool that took overlapped tiles and blended the overlaps back together again and 3) there was a jack of all tools that basically did math on bitmaps.

We used a 40K x 40K bitmap for MeDem but we had a border on it so it was 40960 and we cut it into 40x40 tiles. But for this process we would cut 1536 x 1536 based tiles so that there was 256 pixel overlap on the tiles. Then the processing would take place and then later on the blend tool would take the set of tiles and blend them back into 1024 x 1024 tiles and drop the 256 overlaps. The blend was just a linear ramp. So we did do a little bit of processing on those 1536 based tiles but that was mainly to calculate the tile temperature and vegetation because we had 1600 tiles to process and when it takes 5 mins per tile that adds up a lot. Weeks of processing.

So when we did the mountainous ranges, all we did was make a set of 1536 based tiles stamped down with slices of real mountain height maps and then I wrote a little perl script to whack up 1600 of them by picking them at random and rotating them 0, 90, 180, or 270 degrees at random. Then I used the blend tool to put them all together as the 40K x 40K tile set.

So they were not hydrologically fitting tiles but the 256 border helps mitigate it somewhat. We did not do anything so fancy as poisson blending or wavelet determination etc

Waldronate is perfectly correct in that you need to process stuff happening away from your processing pixel with regard to water flow and erosion. Howard Zhou's work is pretty inspirational and I recall he made a plug in for, I think it was, WorldMachine.

Working with large bitmaps like > 15K is hard work and there comes a point that without a mainframe type machine you will need to use tiles. And with 1600 or whatever of them you need to program the machanism to work with them in some kind of script. We used Gnu Make so that it would work out for itself how much of the processing had been done and then start from the point it got to last time. Since the processing took about 2 weeks on a quad core running multi threaded and flat out, there was no way you could decide half way through it wasnt quite right, make a small change and then have another go. But you could if you told it to process 4 or 9 tiles or so and then have a look and the make system would figure out that all the processes up to the change point dont need redoing.

MeDem was hard. I dont think the bit your trying to do is as hard as the complete process tho. You could fairly quickly make a 10240 pixel square seamless mountain range by blending 5K patches by hand. But 40K or so needs some kind of script based solution and custom programming.

In terms of repetition, most mountain ranges are like lines on a map and so your not going to have large swathes of them to see the repetition pattern I think.

Edit: Have a look at image magick its a script based image processing tool and I know it can work with 16 bit images if you get the right one when downloading it. I think it would be possible to do it using that.