search

GregoryAM-SP / The-Minecraft-Overviewer

The Minecraft Overviewer | Successor
https://overviewer.gregoryam.com
GNU General Public License v3.0
100 stars 13 forks source link

Speed regression on resuming incomplete renders #18

Closed vilhok closed 1 year ago

vilhok commented 1 year ago

I killed the process in the middle of the rendering, therefore I now need to re-render. Interestingly, I killed it because the process had become stuck, which might be something else to look into, but I have no further info about that.

It had ONE tile that was not rendered, on the deepest possible zoom level, therefore it was missing one tile from each zoom level.

How ever, the speed of the re-rendering is very slow, just couple of tiles per second. In previous versions, it used to check the existing tiles very fast, like thousands of tiles per second and find out that the file exists and only render the offending ones. Was there anything changed about this, or is this something on my end?

Gregory-AM commented 1 year ago

Sadly, this isn't something new. Re-rendering a map will always be slower, since it has to check the tiles that were originally rendered.

Which this information can be found somewhere in docs.overviewer.org, where it talks about rendering and re-renders.

That being said, there's nothing that can be done about this. I've attempted to speed up the rendering process before, and all attempts have failed. Since it relies on parsing NBT Data, which I can't seem to speed up without it using way more RAM.

You can always check out one of these options: http://docs.overviewer.org/en/latest/running/?highlight=Rendering#options-1

Since this deals with rendering.

Gregory-AM commented 1 year ago

Also, if you want. You can package your world into a zip, upload it to Google Drive, send it over along with your configuration file and I'll take a look at it and see if there are any errors or if I can reproduce the possible hang on a specific tile.

vilhok commented 1 year ago

Sorry but I feel like you misinterpreted.

Regression in this case means that the current commit is way slower than one of the previous ones. It seems like some caching has been thrown away, or something unnecessary is being done. EDIT: Quickly taking a diff between this fork and the original does not seem to reveal anything concerning though, but I'll look into it.

EDIT2: I also want to emphasize on a distinction: A re-render takes quite long, depending on how many chunks were changed. This is not a problem. The problem is how long a cancelled re-render takes.

Re-rendering definitely was not this slow. Yes, it gives "wild estimates" about the tile count, but something has changed about how it checks the missing tiles. It used to check the tiles several thousands per second, and now it runs barely faster than the original render.

I won't reopen the issue for now, but I'm gonna produce some actual numbers If I'm able to downgrade my map to such version that the old project still renders it.

I appreciate so much that you took over the project, seeing the biome colors in my map is great. Just that I can only run this computer so long daily, I'm unable to complete a single render due to it taking so long.