[Freeciv-Dev] Re: I have written a new terrain generator

[Helge Hafting <helgehaf@xxxxxxxxxxxxx>]

"Ross W. Wetmore" wrote:

> >Thanks, I have uploaded tergen.tar.gz to incoming.
> >Untar it and move source files to
> >freeciv-1.12.0/common/ (it uses the registry routines)
> >
> >Helge Hafting
> 
> I tried things out and except for problems with the savegame (I commented out
> this code to allow the printed results to complete) it looks quite intriguing.
> I used a release version of freeciv-12.0 from last summer. Attached is a
> printout if one needs an example to make sense of my comments.
> 
> I was impressed by some of the simplicity of the algorithms and coding style
> which produce quite reasonable results.
> 
> I saw nothing objectionable in the code save maybe for a tendency to code very
> long lines vs wrap at ~80 columns. The style, technical level and
> documentation
> are very readable and professional.
> 
> I also think that the various steps are modular enough that it should not be
> difficult to replace, say the heightmap generation, or river generation with
> other modules. Or conversely, insert these into the existing mapgenerator1 as
> replacement for some of its current modules.
> 
> It should also be possible to slip some of the make_fair() and other routines
> into this sequence to enhance some aspects via post-processing.
> 
> Your terrain rulesets could quite easily be combined with the make_{type}()
> routines to provide additional or replacement parameterization/functionality.
> 
> make_plains() converts roughly half of remaining grassland to plains in
> mapgenerator1. The trick with height, temperature and wetness is to bias such
> selection so higher/colder/drier tiles are more likely to be plains, but the
> overall weights sum to 50%. There are some attempts to build such effects
> into the existing module, but it would be trivial to use the per-tile values
> from your system vs the current computed ones to give a more sophisicated
> flavour.
> 
My idea here is that the kind of world you get is controlled by
tergen.conf.  My tergen.conf was quickly put together, so it has
weaknesses like almost no forests.  It is ill-tuned - but that is
fixable. It can be improved a lot.
A "default" tergen.conf should generate all supported terrain types
in realistic amounts. 
I didn't really plan on supporting percentages of this and that - if
you raise global temperatures you won't get any arctic at all for
example.

I could create a wetness statistic and dynamically determine tresholds
for desert/grass/swamp, and use similiar statistics
for choosing between mountain/grass/hill.
But that sort of defeats the whole simulation.  If you don't want
mountains, remove the mountain generation rule, _or_ change the max
height to something lower than what the mountain rule specifies.

Some of the existing settings don't map well to my way of generating
terrains.  I may be able to take more input from the existing
variables, but some of it just don't fit the model.  Instead, there
are other ways of achieving the same.


> Now for some "weaknesses" ...
> 
> The update/rewrite savegame code needs to be rethought and rewritten for
> viable standalone use. I doubt you will find this comment a surprise :-).
>
Of course.  The long-term idea was to get this integrated as one of
the available terrain generators to run _before_ the game starts.
If it otherwise is deemed acceptable.  Users should simply select
wether they want my generator or one of the other ones.

 
> The map structure appears to be quite blocky. I suspect this is just a matter
> of playing with the smoothing algorithms, or substituting calls to things
> like
> adjust_map()/smooth_map() in the corecleanup mapgen.c to make the heightmap
> more uniform/contiguous and/or round off some of the edges so their original
> NxN character isn't quite so apparent. 
The NxM stuff is a weakness indeed.  
The "best" way would be a (simple) simulation of plate tectonics and
erosion, but I don't even have simplified knowledge about plate
movement.  So I couldn't do that.  I guess raising circular regions
would help a _lot_ though.  Rectangles has this nasty property
that edges for different rectangles often overlap, creating
straight coastlines and mountain ranges.  Circles almost never
overlap perfectly, there's much more intersections.
Real mountain ranges are often long and narrow because they really
are plate crash zones.  So a combination of circles and lines in
random direction would improve things.  This is one of my next
planned improvements unless someone have an idea for a
real tectonic algorithm.


> If you look at the asteroid rain
> "splash" effect in the corecleanup mapgen.c, there might be some ideas about
> how to tip or randomize block adjustments within a smaller range to destroy
> the integrity of the block borders with little basic change to your system.
> 
> The area where this blockiness may be a more severe problem is in the terrain
> allocation. All terrain above a certain height is not a mountain, but quite
> often high level plateau, or a fertile river valley. Some of the simplicity
> here might be modified to detect "roughness" or changing elevations, or
> conversely find a way to un-smooth mountains into thin linear chains rather
> than blocks. 
Good point.  The current generation looks at a single tile at a time,
that's
good for simplicity.  I could create a "roughness map" from the height
map,
where "roughness" is based on how different a tile is from its
neighbours.
This could be a fourth parameter to the terrain type rules, allowing
things like:

mountain if tall & rough, plain if tall & smooth
hill if rough & low, grass/jungle/swamp otherwise and so on.

> Hills can be more blocky, but should have a similar "natural"
> shape. There are a lot of coastal mountains, i.e. at the edges of tectonic
> plates in the real world, with the centers of continents often being quite
> flat.

> Your big continents tend to uniformly mountainous interiors or be composed
> of a central height mass with peripheral lowlying blocks, i.e. dome shaped.
> Note, there is a similar tendency in CVS, so you are no worse at this aspect
> of heightmap generation and usage.

This is the result of un-realistic height map generation.  Fixes may
be tacked on to the current stuff, or a better algorithm used.
The roughness stuff might cut down on the central mountains, turning
some of them into plains instead.

> 
> Inland lakes and seas should be possible with your system, but I didn't see
> that many. It might be that restricting outflows and setting a threshold for
> combining adjacent rivers into swamps and lakes would give this effect. I
> suspect that your seas are of the Dead Sea type, i.e. below true sea level.

Any "lakes" bigger than 1 square you see is just a low region that
happened to
be trapped between higher region.  There is no concept of continent
or sea other than height above or below 0.

A river with no lower square to flow to will create a inland lake,
currently
size 1x1.  I have planned an improvement where such lakes fill up,
repeatedly 
spill into the lowest neighbour square until the closed valley fill up
and the river spill into lower terrain and eventually the sea.

 
> Rivers should flow through drylands. There seems to be a tendency for a lot
> of short rivers on the windward slopes, and nothing flowing to leeward. Long
> river systems are typically found in the latter case.  

This could be a weakness in the weather algorithm.  Water fall from
clouds
whenever they get over higher or colder terrain, sometimes _all_ of the
cloud rain down and nothing's left to drift further inland.  The
rain_divisor
helps here, setting it high and also increasing the rain_passes a lot
will
wet a lot more terrain.  You may have to increase the river treshold and
change wetness limits to get good terrain, but this might give better
water distribution.  If it don't, please give more suggestions 
about algorithm improvements.

> I'm not sure if this
> can be tweaked by increasing flow-through values and/or a greater wetness
> distribution area that extends 2-3 tiles with at least some major rainfall on
> the immediate leeward slopes. The mountain heights need to be narrower or a
> change in height be used as the moisture squeezing operation on clouds, maybe.
> Rivers also appear to have multiple outflows in some cases, or be joined at
> their headwaters. Random rivers without constraints can be very unrealistic
> but this is difficult to get right.

The generated rivers are quite good, but there is a freeciv limitation
at play:
a tile either has river or it don't, and this river join all adjacent
river tiles.   this would be much better if I could specify things like
"for this tile, the river flows downhill in direction X".  
That would avoid joining two rivers who happens to flow in parallel.

Or I could work around this limitation by considering rivers only for
groups of 3x3 tiles.  Then they would join only when I really
want them to.

> 
> make_fair() postprocessing and/or some additional variability in the selection
> of forest/jungle, grass/plains, swamp/hills, tundra/arctic might reduce the
> mono-terrain aspect of the current selection. The trick is to have a range
> probability that peaks or plateaus near the optimal conditions (but is not
> 100%) and extends (possibly) far out into suboptimal parts at low threshold.
> The order in which the terrain types are allocated can be used as well. The
> resulting effect is a measure of randomness or denseness for each terrain type
> that controls its possibility of appearing and clumping when it does.

I have though of adding randomness.  For each tile, the algorithm could
determine how well each terrain type fit, and then use a random
number to select using that distribution.
 
> The concept of controlled percentages for various terrain types is also
> something that appears to be missing. 
They're missing on purpose - create a world with very wet conditions and
there just won't be deserts.  Still, such weights could be used to skew
the
terrain fitness distributions mentioned above.

> Your algorithms can still be used but
> their "average" points or "distribution" weights may need to be adjusted by a
> (un-)smoothing function. Or the random selection use the computed averages in
> some way to compensate. You provide a number of different (and maybe more
> useful) parameters to control the texture of the final map, but it may turn
> out that some interface to the currents percentage system is either required
> for backwards compatibility, or as the common form that all generators agree
> to support for uniformity of user interface. Optionally allowing per generator
> paramters is perfectly reasonable as an additional way of using them for
> advanced users.
>
As you have seen, my generator needs quite a few parameters of its own
to work.
Hardcoding some might be ok, but I want to keep much of it open for
tweaking.  People should be able to play strange worlds if they want to.
Such as a world without mountains or no arctic.  Or possibly
a nuclear winter world with frozen seas and mostly tundra/arctic.

I am open for using more of the standard parameters, but not in ways
that are squarely against the idea, which is a world created by
simulation.

> It would perhaps be worthwhile to see what sort of post-processing or builtin
> capabilities would really entail in terms of changes to your system.
> 
> But I really do like the basic simple and yet conceptually realistic approach
> to the fundamental generation here and think this is an excellent basis to
> develop further, perhaps even close to the current CVS mapgen in usability as
> it stands.
> 
> I guess a followup question is what would you like to see happen next. Are
> you interested in enhancing or upgrading your system? breaking it down and
> integrating it into current modules? discussing and/or working with others
> to do any or all of the above? having others take over and do such things?
> working on a design proposal for discussion and presentation?

I am interested in improving the my system, and get it integrated
into freeciv so it gets usable for all.  I can put in some time myself,
but I have work to do too.  Others who want to help with this
are certainly welcome.

I got the impression that freeciv went into a code freeze recently, so
I don't know if integration is possible at the moment?
The first improvements I plan to try is the terrain/mountain roughness
stuff
you suggested, and the use of something other than NxM rectangles for
height generation.


Helge Hafting
Helge Hafting