Jump to content

Enlarge maximum map height


sanderd17
 Share

Recommended Posts

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.

  • Like 4
Link to comment
Share on other sites

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 by Skhorn
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by FeXoR
  • Like 1
Link to comment
Share on other sites

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.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...