Creating a Map from Digital Terrain Data and Google Maps

[Gumboots]

Woohoo!

Nailed it. Took a bit of head scratching, because it's not the way I usually think of doing numbers, but it turns out that the formula behind the blue-green height scale is really simple. Stunningly doofus simple. Your cat could do it.

All it does is start at 0, of course, with an RGB value of 0 0 0.
It then proceeds one step at a time to 0 0 1, then 0 0 2, etc, all the way up to 0 0 255.
Then it starts again, with 0 1 0 taking the place of what would have been 0 0 256 (if the hex scale went that far).
It then goes 0 1 1, 0 1 2, all the way up to 0 1 255, at which point it starts again, at 0 2 0.

So, if you take the position on the scale, which for 0 1 0 is 256, then all you need to do to get the RT3 height value is multiply that by 0.7 and round it down to the nearest integer.

The upper limit is 10,000. That has a hex code of 0 55 206. So its position on the scale is 55(256)+206 = 14,286.
Multiply that by 0.7 and you get 10,000.2 and if you round that down as you normally would anyway you get 10,000.

Taking another example, there's hex code 0 3 127. Its position on the scale is 3(256)+127 = 895.
Multiply that by 0.7 and you get 626.5. I would normally round that up, but RT3 rounds it down, giving a height of 626 units.

This works perfectly for any value between 0 0 0 and 0 55 206. Which is a vast relief, because now I won't have to waste any more time screwing around making patches of colour in Photoshop and loading them into RT3. I can now do the entire humungous beastie via basic arithmetic, which is a lot faster and easier.

Edit: Lolz. Maybe the cat is smarter. I just twigged to how it could be written succinctly.
If you take the green channel value as G, and the blue channel value as B, the formula for finding height value for any value of G or B is:

ROUNDDOWN(0.7*((256*G)+B);0)

in standard spreadsheet syntax.

And another one. Got the formula for greyscale too. That one is even simpler.

Height = ROUNDDOWN(0.7*32*V;0)

where V equals the RGB value (which for greyscale is the same number for all three channels).

Note that this one tops out at 5712 height units, instead of the 10,000 units allowed by the Green-Blue scale.
Also note that all game maps imported from a greyscale heightmap will have a highest point of 5,712 units.

That's just the way greyscale works, and it means importing from a greyscale heightmap will require massively different height modifiers compared to importing from a green-blue scale heightmap. Also note that if you accidentally mix a red ocean with a greyscale heightmap it will multiply all heights by a factor of 8. Which tends to be rather surprising if you're not expecting it.

---

Just found out something. The first series of the blue scale, from 0 0 1 to 0 0 255, work perfectly as long as there is at least one pixel of pure red somewhere on the heightmap. They need that as a reference. If you make a patch of any of those 255 colours, without at least one square of red for a reference of 0, it will result in a height of 0. Not only that, but in the case of pure blue (0 0 255) it will automatically be made into an ocean! Just like as if it was pure red. Go figure.

All the other green-blue colours, from 0 1 0 up to 0 55 206, work perfectly with or without a pixel of red for reference. As soon as there is at least one unit of green, the red is no longer necessary. The obvious catch is that without that reference pixel the heights from 0 to 178 won't be available. This wouldn't matter for a map of an inland area that had a minimum altitude up over 178 anyway, but could be a consideration for low-lying but dry areas. If necessary it would be easy to incorporate just one pixel of red somewhere inconspicuous, and just fill in the divot later (lake tool reset would pull it into place easily).

Anyway, I made a proof of concept tile to see what this stuff is capable of. The TGA was 321x193 and looks like the attached .jpg. The result it generates in RT3 is shown in the screenshot. It's a perfect ramp, on an even gradient of about 1 in 85. No terracing at all. Even slope from top to bottom.

321_ramp_test.jpg (3.37 KiB) Viewed 21230 times

[Gumboots]

Ok, tried a test on an actual map.I started by making a custom elevation table with 5 metre resolution. Cropped a DEM, and exported it at its default resolution (ie: no resizing losses). Turned it into a suitable TGA (513x833) and imported into RT3 editor with an overall height modifier of 4.5. Hey presto, one map. This is an area .231 degrees north to south and 0.207 degree east to west, with a scale of about 52 pixels per mile. IOW, each pixel is about 30 metres (100 feet) square.

This appears to be meshed at around 10 metre height resolution. This is a lot better than the 40 metre resolution we had before, but still not as good as it should be. Since I did the ramp test I know RT3 is capable of utilising all 14,286 possible height values, with height resolution down to 0.7 metres, so I checked the number of colours in the TGA. There are 32 colours.

The maximum elevation in the cropped area is around 280 metres, so there theoretically should be around 55 colours (give or take a few). IOW, the image as exported from MicroDEM only has about half the colour range that it should have. Not sure why at the moment, but will keep investigating. It's obviously some sort of problem with the custom elevation table, and hopefully will not be too hard to track down.

I did check exporting the image from MicroDEM with a few of its standard elevation colour options. These come out with 48 colours, which is about where they should be if resolution is 5 metres.

The game map is attached if anyone wants to check it out.

[Gumboots]

Yay! Got it working.

Turns out that when the MicroDEM help pages helpfully say that elevation .dbf files can have 1,024 values, what that really means in English (or any other language, come to think of it) is that when viewed in OpenOffice or a similar app, the .dbf can have a total of 1,024 cells used for data, and that includes the headings of each of the four columns.

Edit: This is not quite right, because the elevation tables have 5 columns instead of 4 columns. I blame lack of sleep at the time.
However, the key point is the next one, about the limit of 255 heights. Once the header row is taken into account, 255 heights require a total of 256 rows. This is the actual limitation, and equates to 1,280 cells.

IOW, you can have up to 255 heights. If you attempt to enter more heights, what MicroDEM does is drop every second one and do a recount. This is why the previous test turned out to have 10 metre res: that one had 256 heights, so every second value was being dropped. For this test I knocked the upper limit back to 1,250 metres, which reduced the number of heights to 252 (250 for 0 to 1250, plus one for below 0 and one for above 1250) and suddenly they all work just like they should.

This also explains why the old 0-9999.dbf only achieved 40 metre height resolution: it had 1,003 heights plus the one extra line for headers, so 5,020 cells in total. MicroDEM ditched half of the height cells and found there were still 2,013 cells, so ditched half of them again and then found there were only 1,255 cells left. It was happy with 1,255 cells, since that was less than 1,280, but of course by that time it only had 1/4 the resolution it was meant to have. Result: 130 foot tall Lego blocks.

The good news is that it is now clear that my cunning plan of splitting things into a range of sheets, to handle every elevation from 0 up to the peak of Everest in 5 metre slices, will work. And, if you import a heightmap to RT3 and want to tweak some part of it slightly, you will be able to do that with an image editor and a colour picker if the game's editor is making things difficult for you.

Screenshot of the new map:

The exported image has 56 colours. One of those is red for the ocean, leaving 55 for the heights. 55 heights times 5 metres = 275 metres maximum elevation, plus up to another 4.99 before it would bring in another colour, so highest point on the map is somewhere between 275 and 279.99 metres, which is spot on where it should be.

That was made with the same cropped area as the previous test and at the same native DEM resolution, but with an extra 10% on the RT3 overall height modifier. It's still as smooth as silk, even with 0 smoothing applied. Zip is attached, for comparison with the previous one. Doubling the height resolution makes a big difference. I'll get onto making the rest of the .dbf tables so we can cover the rest of the world.

[RulerofRails]

Good work. That one looks very nice. The foot of the hills especially look far better to me than on any typical map.

[Gumboots]

Yup, I think we're on a roll now.

I gave it some more thought before that last test. The RGB scale is based on multiples of 8 anyway (256 possibly values for each channel) so it all works really well if I assign the 5 metre elevation contours in steps of 8 RGB height units. This allows using 8 elevation tables to cover everything from sea level to just past the peak of Mount Everest, with a little bit left over before hitting the game's hard-coded height limit. If some nutter wants to map Everest and then build a hotel on top, this scale would just allow them to get away with it.

It's easy on the brain too. I've attached a spreadsheet to show how it works.

BTW, I'm kicking myself that I didn't figure this stuff out before doing that Latvia map. I could easily have had the heightmap done to 2 metre resolution instead of 40. That would have made those !%@$@ rivers and lakes a lot easier.

[Gumboots]

I made the rest of the tables, and gave them a full testing. They work.

Obviously, the way to test them is with Mount Everest. Aint nothing taller than that. So, I grabbed the DEM for that area and exported 8 BMP images, using one elevation table after another. Stacked the BMP's in Photoshop, knocked out the green pixels, and saved as a TGA heightmap.

Imported that into RT3, and it looks like this...

I've attached the TGA in a zip, so anyone can play with it themselves.

Ok, so how did I make this beastie? I used the new elevation tables which are in the other zip.
They come with a readme file, and you are advised to read it, but I'll describe the procedure in the next post.

Edit: Just for fun, I threw a satellite shot on it.

[Gumboots]

The procedure goes like this:

Due to MicroDEM being limited to 255 heights in every elevation table, each table covers a range of 1,250 metres.
They are all clearly named, so even I can tell which one I want when my brain isn't working.

All of the elevations are done with the usual RT3 colour scale, which looks like blue and black but is actually blue and green.
Red is for oceans, as is also usual for RT3. To get your oceans red:
- right click on the image,
- select Display parameter > Reflectance > Water > Set to red > Ok.

Now switch back to elevation view by:
- right click on the image,
- select Display parameter > Elevation > Color from table > Pick your table >
- then, in the same pop-up > Enable Sea Check > Leave Lake Check disabled > Ok.

The colours to watch out for are yellow, lime green and pure white. These are warnings that you need to do something.
These colours should not be visible in the finished heightmap, or RT3 will do weird things when you import it.
If you want to see RT3 do weird things, go ahead and import it with some of those colours (those pixels will be 10,000 high).

Taking the warning colours in order:

Yellow means the DEM thinks that area is below sea level. It might be, or it might just be an artifact in the DEM. Satellite data is not perfect, and the sea goes up and down, so sometimes a DEM will have pixels registering as below sea level when the area in question is at or above sea level. If you see any yellow pixels when using the 0-1250 table, you should check the area out on a map or a satellite shot and decide what you want to do with it. If you want it as ocean, fill it with red. If you want it as land at sea level, fill it with black.

White means those pixels are at an elevation that is higher than the current elevation table will cover. If you see white pixels, you'll need to also save another BMP with the next table up. You don't have to remove white pixels, because the next layer will cover them.

Green means areas that are below the range covered by the current table. If you see green pixels, you'll also need the next table down (and another BMP).

Once you have all the BMP's you need, stack them up as layers in your image editor and knock out the green pixels with the Magic Wand tool. Make sure that anti-aliasing is not enabled, because if it is the cuts will be furry. No anti-aliasing means you get clean cuts exactly around each pixel. That's what you need for this job.

Once all layers are free of green pixels, you can save the whole thing as your TGA heightmap.

This is the first layer for the Everest heightmap:

Lotsa white there. This means Everest is taller than this (in case anyone didn't know).
So, next layer up...

Lotsa green there, so knock it out with the magic wand and the two layers together will look like this:

Pretty straightforward. Only takes few seconds. Keep going like that until there's no white left. Easy.

[Wolverine@MSU]

Greaat work Gumboots . I especially like the way you've color-coded places that are below the range of the elevation table (green) and those above (white). Makes touching up the stacked BMPs really easy as long as the layers are in the correct order.

[Gumboots]

Glad you like it. I wanted it easy. I don't like playing guessing games.

White means up to most people, since terrain maps usually have white on top of high mountains (for obvious reasons). Green means land, so down. Both are nice and clear against the rest of the heightmap, without burning your eyes out. Yellow stands out well against red, so is good for sea level artifacts. And, most importantly, none of these colours will be used anywhere else in the heightmap, so you can't accidentally knock out pixels you want to keep by selecting any of these colours.

I've run a few other tests with this scale and I think it's a good general purpose one, but I can see specific cases where someone might still want a different scale. Now that we know how to do them, that should still be easy. One detail I did notice is that apparently the elevation .dbf's won't accept fractions of a metre. I did experiment with setting a range for 0-0.1 metres and then 0.1-5 metres (in the hope it would be handy for small artifacts around sea level) but after saving the file and running MicroDEM those decimal values were reverted to 0. So it looks like the smallest range possible is one metre, which is still ludicrously precise for RT3 maps given that DEM data is often out by more than that.

[Gumboots]

I came up with an idea last night. It's one of those ideas that's so obvious in retrospect that I'm wondering why it only just occurred to me.

MciroDEM doesn't just do TGA heightmaps. It's capable of a lot more than that. One of the easy things it will do is make reflectance maps, which are the basis of the terrain shading that is commonly used on terrain maps. These turn out to be very useful, because since they are generated directly from the DEM they match it exactly. This means that if you export one with it zoomed in, so that the exported size is greater than 1024x1024, you can then use it as a guide for positioning and scaling a large composite satellite shot. The advantages here are:

a/ You don't have to guess how it will fit your game map. You can see it right in front of you. This is a very welcome change.

b/ There's no need to worry about exact coordinates to get your satellite shot overlay fitting your game map. As long as the image(s) you start with cover more area than you need to cover, that's good enough. Cut the edges anywhere that's easy.

The current test case is a map of the Darjeeling Himalayan Railway. This was chosen because it's a possible good scenario at some stage, the area has highly complex terrain that provides a good test case, and I already had the DEM for that region anyway. The game map is 448x576 pixels and the area it covers is from 26.60042 North to 27.20042 North, and from 88.09958 East to 88.62042 East.

Why the funny decimal values? Because that's the closest that MicroDEM would get to simple values while giving me the finished map size I wanted. MicroDEM does the cropping by using values of pixels on the DEM, and you just put these at the most convenient values. A basic reflectance map of the area, with standard IHS colours enabled, looks like this:

That's a handy starting point, but it can be tweaked to make it more useful. Desaturating it and then colorizing gives this:

When overlaid on top of the previous image, with layer blending set to Color Burn, you get this:

Which looks a bit lurid, but turns out to be useful. Use the Magic Wand, on a suitable tolerance level, to select the river valleys (blue areas) and ridges (reddish areas). Then "Copy merged" and paste those selections as a new layer. This makes a very good guide for resizing your satellite image. You can just stick the satellite shot underneath the guide layer and then manually resize it, without worrying about any coordinates or other numbers, until it fits the way you want it to fit.

Once you have that sorted, resize the thing to 1024x1024 and save as a BMP. Apply to the game map with bmp2gmp, and you get this:

Which is pretty good for a first stab at it, given the complexity of the area. It's not pixel perfect everywhere. You can find small anomalies if you look for them, but it's close enough to be a very good starting point for further tweaking, and it's a process that is a lot easier on the brain than either guesstimating or trying to calculate it all accurately and hoping it works.

Now for the next step, which I haven't looked into yet but has great potential. MicroDEM will also import stuff other than DEM's, like shapefiles. These can be used for things like this: Polylines of 687 rivers, associated to the basins from the river mouths.

The idea here is that if you can directly overlay accurate river courses onto your DEM, you can obviously export that as an image to your image editor. This will then allow you to colour the rivers with whatever colour fits the elevation you want for the river bed, using the values from the RGB elevations spreadsheet back here.

This method should ensure that you can cut rivers through any terrain at all, at the correct heights, regardless of the game map resolution. It should all be done automatically when you import the heightmap into the RT3 editor.

[Gumboots]

Ok, off to a good start with lakes and rivers too. I tried doing various things with MicroDEM but quite a few functions seem to be buggy. It's still good for heightmaps and relief maps, at least for the moment, but not so good for some other things.

So, I went and grabbed QGIS. Spent a bit of time swearing at the interface, but fairly quickly got a useful result. The same SRTM data that is the basis for the usual DEM's also comes in other datasets, like this - https://dds.cr.usgs.gov/srtm/version2_1/SWBD/ - which is a vector map of just about every lake on the planet, and this - https://hydrosheds.cr.usgs.gov/datadown ... ata=15rivs - which does the same for rivers.

So if you download a bunch of files from those pages and import the shapefiles into QGIS, you can make a nifty overlay for your game map that will contain more information that you'll ever need and will match the DEM projection perfectly. Which would have been handy to know some time back, but nobody ever mentioned it.

Basic example using the heightmap for my Latvia scenario, since it was handy anyway and that area is chockers with lakes and rivers.

[Gumboots]

Ok, here's some more RT3 weirdness.

When I did that ramp test back here, to check out the lowest smooth gradient the game was capable of, I noticed that even though it had a gradient of approximately 1 in 85 the track was shown as being at 0%. So, I decided to run a few tests to see what the game thought various gradients were, compared to what they actually are in terms of in-game mesh. The results are amusing.

Using the same test ramp heightmap, and just playing with the overall height modifier on import, I generated a range of in-game ramps with modifiers varying from 2.6 up to 48.0. Up until 2.6, the game will still show the track as being at 0%. In other words, this supposed 0% track gradient seems to apply to ramps as steep as 1 in 32, in terms of the actual game mesh geometry. That's an actual 3% ramp, still displaying to the player as 0% track.

Track starts getting displayed as a solid 1% at around a height modifier of 8, with a solid 2% kicking in around 16, etc. It looks like the internal calculations are done on the basis that 8 internal height units (which remember are 0.7 of the height units the game displays to you) over the length of one map pixel (the smallest squares visible when laying track) gives you a "track gradient" of "1%" shown in the interface, with the actual gradient of said track being around 8%.

Note that this is still an assumption, because changing ramp height via the overall height modifier on import is not as accurate as changing it directly via the heightmap RGB values. Large modifier values screw things up. Since the original ramp was 1 height unit per map pixel, and was dead smooth, obviously a modifier of 48 should make a smooth ramp of 48 height units per map pixel. It doesn't, though. It gets the top plateau height correct, but the ramp between that and the ocean is badly striated. It's mostly a grade of 6, but grades vary from 1 to 10 in places. At some point I'll probably make a few more RGB ramps to test some of this stuff without having to use height modifiers (IOW, ramps will still be dead smooth) but given the observed results I'm pretty sure the scale suggested is the correct one.

So, in real terms, "0% track" is anything under an actual 1 in 32. "1% track" is about an actual 1 in 12, although with a bit of a range either side of that. "2% track" is about an actual 1 in 6, etc. By the time you're up to "12% track" the actual gradient is near to 45 degrees, which if you check things out in the game is about right.

---

That's today's first lot of weirdness. The second lot of weirdness is the editor's smoothing function. The ramp testing was all done with 0 smoothing, but just to see what would happen I also did a couple of import tests with smoothing values of 1.0 and 2.0. It definitely doesn't do what I would expect it to do. I would expect it to round off the edges of the top plateau, and round off the internal edges between the ramp and the steep sides up to the plateau.

Instead, what it does is only round off one edge of the plateau, and only round off the opposite internal edge between ramp and sides. The other two relevant edges, one edge of the plateau and the ramp-to-side internal edge opposite it, are not smoothed at all and remain angular.

Given this behaviour it is no wonder I've found that the map "smoothing" modifier tends to make a mess of things. I wouldn't trust is as far as I could throw it. It's clearly going to be better to import terrain with a fine resolution (good elevation tables) and a smoothing value of 0, then do any minor route smoothing manually.

[Gumboots]

Been doing a bit more testing. I've found the 5 metre scale is very good for some maps. It works well for small areas done at large scale. For some maps even a 4 metre scale could be handy (ie: setting 8 of RT3's internal height units to be 4 real life metres). For example, a 4 metre scale would have been perfect for the Latvia map I made last year, because it's large and flat and you want some extra detail at low elevations. But minor tweaks to the overall height modifier when importing the heightmap would do just as well in that case (which is what I did when I made it) so a 5 metre scale would have been fine.

OTOH the 5 metre scale is not so good for larger areas that have wide ranges in elevation. The first Mount Everest test model was really too exaggerated at that scale, and looked more realistic with a height modifier of around 0.4 or 0.5. The Orient Express test maps I made the other day were done with the old 0-9999.dbf, which even though it didn't work properly (40 metre Lego blocks) was about right for overall height range on a map of that real life area and in-game pixel size, if imported with the height modifiers left on the default value of 1.

The other thing is areas below sea level. The Dead Sea is the most obvious example, but there are plenty of others: Sea of Galilee at -210 m, Afar Triangle at -150 m, parts of the Netherlands at whatever, central valley of California, etc. Sooner or later somebody is going to want maps of those places too, and they can't use tables that start at sea level. Obvious thing to do: make a few sets of tables in handy ranges, so you can pick whichever ones work best. So I did.

The old monster Lego block table turns out to have been done on an 8 metre scale (ie: 8 of RT3's internal height units = 8 real life metres) or would have been if it had been working properly. That's basically what the RGB values were set for. So I whipped up a general sea level to 10,000 metres table on an 8 metre scale, and another -400 to 9,600 metres table on the same scale for handling the Dead Sea. Ran a test on that one to make sure it works, and it does.

That was done so that the Dead Sea itself was at 0 height for heightmap purposes, so was "ocean" in RT3 terms, with the Mediterranean being a manually-done lake at a nominal 400 metre altitude (the Dead Sea was around -400 metres before 1980, but has dropped a bit since). The same principle would work for any below sea level starting point. You could even just use this set of tables if you weren't worried about having an automatic "ocean", and your central Cali map (for example) could have the Salton Sea added in as a lake (obviously the Pacific would have to be a lake too). I like automatic oceans when I can get them, so personally I'd only use the -400 to 9,600 tables if I really needed to start below sea level.

Anyway I've zipped up both new sets: 0 to 10,000 m, and -400 to 9,600 m, both in 8 metre increments, for anyone who wants to use them. This is not as fine a resolution as the 5 metre tables, but is still 5 times better resolution than the old 0-9999.dbf.

Also included is the TGA heightmap for the Dead Sea test map, if anyone wants to try it out. I found that looked best if imported with an overall height modifier of about 2, since the real life area is quite small and the test map size is quite large. It would obviously be possible to make a set of tables with the same starting point and a 4 metre resolution, but it would mean a/ more tables to mess with and b/ you'd run out of RGB values at +6,743 metres, so no Himalayas.

[FlorianF]

I made the rest of the tables, and gave them a full testing. They work.

Obviously, the way to test them is with Mount Everest. Aint nothing taller than that. So, I grabbed the DEM for that area and exported 8 BMP images, using one elevation table after another. Stacked the BMP's in Photoshop, knocked out the green pixels, and saved as a TGA heightmap.

Imported that into RT3, and it looks like this...


Everest_import_testing.jpg


I've attached the TGA in a zip, so anyone can play with it themselves.

Ok, so how did I make this beastie? I used the new elevation tables which are in the other zip.
They come with a readme file, and you are advised to read it, but I'll describe the procedure in the next post.

Edit: Just for fun, I threw a satellite shot on it.


Everest_satshot.jpg

Wow! Did you actually made this into a map to play? :O

[Gumboots]

No. It was just an obvious test case for proof of concept. I figured if it will handle Everest, it will handle anything.

Edit: By the way, if you want to turn it into a scenario or sandbox I'm happy to give you a copy of the version with the satellite shot.

[Gumboots]

I've been giving this stuff more thought, now that I'm at the stage where finishing eye candy for the NSW map is the next step.

At the intended scale for default RT3 heightmaps, 8 internal units equates to 8 metres (ie: 1 metre per unit) so each click on the up or down tool will change height by 8 metres. Obviously this will change if you use a different height scale. If you use a .dbf set to 8 units = 4 metres (useful for large maps of small areas) then each click will raise or lower that vertex by 4 metres in real life height.

This scale thing could also be useful for checking altitudes of any critical points, perhaps if they have been messed up by a smoothing algorithm. If you know what they are supposed to be (which you can get from Google Earth easily just by hovering over them) then you can use a simple formula to convert that to RT3 game map height (altitude in metres x map scale x .7) and then the relevant vertex or area/lake can be set exactly on the .gmp.

---

The other thing is getting satellite shot overlays to match around nasty geographical details like coasts and rivers. I had an idea here too, which should take all the guesswork out of it. The actual river course on the .gmp will not exactly match real life due to the game's limits, and ditto for coastlines. However, you can get their course on the .gmp quite easily.

You know how many pixels there are on the .gmp, and each section of coast or river exactly follows .gmp pixels, as do oceans and lakes, so these can be transferred to a .psd in Photoshop or .xcf in GIMP. This .psd/.xcf can then be used as a guide for tweaking sat shot overlays so they match the tricky bits. There's no need to load things into the game by trial and error. The whole lot can be done in an image editor, and it can be made to match the .gmp exactly.

This is worth doing, because the resulting .bmp that will be applied to the .gmp is going to give more accurate terrain painting on most maps than trying to paint in the editor. This is because the .bmp will always be 1024x1024, while the terrain painting in the editor follows .gmp pixels. If you have a 512x512 map, the .bmp for the satellite shot will have double the resolution of the .gmp, and will therefore give much better detailing.

So, the way to do it would be to make a reference .psd/.xcf that matches the proportions of the .gmp but is at a larger scale. For a 512x512 .gmp the logical choice would be 1024x1024, which the .bmp can be built straight on top of. All pixel dimensions for coasts and rivers can simply be doubled.

For other sizes of .gmp's it would be easiest to use integers to scale them (because that way pixels still work for placement of features) so for the NSW map it would make sense to scale its 512x448 to 2048x1792. Apply rivers courses and coasts from the .gmp with a simple x4 multiplier. Sort out sat shot to match that. Scale resulting image down to 1024x1024. Apply to .gmp. Sorted.

PS: Obviously this same trick would also work for any other overlays: reflectance maps, terrain contour maps, etc.

[Gumboots]

Hey I just tried something out of curiosity. Greyscale heightmaps get imported with no ocean created, and you can't combine a greyscale heightmap with a red ocean. Well you can, but all heights get multiplied by 8, so it ends up being ridiculous.

Anyway, I remembered how blue behaved on a blue-green heightmap (the standard RT3 scale) if there were no red pixels present (it makes an ocean at 0 altitude) and that got me idly wondering what would happen if you put a blue ocean on a greyscale heightmap.

Turns out that it works perfectly. It automatically creates a zero altitude ocean for you, and it does this without borking the heights of the land vertices. The land gets created at the normal heights for greyscale: if imported at the default 1.0 height modifier the highest point on the map will always be 5,712 internal height units, which will display in the game interface as 3,998.

IOW, whatever height modifiers someone is used to using for any size greyscale map will still work normally, but you get the bonus of automatic oceans. It's easy to do this in MicroDEM by setting the reflectance colour for water to be blue instead of red. The standard ocean check will then add the blue where it's supposed to be, and the rest of the image stays as greyscale, and you just import that to the RT3 editor.

Slight drawback is that it's not as accurate at very low elevations as the blue-green scale, so your coastline will lose some details, but it's still pretty good and would be fine for areas that don't have a complex coastline anyway.

Personally I'll stick with blue-green, but I thought this trick was worth mentioning for anyone who prefers to work with greyscale.

[Gumboots]

Found a way to get sat shots matching coasts and rivers without much effort.

It's still a bit fiddly, and requires some trial and error adjustment to get it all lined up, but results are very good. Eye candy is pretty much sorted. It will still need a little bit of touching up here and there, but it's close straight out of the image editor.

First point: don't use Google Earth for the sat shots. Use this page: https://earthexplorer.usgs.gov/

This has a cylindrical projection which will match your heightmap. Take a succession of screenshots of the area you want, with two shots of each section: one with grid on and one with grid off. These all get grouped in pairs in Photoshop (or GIMP or whatever) and you use the grid to line up all the groups. This is quick and easy in practice. Once they're lined up, merge them into two layers (one with grid, one without). These composite shots are then used to make your final .bmp.

The short version is I got a copy of the heightmap and resized that to 1024x1024. This gets used as a guide for the sat shot. I made several guide layers for different purposes: one had the ocean cut out with the magic wand, then 0% fill applied to that layer and a translucent 3px red outside stroke. What this does is give a clear but see-through guide for aligning the sat shot coast. You can get it spot on everywhere just by eye, with no measuring required.

It's necessary to tile the sat shot in several horizontal strips stacked north to south, just because the projection varies slightly over the latitude range, so trying to do it all with one big sat shot doesn't work as well. I used four strips, each 256 px high on the finished image. The joins between turned out pixel perfect.

To get things lined up east to west, I used copied/pasted some magic wand selections from the heightmap to extra layer. These were obvious things like river bed contours, which can be used to align the sat shot horizontally. It's basically just a matter of stretching and squashing the four strips until they fit everywhere, then saving the whole kaboodle as a 1024x1024 .bmp.

Only catch is that although everything fits, the ocean from the sat shot was too dark around the beaches, etc. To fix that I made three more layers on top of the base layer. Two had the ocean cut off with the magic wand. One of these stayed as the top layer, and the next one underneath was given a 3px Gaussian blur. The third layer under that was given a sandy-coloured drop shadow (angled to match the general run of the coastline). This combo sorts it out so there's a pretty natural gradient from land colour to ocean colour around the edges. After that it's just a matter of sweeping the beaches with a sandy brush in the editor (or a rocky one if you want rocks) to finalise the last bits of odd pixels.

Screenshot shows the result, which has had a few minutes of fiddling with brushes in the editor but is otherwise straight out of Photoshop.

[Gumboots]

Found a fix for the seams that RT3 generates in the bitmap for the terrain.

These appear at multiples of 128 on the map X axis, which is obviously some bug related to processing powers of 2. I'd seen them before (the Latvia map springs to mind) but had never been able to fix them properly. Brushing over the seam doesn't work. No idea why not, but it doesn't.

What does work is selecting a colour from a pixel on one side of the seam, then spot clicking that colour onto the corresponding pixel on the other side of the seam. To drop the colour into place you have to click around the middle of where the map pixel would be, not right against the seam. If you click right against the seam nothing happens. If you move away from the seam slightly, the colour will drop into place with a perfect match across the seam.

It's a bit tedious, but it only has to be done in the worst and most obvious places.

Edit: Thought of something which might be worth testing. I might try applying the same bitmap to a 576x512 version of the same heightmap. I'm curious as to whether the seams will only appear if the X or Y axis is a multiple of 128 (IOW, total axis length = 128, 256, 384, 512, 640, 768, 896, 1024).

The reason I'm wondering about this is the Latvia map was 768x512 and that had seams (will check if they are on both axes, but they were definitely on the X axis 256 multiples) and the NSW map is 512x448, and only has seams on the X axis positions. If the bug is caused by choosing map dimensions that are multiples of 128 that would be good to know.

I've already tested applying the same bitmap directly to the .gmp via hex editing, instead of via Pjay's bmp2gmp tool. That's very easy to do (no harder than using bmp2gmp) but unfortunately it makes no difference to the 256 seams problem. The bug is obviously within RT3 itself, rather than being an artifact of bmp2gmp.

[Gumboots]

Just thought of something, which should have been obvious years ago.

We can't be the first mugs who have wanted satellite shots to match the projection used for DEM's. When you think about it, given that there are tools to put river shapes and all sorts of things on top of DEM's it makes sense that someone would have figured out how to geo-reference satellite shots. So I ran a quick search for "geo-referenced satellite shots" and a lot of useful stuff turns up. There are even tutorials for referencing old maps to whatever projection you want to use.

Georeferencing Satellite Images
Fundamentals of georeferencing a raster dataset
Georeference imagery

This one looks particularly useful:
Download Georeferenced Satellite Images

SAS.Planet is a free application used to view and download satellite images submitted by such services as Google Maps, Bing Maps, Yandex.maps, Yahoo! Maps and many more.

The satellite images can be downloaded and then loaded into OCAD as georeferenced background maps.

As soon as I get time I'll have a play with this stuff. Doing the rivers, etc as shape overlays on DEM's and BMP's is a great labour saver. If we can get a fairly simple process for referencing sat shots to DEM projection as well, that would make map texturing much easier.