Scallact

Well, maybe that the elephant in the room, while we are talking about everything else? I understand the perfectionism of the devs, in not labelling the game as "finished". However nowadays nothing in the market is ever finished. Or maybe it's a dev's choice, to limit unavoidable player's pressure by a too large community? Which I would understand as well. But, from a player's perspective, it's a lot of wasted awareness potential.

A temporary solution I found, useful if you are not confident with copy-pasting into a hex editor, is with a nice little command line utility: Swiss File Knife. It's multiplatform, and doesn't even require an installation. Just put the executable near your files and run it in a terminal. The useful command it provides is "partcopy", which allows to copy part of a binary file to another. An example command, to transfer elevation from a 385x385 uncompressed 16 bits greyscale .tif to a large .pmp : ./sfk partcopy [source_name].tif 8 296450 [map_name].pmp 16 -yes The number in the middle is the number of bytes. It must be adapted to the map's size: map size tif(px) bytes ----------------------------- normal 257 132098 medium 321 206082 large 385 296450 very large 449 403202 giant 513 526338

Yes !!! We need that ! 16 bits import ability is the only missing link between elevation files and the Atlas. I have a GIMP plugin nearly ready, for the creation of elevation files, but I'm hesitant to publish since the import learning curve is too high. Your idea of a GIMP plugin for .pmp export is nice too, that would perfectly fill the gap. Before anyone asks, I don't think I would be able to write such a plugin with my current python level. :-) I might still try to look at it in the (not near) future if nothing moves on this front.

All good now! Thanks!!!

Thanks a lot! There are still many blurry textures on my side, for example, the majority of "Biome Alpine", and many others. Alpha 26 final on Ubuntu Linux 20.04, the snap version and the ppa version have the same problem.

You surely meant "wood" instead of "food"? Too bad you didn't bring it up during the long release candidate testing? Like, it seems no one tested the Atlas during that phase, and now all textures are just a single color in the interface. (I'm a culprit too)

Oh ok, thanks for the info! Will try another civ tonight.

Why aren't Athenian and Persian included in the changeset? Don't these civs benefit of the new tracks? I played with the Athenian last night, and I only heard the old tracks, even when watching the replay.

That would be huge!

So we are back to the "external software - mesh import" model. Which is exactly what I do with my plugin. You know what would be extremely useful ? An Atlas mesh import function which doesn't crush the heightmaps to 8bits. :-)

@smileyHere is a height-map produced with the "distance map" algorithm. Those mountains are too huge but it gives you an idea.

Pardon my ignorance - what is an "actor mesh" ?

If you're looking for some simpler algorithm, I also made experiments with the "Distance map" one. Gives some nice, if not slightly "too regular" results. Maybe that would fit your requirements. Basically, it computes for each pixel the distance to the nearest black pixel. This give cute mountains with constant slope.

See above! TL;DR : yes, I use some advanced image processing algorithms ! ;-) At least, the "Solidify" G'Mic algorithm is the basic concept of it all.

FYI, I don't use an iterative erosion process at all. But: The base noise is generated by the "solid noise" GIMP algorithm Then, some random pixels are spread with the "Poisson disks" (blue noise) algorithm (G'mic) Those pixels sample the values on the noise layer The main render is then computed by the "Solidify" G'Mic algorithm. It computes a Delaunay triangulation between the pixels and fills the triangles with the interpolated gradients. These above are the main ideas. Some operations are done twice and combined with specific layer modes. Some "distance map" from GIMP is used for more regular mountains. A general "sea sedimentation" layer is added to have different levels through the map. So yes, all of this would be quite involved to implement in JavaScript, and probably not very fast. To give you an idea, the script runs in ~13 sec on my machine (i7-6700K @ 4Ghz, Geforce GTX 1080) Apart from layers operations, apparently the most computationally intensive is the "Solidify" algorithm. BTW, those algorithms could be implemented (if possible) separately, and then used in by the map script itself.