This does require a color definition to be added to the colors file.
Implemented as a generic option to draw or ignore types of nodes
(i.e. 'air', 'ignore'). Ignoring specific named nodes from the
command-line is not (yet??) supported.
i.e. allow minetestmapper to query the database for a list of
blocks in a specific range (corresponding to the requested geometry),
instead of always obtaining a full list off all blocks.
As postgresql is the only database which supports this efficiently,
this option is only effective for postgresql.
When using --disable-blocklist-prefetch, the database key format for every leveldb
block, which is normally determined when prefetching the block list, is not known.
In order to avoid duplicate queries using both key formats, the key format can now
be specified using --database-format
This introduces a speed tradeoff.
When mapping a small part of a large world, the prefetch time dominates
the mapping time, and it is more advantageous to skip the prefetch and
query all possible blocks in the mapped space.
When mapping a large fraction of a world, in particular when a lot of
the mapped space is empty, the time spent querying non-existing blocks can
dominate mapping time, and it is more advantageous to prefetch the list
of existing blocks, so that querying huge numbers of non-existing blocks
can be avoided.
As tests using --sqlite-cacheworldrow showed a consistently
lower performance than without, this option was effectively
disabled. It is still recognised for compatibility, but
it may be removed some time in the future.
--heightmap: generate the height map, in colors
--heightmap-grey: use shades of grey instead of colors
--sealevel <n>: define the sea level (below sea level is drawn in blue)
--heightmap-scale <f>: scale the heights by f (for the purpose of
color selection)
When generating a heightmap, a special colors file is needed,
that defines just the blocks that should be considered part
of the ground. That means that normally, any plants, special
nodes and water should not be included.
The option --tiles has two new possible values: 'block' and 'chunk'
'block' creates tiles corresponding to map blocks
'chunk' creates tiles corresponding to map chunks
(chunks are the unit of map generation).
An option --chunksize was added to manually override the chunk size.
Note: on the y-axis scale, the block coordinates are rendered above
the line, instead of under the node coordinate, as that makes
them adjacent to the block they refer to.
for illustration: create a map with --drawscale --tiles=16 --tileorigin=world.
this makes the tiles correspond to the map blocks.
Consider a point with y-coordinate 64. It is part of a map-block with y=64..79.
This block is located at and above the line corresponding to y=64. On the y-axis,
it is therefore most intuitive to render the block coordinate above the line.
This new mode averages the colors of all transparent blocks, instead of
making the colors progressively darker and more opaque.
This 'average' mode is now the default when using --drawalpha. It can be
explicitly selected using --drawalpha=average. The old modes can be selected
using --drawalpha=cumulative[-darken].
It is recommended to change the colors of water as well. These are in a
separate patch.
As this comes with a significant performance penalty, this
feature must be enabled using the command-line option --drawair
For best results, the color of air should be fully transparent,
so that underlying nodes will override it.
This is useful to show invisible ('air' or 'invalid') nodes in blocks
that are in the database using a different color than blocks that are
not in the database (which will have no color at all, causing the
background color to show).
A colors file can now specify other colors files, from which
additional node color specifications will be read. This allows, for
instance, using system-installed colors file for most colors,
and only overriding some of its colors in a custom colors file.
As a purpose of using a custom colors file may be to leave the colors
for some nodes undefined, it is now also possible to undefine a
previously defined node color (i.e. after reading another colors file
which defines a color for the node).
addi
Rogier