For what it is worth, this is an older explanation of my plans for the terrain renderer. This work was begun in the 'newterrain' branch, starting with converting the old data into a more appropriate format for such rendering, but put on hold until javascript porting and 3.1 release work is completed. The mentioned modding improvements have been addressed in the branch, but very little documentation exists yet. I'd be happy to discuss the details of this plan, if someone wants to work on it.
The current map renderer has some painful issues with transitions that
blend badly or get wrong geometry. This is due to the way the blending
is done by shifting tiles instead of doing proper splatting. Now,
different solutions will have different limitations. I would like to
design a solution that does not need shaders (see more on shaders
below), and can work on worse graphics hardware. I would also like to
make code that is maintainable and clean. The first point of order in
that regard is to fix up the map format, so that conversions are done
once in an external tool. I am currently working on this. The idea is
to keep height and terrain type in 8 bit grayscale PNGs, and decal
info in an INI file. The heightmap is expanded to four points, of
which we use two (upper left pixel as upper left height, and lower
right pixel as center height) for now. The current terrain type is
split into a terrain type (8 bit value) and an optional decal entry.
The rotation and flipping is ignored for terrain, while rotation is
kept for decals.
Each terrain square is thought rendered as four triangles. We will be
needing hardware support for 4 texture units and multitexturing.
Terrain will be drawn in one pass. Two texture units will be loaded
with packed terrain textures, and one with a variety of packed
blending masks. (I am unsure if the choice of blending mask should be
left to the map editor and saved as PNG of its own, or whether this
should be generated automatically on load. We may want to use some
pseudo-random variety in blending masks here.) For each triangle we
calculate texture coordinates that blend a 'native' terrain with an
'opposing' terrain (the terrain 'native' to whichever tile the
triangle faces) using one of the blending masks. If the 'opposing'
terrain is identical to the 'native' terrain, we just use null
coordinates. For decals, I would like to pack the decals, as well, but
in as many pages as we need to support any number of decals. If we
have more decals than we have available texture units, we just add
more draw passes. I think we should offer the user a choice of 512x512
and 256x256 texture sizes for terrain, the lower size for people with
worse GPUs, and I think that will be more than large enough at the
zoom distances that people will play the game. This leaves us with a
hard-coded limitation of max 16 base terrain textures for each
tileset, 64 blending masks (since they are triangles), and any number
of decals. I think this will be quite enough. Adding variety to maps
should in any case be done by adding decals, while the number of base
terrain types should be kept low (for aesthetic consistency reasons).
The current master map rendering framework is quite difficult to mod.
I want to change this as well, to make it very easy to add new
tilesets and bundle them with maps, while reusing any existing
textures as desired. (I do not have my notes for this available, so I
will have to add those details to the plan later.) The textures will
be stored as individual files, as now, not as texture pages, to allow
easy re-mapping and re-paging.