ppm Height Map Import - Half Heights

[Sarlock]

Question... I was doing a lot of testing with half heights a year ago and imported an upgraded PPM file that I made to use for one of my SMSC entries (in Oct 2013).  This was imported in to Simutrans and I had a wonderful gradient of over 30 height levels from sea level up to the highest peak.

I imported the same PPM file today with r7338 and it will only import with a gradient of 15 instead of 30.  I tried with RC120.0 and it does the same thing.

I'm not sure what nightly version I had used to import the original PPM in Oct 2013, but it would've been a fairly current one.  I assume that this conversion ability was removed as perhaps it wasn't compatible with existing height maps.

So then the question is: how does one import a height map with the full extent of possible heights (48)?

[DrSuperGood]

I would imagine there being some kind of fidelity setting somewhere that controls how image heights translate into actual map heights. The kind of settings I would imagine are similar to histogram clamp operations followed by some form of translate. These would be the minimum/maximum brightness (or however the images are formatted) and what level that translates to.

If no such settings are provided the logical behaviour would be to automatically find the minimum and maximum brightness levels in the image and assign those to the minimum and maximum height levels that simutrans can produce and then interpolate all the intermediate values based on that. This would sort of be similar to an automatic histogram stretch followed by mapping lowest and highest heights to the lowest and highest possible brightness levels.

If any of the above are not supported by simutrans it might be good to look into adding them as features.

[kierongreen]

Earlier this year I added code to change how maps are imported with half height paks. As such the greyscale levels used are different. These levels are only present in the code there's no setting to control them but if you play around in an image editor you should be able to get them to match.

[Sarlock]

I had made a test height map to determine where the breaks were with the pixel intensities and back when I originally did it, I was able to get all 48 height levels and charted them down (every 5-6 pixels was a height change).

When I import the same map again now with a current version, I only get 24 heights:

Height Test Map

[kierongreen]

Yep - check again with your test map you should be able to get as many levels the colours will just be closer together now if you are using half heights (the idea was that maps would look the same in half height or single height paks)

[Sarlock]

Hmm, still only getting 24 heights on the map (-13 to +10), not the 48 I attained a few months ago.

[kierongreen]

Ok, seems like prissi reverted my code:

Code Select Expand

r7139 | prissi | 2014-04-13 22:41:07 +0100 (Sun, 13 Apr 2014) | 1 line

FIX/ADD: if way under bridges require one or two level clearance is now enforced independently from pak set conversion factor

This revision actually also removed the code for heightmap import as you can see:

Code Select Expand


Index: simworld.cc
===================================================================
--- simworld.cc (revision 7138)
+++ simworld.cc (revision 7139)
@@ -386,7 +386,7 @@
int G = fgetc(file);
int R = fgetc(file);
fgetc(file); // dummy
- h_table[i] = ((env_t::pak_height_conversion_factor*((R*2+G*3+B)/4 - 224)) & 0xFFF0)/16;
+ h_table[i] = (( ((R*2+G*3+B)/4 - 224)) & 0xFFF0)/16;
}
// now read the data
fseek( file, data_offset, SEEK_SET );
@@ -456,7 +456,7 @@
int B = fgetc(file);
int G = fgetc(file);
int R = fgetc(file);
- hfield[x+offset] = ((env_t::pak_height_conversion_factor*((R*2+G*3+B)/4 - 224)) & 0xFFF0)/16;
+ hfield[x+offset] = ((((R*2+G*3+B)/4 - 224)) & 0xFFF0)/16;
}
fseek( file, (4-((w*3)&3))&3, SEEK_CUR ); // skip superfluos bytes at the end of each scanline
}
@@ -519,7 +519,7 @@
int R = fgetc(file);
int G = fgetc(file);
int B = fgetc(file);
- hfield[x+(y*w)] =  ((env_t::pak_height_conversion_factor*((R*2+G*3+B)/4 - 224)) & 0xFFF0)/16;
+ hfield[x+(y*w)] =  ((((R*2+G*3+B)/4 - 224)) & 0xFFF0)/16;
}
}

@@ -2307,10 +2307,10 @@
if(  !gr  ) {
gr = plan->get_boden_in_hoehe( h - 2 );
}
- if(  !gr  &&  env_t::pak_height_conversion_factor == 2  ) {
- gr = plan->get_boden_in_hoehe( h - 2 );
+ if(  !gr  && settings.get_way_height_clearance()==2  ) {
+ gr = plan->get_boden_in_hoehe( h - 3 );
}
- if(  gr  &&  h-gr->get_pos().z + hang_t::max_diff( gr->get_weg_hang() ) < env_t::pak_height_conversion_factor  ) {
+ if(  gr  &&  h-gr->get_pos().z + hang_t::max_diff( gr->get_weg_hang() ) < settings.get_way_height_clearance()  ) {
return "";
}


[Sarlock]

Aha, thanks for finding that.  Good to know that I wasn't going crazy and forgot some important step

[prissi]

It seems I was to overeager in those parts. But what would happen in pak64, where the conversion factor is 1? That would then leave many levels inaccessible?

[kierongreen]

Indeed - however I wanted to maintain compatibility with older pak64 heightmaps. I can't really think of an easy way around this unless we have ways of setting the height scale factor in the gui. The code I added was restricted to pak128/pak128.Britain heightmaps as the look of these paks changed anyway.

[Sarlock]

Hmm... it seems that adding a toggle option on import of the height map to load as a double/half height ppm is likely the only option that works here.

[Sarlock]

I have a new map that I made some time ago that is half height ready (it's a half height version of the same map I released a couple of years ago).  I imported it back a few months ago and it was lovely in half height... hoping to be able to import it again

[prissi]

SHould work in r7343 (please test, as you have the right maps at hand)

[Sarlock]

Both test maps work great, thank you!