What happened to the ability to render the map to multiple tiles?
retep998 opened this issue · 9 comments
The openlayers script doesn't seem to work anymore as it uses a -split argument which isn't understood by mcmap anymore. I have a decently sized world that I'd like to share a map of, but the gigantic single png it creates is really unwieldy (over 200 MB). It would be great if there was a way to create a web map using individual tiles that could be easy to render.
Hmmmm, I wonder how feasible it would be to create a Rust program that loads the gigantic PNG and generates tiles...
Well, I was waiting for such an issue to re-implement the feature. Generating tiles from a PNG is trivial; mcmap can go further and generate isometric slices of the world. The problem would be to know if a map viewer could display those slices by overlaying them, or if it would be better off displaying square tiles.
I thought nobody was interested, and did not take the time to look at this feature. A year ago, while going through the project, I think I remember asserting that the openlayers script was outdated; if that is interesting to you, please let me know what displaying backend you have in mind, and I'll make mcmap output the right images.
That functionality never worked for me, but because the old mcmap was so memory efficient I was able to render it all out into a ~250MB PNG file and slice it up with a small tool myself https://github.com/M3t0r/png-tile (imagemagick needed 15+GB for the same task).
Back then I used https://leafletjs.com/ to build the interface, and it required square tiles that can't overlap. I doubt that changed. At least not when you want a performant solution.
Are you not able to anymore ? I tried making the new version as efficient as possible. Or is it that this world is pre-1.13 and not compatible anymore ?
@spoutn1k I didn't have large worlds on a small server in over 4 years. And I haven't rendered any map since. I just thought I'd share my experience from back then. But the numbers I remember was limiting mcmap to 500mb, and the output PNG was 250MB big. It took a lot of iterations to generate the map!
Definitely should be square tiles as that is what everything is designed for. I don't personally have any opinions on which display backend to use. I just want some sort of web map that is easy to view.
On the subject of tiles, I've been thinking about the artifacts in the water on the boundaries between those isometric slices, and I'm pretty sure that could be resolved by using premultiplied alpha for all your rendering as well as combining the tiles, and only converting to conventional alpha when outputting the final images.
This commit added the ability to tile the output. The results are sorted in a machine parseable way and I got great results with leaflet.js. I plan to add the HTML/JS scripts in a future commit, once I nail down how to transfer execution info into the webpage.
Tiling support has been merged in the master branch.
About premultiplied alpha, from http://www.libpng.org/pub/png/spec/1.1/PNG-Rationale.html:
PNG uses "unassociated" or "non-premultiplied" alpha so that images with separate transparency masks can be stored losslessly
I am skeptical about if it can be done using the PNGs as they are used today.
On the subject of tiles, I've been thinking about the artifacts in the water on the boundaries between those isometric slices, and I'm pretty sure that could be resolved by using premultiplied alpha for all your rendering as well as combining the tiles, and only converting to conventional alpha when outputting the final images.
FWIW while pre-multiplied alpha might help, I think those seams were the result of rounding errors since you only have 8 bits per channel, but in case of an ocean, you have multiple transparent setpixel operations per output pixel, so you are off by quite a bit in the end. I planned on hacking up a simple 16bpc version to test if that theory is correct, but then never got around to it.
I will definitely test this theory.
My head cannon was we need the 'depth' of each layer to accurately merge the layers as if they were made by multiple setpixel operations, which is a task and a half.
Hopefully switching to 16bpc fixes that, and I am pretty sure I kept most of the groundwork you laid for it (with the BYTESPP macro or something)