Unified heightmap format

[robn]

We have two heightmaps (Earth and Moon). Both have slightly different formats, and slightly different fractals to manage them.

1333 would add another heightmap in a different format again, and a lot of code to support it. This is unmaintainable in the long run.

I want a single heightmap format, and a single terrain generator to cope with. Then mods can add as many heightmaps as they please.

I have no particular opinion on what this format should contain - terrains are not something I know much about.

[shadmar]

Questions

How should this really work? Could this be done in 2 steps ?

step 1 : file format

I have pure png heightmap reader wich replaces the old hmap format alltogheter and seems to work ok for both earth and moon without changing the fractal code as is. (except I have yet to find a good earth heightmap)

step 2 : Fractals

We could rewrite the terraincode for heightmapped fratals to have som fractal option based on input like this ?

:height_map('earth.png',MODE)

MODES could maybe be :

EARTHLIKE MOONLIKE MARSLIKE ...

Since png can use 4 channels we could also, use RGB maybe to determine diffrent fractals on each channel and store height in alpha. (haven't thought this through or if it will ever work)

[robn]

It needs to work such that I can produce a heightmap file in whatever program creates them (a terrain generation package, an image editor, or my own code) and drop the output* in Pioneer's data directory and it works wiithout having to recompile the game.

• I'm happy for us to write and ship a compiler to turn it into a Pioneer-native format. The point is, I don't want to have to add code to support a particular kind of terrain unless its part of the documented format, and generic enough to work anywhere.

I don't like the MODE concept. I'd prefer that the data or algorithms needed to do that be built into the heightmap file. And I'm not suggesting that we actually have code in this file, but more that the fractals in Pioneer are generic enough that they can produce what we need from the data.

There was talk at one time of having some layered format where you have several versions of a heightmap at different resolutions, and mix/interpolate between them as necessary. Colours and heights could be done in different layers. I guess its a kind of LOD switch, not sure. But it wouldn't need to be some magical file format or misuse of PNG channels or anything like that. It could just be a zip file with a known set of filenames.

Really, that first paragraph is the only requirement, I think.

[robn]

@floodfill2 wrote:

What about an lua callback for each heightmap? Something like onLoadHeightMap(HeightTable) with the return value being a table of colors. The result of this can also be cached to a file if necessary for fast loading.

I don't understand what you're suggesting.

[shadmar]

For step1 just get a friendly format to replace the one we have right now, just about any picture format SDL::IMG_load can read instead of the hmap format we use today, which noone can edit or produce without c++ code. I can pull my existing stuff on this if this is feasible. (Just need to find some replacement maps for the hmaps we have today)

For step2, well we have 2 fractal formats for heightmaps, one for earth one for moon which would be abit limitied. (if you wanted to create a mars like planet without water, vegetation coloring etc) You are suggesting we should only have one, that would be great, but it should take some parameters so not all heightmapped planets would look the same (color,fractals etc)

Not sure I made myself sany clearer now..

[robn]

Sorry, I was responding to @floodfill2, which he appears to have since deleted. I've edited my comment up there to include the text I was replying to.

[robn]

And yes, I'm suggesting we only have on heightmap format, but one with enough flexibility to do whatever we need. "Parameters" are just different data within that format.

[fluffyfreak]

My suggestion, supply two things:

1. Heightmap - 32 bit format, better for usage internally, requires no conversion etc.
2. Colourmap - standard 24 bit colour format png.

The rest of the info should come from the usual fractal input params such as sea leve, ice cover etc which are already exposed to Lua for defining custom worlds.

Use a single fractal to add sub-texel level detail. With height and colour coming from the above two maps you can keep the fractal really simple if you like.

The only decision to be made is what format to use that allows us to import/export 32 bit floating point heightmaps and how we get data into that format.