by Aaron » Thu Feb 23, 2017 12:11 pm
Hi HanoGames,
Thanks for the bug report. I've now been able to reproduce this, but have not yet devised a fix (working on it!)
The explanation for the fault is as follows:
When you resize a small heightfield to a very large one (of the order of 16k x 16k pixels or greater), the resizing operation copies the map data from an un-tiled map to a tiled map (tiling is necessary on large map sizes). In this copying process, it appears to drop the calculated min/max values that are stored with the map. Note that the actual pixel values are copied across OK, just the stored min/max values get corrupted. The effect of this fault is that the greyscale display in the 2D view will have the wrong shading (since the palette is determined from min & max), as will any images exported from the heightfield. I think 'proper' map files like HFZ should be unaffected, as they don't rely on the stored min/max values. The other place the min/max values are displayed are in the 'change vertical heightfield range' window, as you have most helpfully observed.
As for why only the 'max' value is getting corrupted here: I think the min & max are both getting re-set to zero, and then when a pixel value is copied across to the resized map, it will re-set the minimum value if it's smaller than 0 (guaranteed, wince all pixels are less than 0 here), but it won't re-set the maximum because no pixels are greater than 0 (hence max stays at default of 0). The same effect would be observed if you had a map that was entirely above sea-level, except that here the minimum would be getting set to zero, instead of the max. This shouldn't be too hard to track down, I hope...
Anyway, the reason the 'average altitude' value changes when you resize the map is because L3DT takes a shortcut in its calculation (averaging billions of pixel values is very slow), and instead calculates the average from the histogram (which is in turn calculated from sub-sampling the heightfield, and is really fast). Back in the depths of time, I seem to have only given the histogram 512 bins, so in your case the 6751m range implies a histogram bin width of ~12 metres. The difference between the average altitude in your first and second screenshots is, by remarkable coincidence, 12 metres also, which means this is a classic 'fencepost error' where the average has tipped out of one histogram bin into another (possibly due to a slight shift in which pixels are measured in the sub-sampling, which is going to happen when a map is resized). Anyhow, the quick-n-dirty fix here is to increase the number of histogram bins to improve the precision (will be 4096 in next version; 8x more precise). To be completely accurate, L3DT would have to actually calculate the average of all map pixels, which would be way slower than calculating an approximate average from a histogram sample. I'll have to have more of a thinker about that.
As for why the heights in the map change when you re-set the max value to the 'correct' altitude, this is because the re-scaling factors are calculated from the old & new min/max values. If the old max value is incorrect (i.e. 0, when it should be -723), then the scaling factor is going to be incorrect too, meaning the height values in the heightfield pixels will go all wrong.
Anyway, please stay tuned, I will post back here when I have a fix ready. Thanks again for the bug report.
Best regards,
Aaron.