Enlarge maximum map height

[sanderd17]

Yesterday, there was another complaint about how our maps are limited in height (see http://wildfiregames.com/forum/index.php?showtopic=19727 )

So, as the maps from A18 aren't compatible with the maps from SVN now anyway, I though it might be a good time to change that limit.

The easiest way to alter the maximal height is by altering the precision. The height is encoded in 16 bits for every map point, and you can use more bits for precision, or more bits for a bigger reach. That way, the height stays stored as 16 bits, and it won't alter the performance.

In the current situation, the maximum height is 89.5 meters, and the precision is around 1.4 milimeter. So I don't think that I need to explain there's room for lesser precision and a bigger reach.

The best way to handle this would be to multiply both with a power of 2. That way, the change boils down to shifting a few bits, and we won't run into strange rounding problems.

The drawback of this change is that it will break all current maps, but I made a simple script that should convert your map from the old A18 format to the new format (whichever scale is chosen).

So my question to the mapmakers is, what factor would you like?
Here's a small summary of to what values different factors would lead.

• factor 1: precision = 1.4 mm, max height = 89.5 m (current situation)
• factor 2: precision = 2.7 mm, max height = 179 m
• factor 4: precision = 5.5 mm, max height = 358 m
• factor 8: precision = 10.9 mm, max height = 712 m
  

Currently, there are a number of maps in our repo that almost hit the maximum height, so where it's not possible to make tops higher, or add hills on certain plateaus. One of these examples is Death Canyon (you can easily try to add a hill on the plateau).

This is an example of how high you could go on Death Canyon with a factor 4: http://i.imgur.com/QdpsAWv.jpg

For more technical information, or to test some stuff (testing would need manual compilation), you can take a look at the ticket: http://trac.wildfiregames.com/ticket/3112

I think factor 4 would be a good value (still precise enough, and have a reach that's probably good enough for all use cases), but I'd like your opinion on it too.

[Skhorn]

Nice!! Thank you for posting this Sander

I'm for the factor 4, but i think for experimental purposes the factor 8 will be good, will try that this night.

Thought it was more complicated than multiply it by a power of 2.

Edited March 20, 2015 by Skhorn

[feneur]

Would be interesting to find out where the precision becomes an issue. Or how for that matter, maybe someone can take a screenshot with it set really low so one can get an idea of what would happen

[WhiteTreePaladin]

A factor of 2 would be good for me. I do worry what the loss of precision will do beyond 2x.

[sanderd17]

I don't think lack of precision will be noticeable at factor 8 already (I didn't notice it in Atlas at least). At factor 8 it's precise to around 1cm, which is still better than real-life measurements of many soil types (certainly natural ground). But indeed, if you exaggerate with the factor, you can get to a point where it does matter.

@Erik, not sure what sort of screenshot you really want.

[WhiteTreePaladin]

Sorry, I read millimeter as meter, so I thought the precision would go from around 1 meter to 10 meters. That didn't seem acceptable. A centimeter isn't too bad at all. Still, 8x seems like overkill unless we are planning much larger maps in the future.

[leper]

Since we're planning on breaking compatibility here I don't see any point for going with anything less than factor 8. 1.1 cm is still way too precise for what we do IMO, but is already a huge improvement.

[agentx]

I wonder whether the existing textures look better on very steep, almost vertical map features with this proposal.

[FeXoR]

I definitely agree on this. Factor 8 sounds good.

Related post (and topc in general): http://wildfiregames.com/forum/index.php?showtopic=17809#entry278244

(Not sure the wording is appropriate as well as the numbers)

While we're at it:

- It would be nice to remove all hardcoded unit parameters from RMGEN and have the engine give those parameters to RMGEN at start - namely:

CELL_SIZE (4, size of a terrain tile in meters)

HEIGHT_UNITS_PER_METRE (732, How many height units fit into a meter)

MAX_HEIGHT_RANGE (0xFFFF / HEIGHT_UNITS_PER_METRE ~= 90, maximum heigt values in meters - used in RMGEN - supported by the engine - using the range 0 to 0xFFFF). Better just to take the 0xFFFF IMO.

All to be found in binaries/data/mods/public/maps/random/rmgen/library.js

Edited March 22, 2015 by FeXoR

[wowgetoffyourcellphone]

Sorry, I read millimeter as meter, so I thought the precision would go from around 1 meter to 10 meters. That didn't seem acceptable. A centimeter isn't too bad at all. Still, 8x seems like overkill unless we are planning much larger maps in the future.

Never know what future holds.

[historic_bruno]

While we're at it:

- It would be nice to remove all hardcoded unit parameters from RMGEN and have the engine give those parameters to RMGEN at start - namely:

CELL_SIZE (4, size of a terrain tile in meters)

HEIGHT_UNITS_PER_METRE (732, How many height units fit into a meter)

MAX_HEIGHT_RANGE (0xFFFF / HEIGHT_UNITS_PER_METRE ~= 90, maximum heigt values in meters - used in RMGEN - supported by the engine - using the range 0 to 0xFFFF). Better just to take the 0xFFFF IMO.

All to be found in binaries/data/mods/public/maps/random/rmgen/library.js

I guess they could be added to the map settings during init.

[rmhibbs]

I am excited about this change. It will allow for much more interesting maps.

As you increase the usable height, will you also be able to have rivers with more drop; faster flowing; rapids; waterfalls?

Good work! Thanks.

Bob

[sanderd17]

Not for now, the water plane is flat now. But maybe in the future, there could be a number of different water planes, or even a water height map.