-
Notifications
You must be signed in to change notification settings - Fork 480
Ideas for Major Changes
This is a page to list ideas for changes we want to make to Overviewer, but may be very large or may break backwards compatibility with old maps.
Note: Breaking backwards compatibility means that existing maps will not look the same as newer maps. For small worlds, this shouldn't be a problem, since the time to re-render and entire map will be small. However, for larger maps, the time to re-render may be prohibitively long.
A GUI would be nice for those less enlightened CLI-capable, or on Windows. There is/was a wxWidgets mockup done by agrif but the current status is unknown. Ideally any implementation of this would be cross-platform compatible.
eminence is also working on a QT version. It is functional, but missing some feature.
Probably better called "multi region-set support", we need to support related region file sets (like overworld + nether + new sky dimension), ideally with some way to switch between the related areas in javascript (i.e. clicking a portal in overworld takes you to corresponding location in Nether).
For those with very large maps, or someone looking to setup a general map rendering service, it would be very cool to be able to distribute the rendering work load to multi machines. This could tie into the continuous update/render idea below.
Running Overviewer every time you want to update can run into interesting issues with large worlds (or small worlds on low-power machines) where you are doing a lot of work checking unchanged tiles just to get through a partial render. One way to solve this would be to do continuous rendering, where Overviewer would render all the initial tiles, then recieve only a list of regions that change as they change (either via a Bukkit plugin, or some other mechanism) to eliminate the overhead of Overviewer scanning for changes itself. There was some initial work to this end done by MrSheen here: https://github.com/mrsheen/Minecraft-Overviewer-Mega but this is fairly unstable.
Making additions to Overviewer is fairly awkward currently, it would be nice to streamline this for the end users. Note that there are a couple of different areas plugins could affect and a good plugin support system should account for these. Such as a pure JS plugin that only affects rendered maps, a plugin that has both Python and JS components and so needs to hook into overviewer_core, possibly a plugin that adds a completely new rendermode?
We should strive to make overviewer as fast as possible. Pigmap produces very similar output, but runs much quicker. We should try to achieve pigmap-like speeds (even if this means re-writing some code in C/C++) --eminence
One idea for this is to reduce (or provide an option to reduce) the detail of the closest zoom level. Right now Overviewer lets you zoom in really close, which is great, but reducing this detail by just a factor of 2 (one zoom level) would improve render speeds considerably for those who want this tradeoff. Suggested by ArmEagle in Issue #244 -- agrif
Or the ability to specify a maximum and a minimum zoom level. Then like chunklist you can render updates for a specific zoom level. -- BarryCarlyon
How about GPGPU using pyCUDA? You could move all the worker processes to the GPU which has far more cores than a CPU does. It would at least speed up the process on nvidia graphics cards. -- CounterPillow
Right now the default (no biome info) colors for grass, leaves, etc. are hardcoded, which doesn't look quite right when using a texture pack. Getting this info from grasscolor.png (etc.) would prevent this, but break the current map colors. Also, generic .zip texture pack support would be nice. -- agrif