Pioneer dev forum

After some reverse engineering I'm getting closer to figuring out the existing "hmap" formats.
I have no idea how they were created, or where the embedded values came from, or why they're such odd dimensions!
However it has helped me figure out that when they're used it does bicubic interpolation of the heights which is nice to know so I'll document that and probably factor out the code (already done on my branch).

Anyway this leads me onto some questions for people who're interested in the subject namely:

• What format do we want to use? 16-bit TIFF uncompressed seems common.
• Should it come with a specification file? That defines scaling, min heights, etc, separate from the data/image format.
• Is there a good argument for having a 16-bit TIFF -> Custom format converter?
• Can anyone think of anything else I've missed?

Chip in please!

I've been getting heightmaps from here:
https://astrogeology.usgs.gov/search/ma ... l_200mp_v2
https://astrogeology.usgs.gov/search

But beware they are HUGE files, I've had to use ImageMagick to resize them from the command line using: To get them down to less insane sizes where I can then open them up in GIMP 2.10.8 to decide what to do with them afterwards.

And by odd data I mean: The moon has (hardcoded) different data because it's a "scaled" heightmap ... *shrug*

Great work!

My only input is, it must be good to use some format that is standard and well documented.

In theory PNG can support 16-bit no problem, and I've converted some of the TIFFs into PNG for testing, however SDL_Image seems to just import them as 8-bit...

EDIT: ...and when you import TIFF files, which SDL_Image also supports, it promotes them to 32-bit! Wierd.

Ok, figured it out we can't use SDL_Image to load 16-bit TIFF files because it converts them to 32-bit 8-bit per channel images internally. I.e. it turns the nice 16-bit inputs into 8-bit values, then copies those values into the red, green, and blue channels. Alpha is always 255.

So it's useless for getting higher precision terrain data into the engine. However I have found an alternative for reading TIFFs called TinyTiff that does the job ok it seems.

So I will press on down that path. The libray itself isn't a great fit, it doesn't have the flexibility that I want, but I think that I can extend it.

EDIT: actually looking more into that library I think the word I should have used is "rewrite" it

Speaking of maps, here's high resolution of Mars:
https://mars26.com/

A) that's very a piecemeal photo collection plastered on a perfect sphere with no height,
B) wtf is with them trying to use NFT to descried OWNERSHIP of pieces of mars from orbital photos?

I could answer that question, if you buy the NFT for this comment, proving you are the unique owner of this one-of-a-kind post.