Heightmaps and tall mountains - height cutoff

[sjiveru]

Hello! I'm messing around with large heightmaps that have tall and sharp mountains - specifically the USA heightmap available on BaNaNaS. I've cut it in half (I only want the west half), and blown it up with an image editor to 4096x4096.

Unfortunately, OpenTTD seems to really struggle with the mountains. With default settings, the Sierra Nevada is cut off and flat on top - the game does not render anything higher than a certain point. Unintuitively, though, this isn't simply a max height issue, as I can set the max map height to 255 and still get cutoffs in places (many of which apparently aren't even at the max height), and that still causes a lot of the rest of the map to be rescaled upwards and more bumpy than I'd like (eg causing San Francisco to be just a straight peak, and thus annoying to found a city at; or having mountains with bases seemingly too wide).

At the moment, my solution is to rescale the heightmap colour gradient in the GIMP, but this is rather unsatisfactory, as I can't seem to preserve both tall mountains and shortish hills, and getting a reasonable result requires some very good precision defining the rescaling curve (or else I get odd things like foothills starting suddenly, then flattening out, then rising sharply again).

Does anyone have suggestions for ways to cope with this? My goals are:
- No cutoffs (or tiny cutoffs at the highest points)
- Reasonable foothill behaviour
- Not obliterating lower features (I'm happy with a bit of unrealistic scaling where this is concerned)
- Not having lower features problematically sharp thanks to having everything scale up to a huge max height

It may simply be that I need a better rescaling curve in the GIMP, but I'd like to hear if there's an easier solution. It would be nice if I could somehow set the worldgen to not -necessarily- go to the max height, and only go as high as it really needs to. I suspect, though, that I might just have to use a larger map in order to really get what I'd like; but so far, it seems that increasing the map size causes the cutting off to get -worse-.

[Eddi]

IIRC you can set in OpenTTD which height to use as the maximum height for heightmaps (or random maps), so it doesn't try to use the full 255 heightlevels

[kamnet]

I'm going to guess that the problem is that you're starting with a heightmap made from a low resolution source, and cutting and stretching that is just magnifying all of the errors, and then you're dealing with a heightmap that was generated when OpenTTD only used 16 colors to generate maps and now you need it to interpret 256 colors.

There's not going to be a fast or easy solution.

1. You need a higher resolution copy of the SRTM data. This may or may not be possible. It's a good guess that the original data probably came from NASA, but the US State Dept or US Dept. of Agriculture, or even possibly each US state government may have higher resolution data files that they created for their own purposes.

2. You will need to modify the output of the data using a conversion program so that it's exported in 256 color greyscale rather than 16 color.

3. You will need to manually edit each tile in order to correct for errors in order to create a map that meets your expectations.

[Alberth]

Height changes are at most +1/-1 in OpenTTD, so if you have a heightmap with steeper edges, it won't get loaded unharmed in OpenTTD.

[sjiveru]

The cutoffs come in different places with different settings, so I really don't think it's a problem with the heightmap itself - you can get detail up to the top of some peaks with certain max heights, while different max height settings cause those same peaks to be cut off. It does seem like the heightmap uses 256 colours, as well; that's what the GIMP claims of the original I downloaded.

I think Alberth is closer to the issue - it makes sense that if OpenTTD can't handle the speed of the rise, it just gives up after a point. Still, it's surprising to me that that results in flat cutoffs at the top, rather than wider bases at the bottom to compensate (though I think those happen as well). If the mountain was too steep, why would the top be left with a wide flat area? Nonetheless, after a point lower max height settings also cause cutoffs (typically even worse), so even if you try to solve the issue by reducing the speed of the rise, OpenTTD doesn't respond as expected by lowering the target peak height. What's surprising to me is that OpenTTD doesn't seem to be proceeding intuitively with its scaling algorithm. If it simply found the highest and lowest points on the heightmap and set those as max-height and 0, scaling everything else to be inbetween, these cutoffs wouldn't happen, though the mountains might be oddly flat with low settings. Still, it does no good to complain about how things are if that's simply the way they are - I'm sure there's some other good reason for it.

I guess the question is this: is there any way to find the highest point(s) in a heightmap, ensure that that and that alone reaches the set maximum height, and scale everything else between that height and 0? I suppose that might simply boil down to scaling the heightmap colouring itself so that one pixel is at 255/255/255 and everything else is less than that, but I'm not sure I know how to do that in a satisfactory way (that doesn't also ruin the coastline-defining difference between 0/0/0 and 1/1/1). Is there any convenient way to do this in eg the GIMP, or do I just have to brute-force try scaling curves until I find one I'm happy with? Are there any curve shapes I should aim for?

[planetmaker]

I suggest that you let run a median (blur) filter across your input image. Play around with its strength.

I know of no easy method to get the maximum height. As a suggestion : start the height map in arctic climate an set a minimum snow line height slightly below the highest peaks. Iterate, if necessary. That way the peaks become easily visible

[sjiveru]

That seems like a reasonable idea - thank you! I'll try it when I get a chance.