Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time-Lapse Renders #799

Closed
ekovac opened this issue Aug 24, 2012 · 2 comments
Closed

Time-Lapse Renders #799

ekovac opened this issue Aug 24, 2012 · 2 comments

Comments

@ekovac
Copy link
Contributor

ekovac commented Aug 24, 2012

It should be possible to efficiently present a timeline slider to enable users to scroll through and view changes to the map over time.

Throughout this explanation I will use 'world' to refer to the Minecraft region files, and 'map' to refer to the completed rendering output of Minecraft-Overviewer.

Procedure

  1. User backup scripts fetch a fresh snapshot of world t, assuming a world t-1 exists already. Utilities such as dirvish simplify and optimize this usecase.
  2. User scripts do a recursive copy of t-1 map using the -l option to use hardlinks.
  3. Render t map on top of the hardlinked copy of t-1 map. Current semantics in Minecraft Overviewer's file saving should ensure that t-1 map tiles that need updating are replaced only in the t map copy, since save /rename or delete/save are used instead of truncation.
  4. User script generates a list of links or a modified web asset file allowing users to navigate between maps at different times.

This procedure has a distinct drawback in that clients' browser caches will not properly reuse tiles that do not change between each timestamp. Tiles that do not change would still be represented as distinct URLs. Not only would this drastically increase bandwidth consumption to the host, it would impact the fluidity with which users could navigate the timeline.

I'm unsure of how the Google Maps API works internally, so it may not be possible to do what I'm suggesting elegantly. There would need to be some way to maintain a reference table of the "last change" of a given tile coordinate so that the appropriate URL could be used.

Additionally, it would be ideal if a timeline slider could be presented in the stock web assets.

I'm not sure how feasible any of this is, as I'm not a webdev. It seems to me however that the potential costs would be fairly modest.

@tswsl1989
Copy link
Contributor

An interesting idea, but not something feasible for Overviewer to support directly, IMO

As I understand it, the only way to support this using the Google Maps API would be to treat each snapshot as a separate world and have the slider select the worlds in sequence. There would also be issues if the world has grown or shrunk enough between successive snapshots to require a different number of zoom levels. We would almost certainly also need to impose more rules about folder layouts in order to have any kind of sanity in overviewer.js, which is something we have tried hard not to do in the past.

Maintaining a list of tiles and the last time they changed and handing that list to the browser has been rejected in the past - we have a lot of tiles and you end up with megabytes of data pretty quickly.

In addition to that, hardlinking tiles from previous renders would 1) remove some of the speed increases made to Overviewer over the past few months and 2) be difficult to maintain in a cross platform manner. You would also need to have snapshots of the world corresponding to each render, otherwise the snapshots would be updated by overviewer.

If you were interested in following this up yourself, an easy way to start would be to have a dynamic config file, rendering the world into dated folders. If you used rsync to copy+hardlink the previous render to the new folders, you should have minimal issues presenting the snapshots. Then you can create custom web assets to present the worlds in a suitable manner.
What might be useful is for Overviewer to support an option in the renders dictionary that allows a world to be skipped during rendering (i.e all of your historic snapshots), but still included in the javascript. Not sure how feasible that part is, but it's probably more feasible than trying to put all of the functionality into Overviewer itself.

@pironic
Copy link
Member

pironic commented Jan 23, 2013

I am going to close this issue as it is in regards to a discussion about a non-master branch feature. Although we encourage such discussions, we would prefer they be opened on the Addons repo. Thank you for the suggestions... If you'de like to continue discussion on this feature request, please click the link to the Addons' issue above this comment. Thank you for contacting the Overviewer Development Team.

@pironic pironic closed this as completed Jan 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants