Feature Request: Provide a non-rendering mode that just gives a count of how many tiles need to be rendered

[JRSofty]

My problem is that after a gaming session on my world I would love to do a render, but I would like to know how long it will take to perform the render. Naturally I can get a basic idea if I knew how many tiles would need to be rendered (either updates or new renders). So a nice feature would be an option that just dumped out the number of tiles that would need rendering, and from that I can kind of guess how much time would be needed.

[Gregory-AM]

The Minecraft Overviewer shows an ETA of how long a render is supposed take to complete. This applies to new renders or updating an existing render.

[JRSofty]

Yes, but I was wondering if it would be possible for it to provide an estimate of the number of tiles to be rendered or an estimate on the time, without rendering them? I can use this information to decide when I want to run the render. If it's not possible no big deal.

[Gregory-AM]

This is not possible at the moment.

I'll keep this issue open as a we can possibly look into showing a preview of the Tile Count and Time Estimate required to render the world; possible with a command-line argument.

---

When we do dabble into this, we will close this issue with a comment letting you know that we have started working on this.

[stwalkerster]

This sounds like an XY problem - what use do you expect to achieve from having this information while not actually performing a render?

Even the current tile estimates that are provided to the observers can be inaccurate at the moment, though admittedly I think I've only ever seen an over-estimate of this. Additionally, if you're running in --check-tiles mode, there's basically no way to get an accurate number and the value returned is an estimate based only on the number of zoom levels ("tree depth") your map has, specifically: $$\frac{4^{zoomLevels + 1} - 1}{3}$$

https://github.com/GregoryAM-SP/The-Minecraft-Overviewer/blob/0892d26e0d047268c408de2a48b49cc04f23b84e/overviewer_core/tileset.py#L464-L470

I don't foresee extracting the current estimated tile counts to be too hard as the dirty tiles are calculated before the work is dispatched for a render. I think we can probably extract the total work count from the tilesets after we've done the preprocessing on the tilesets: https://github.com/GregoryAM-SP/The-Minecraft-Overviewer/blob/0892d26e0d047268c408de2a48b49cc04f23b84e/overviewer.py#L581-L586

---

The estimated time remaining is usually wildly inaccurate until you're a good way into a render. It's also only ever calculated by the observers (as an extrapolation from the render start time). I don't think this will ever be retrievable. https://github.com/GregoryAM-SP/The-Minecraft-Overviewer/blob/0892d26e0d047268c408de2a48b49cc04f23b84e/overviewer_core/progressbar.py#L117-L122

[JRSofty]

The actual time to render isn't really the important part, but a calculation of the number of tiles that will be rendered if I were to run a rendering. The amount of time for rendering is very machine specific and I understand that. I can calculate my own time estimates for my machine if I have the tile count.

This is a very specific use case. I use this on my single player world, and would like to know how much is changed before I start a render. Since interrupting a render also causes issues I would rather avoid it if I know I don't have enough time to render it.

[stwalkerster]

OK, gotcha. I wonder if it's also worth us having a ticket to allow safe cancellation of a render in progress, which might also alleviate any concerns about time to render somewhat? My thinking here is to dump the dirty tile list, the render start time, and a hash of the config to disk at the start of a render, then if/when a render is cancelled it can check mtime of region files vs mtime of all tiles in the dirty list, and add the old dirty list to whatever dirty list exists for the newly-started render? I'm just throwing ideas around at the moment - dumping a dirty tile count is definitely going to be easier than what I just suggested.