Suggestion: Block height fading

[leth]

Our server admin hacked in a small feature to the renderer which slightly reduced the saturation of the textures as the blocks got higher up.

It helps distinguish whether something is above another which is often hard to see from 2D perspective.

Give it a try, and see if you think it's any good :)

[eminence]

this sounds neat. can you provide an example of how it looks?

[leth]

Alas we don't have any screenshots saved. I'll keep you posted if we find anything or revive the hack.

[leth]

I've had a look at the libraries and it'd need ImageEnhance.Color adding to lines 578, 583 and 588.

Something like this:

  img.paste((0,0,0), (imgx, imgy), ImageEnhance.Color(ImageEnhance.Brightness(facemasks[0]).enhance(black_coeff)).enhance(???))

Where ??? is some function of the block height.

[leth]

Ok, I implemented it and got some screenshots:

• http://imgur.com/vKwtu.png lighting, original
• http://imgur.com/AQbiM.png lighting, with fade
• http://imgur.com/KfuZm.png no lighting, original
• http://imgur.com/IOwpd.png original, with fade

The non-lighting mode looks rubbish, but I've not got the time to improve it. The fading function might benefit from some tweaking for more built-up (higher) maps. I don't have any saves of that kind on my laptop to test it on.

Here's a diff of my changes: http://pastie.org/1287326

[nickistre]

I've incorporated leth's patch into my dev branch ( https://github.com/nickistre/Minecraft-Overviewer/commits/dev ), though I'd like to create an optional flag (probably with --heightfade or the like) along with the other cleanups. I like the idea, though.

[irowboat]

Any chance of something a little more along the lines of Donkey Kong's adjustment to Zahl's mcmap?

http://www.minecraftforum.net/viewtopic.php?f=25&t=40327&start=30#p772477

[alexjurkiewicz]

Was that range chosen so the most change happened near sea level, and progressively less the higher/lower you get? I like the idea, but if the equation wasn't consciously tweaked with that idea it can probably still be improved.

[nickistre]

Irowboat, I've created a new branch dev-heightmaplog by changing the fadecoeff formula to something like the following: (1/(1+math.exp(-1(1.3_z/16)+6.0)))*.3

https://github.com/nickistre/Minecraft-Overviewer/tree/dev-heightmaplog

This seems to slow down the render, so I don't have a sample yet to compare to yet. I did plot that function compared to leth's original function and it looks promising: (-128 <= x <= 128, -0.25 <= y <= 0.5; red it leth's original function, purple is the one I made above) http://dl.dropbox.com/u/424679/Pictures/other/para_vs_exp.png

(I'm not very familiar with python yet, so I'm hoping this works... ;) )

[irowboat]

Since brightness in Minecraft only really comes into play in the transition from surface to cave, visual differentiation at mapping distances relies mostly on saturation and hue. Losing saturation leaves only hue, which means grass and trees approach looking the same (depending on your terrain.png), losing definition.

Looks like mcmap seems to lower the brightness progressively the lower the landscape, retaining the saturation.

[leth]

Nice find guys, the logarithm scale looks wayy better in those pics. The range was tweaked so that most change happens at high altitudes.

The patch I posted changes the brightness, I tried other effects but they didn't seem noticeable enough at the time. It's probably worth trying them out again though.

[Fenixin]

Using nickistre's branch and a very similar function to Donkey Kong posted in forums, I've made a fork with a very similar aspect to the Donkey's adjusment. The used formula is:

fade_coeff = (1/(1+math.exp(-1.(z-70.)/11.)))0.6-0.55

Which has the form:

http://imgur.com/07JJA

Negative zone darken the image. And the results are:

http://imgur.com/v15fv

http://imgur.com/PSR8U

I think the code is well commented and simple, it's just a few lines to the chunk.py, so could be easily merged, but I'm not really a programmer so, please, look at it, test it, and if you can, improve it.

[Fenixin]

Seem to works also in night mode:

http://imgur.com/OdpAg.png

http://imgur.com/Sbjcm.png

[nickistre]

Fenixin, I've taken your ideas it into my test branch now. I've also streamlined how it figures how to add black or white based on fade_coeff <0 or not.

I've also separated the code out so that I can quickly do tests, like possibly doing desaturation or blurring based on height. Also, this puts in place a way to set which formula to use based on arguments passed in from the user or a script.

[Fenixin]

Great!

Before I posted that formula a tried a few formulas (sqrt, lineal, constant+lineal (picewise fuction), log, exp), and I think the Donkey Kong's one is the most beautiful. You have most of change of brightness in the interesting zone, and changes light smoothly.

Also, I experienced that light the map more than 0.05 make it quite ulgy, like foggy, however darken it (up to 0.6) doesn't affect the "beauty" of the map. But maybe this is a bit personal :)

[Fenixin]

I'm thinking on this. What about a new option? "--height-fade "? I think by default should be off. Opinions? Ideas?

[alexjurkiewicz]

Don't allow users to specify the formula, down that path lies madness. Hardcode the best.

[Fenixin]

Yep, but a list of hardcoded formulas is easy, no? Something like: log, log2, lineal, exp...

[nickistre]

My test branch now has a new command-line option "--heightfade". Setting which function to use is simply like adding "--heightfade=log2". The available functions are pulled from heightadjust.py.

I'm sure how I did this is completely wrong and ugly, but I do have it working. I'm going to do rebase of brownan's master so I can figure out what I actually did between merging of various branches... :)

UPDATE: Rebase finished, and I fixed some bugs I introduced while resolving several conflicts. This is available in my rebase-brownan-master-2 branch, which I will probably setup to be my pull request.

[Fenixin]

Great! thanks for this, I really want this feature.

I've just tested and it doesn't seem to affect trees:

http://imgur.com/ob812 (log formula, no biome data)

http://imgur.com/whz8y (same)

Also an idea on this. We are calling composite.alpha_over 2 times per side, that's 6 times in total. One call y for light and the other for the height fade. We can reduce this to 3 calls lighting up the textures the necessary amount in textures.blockmap and textures.specialblockmap, and then darken it once in the chunk render pass. What do you think? Will it be significant the speed improvement? Thoughts? I'll do it if it's ok.

[nickistre]

I had noticed the trees not being affected. I do remember some of the code I had worked on had trees working and I'm looking through my git history to figure out where it had changed.

UPDATE: Go ahead if you have some ideas of speed improvements. Really, you don't need my permission; I don't own the code... :)

UPDATE 2: I think I found the commit where the trees not being faded issue was introduced: when I merged in changes from upstream on Dec 24. These changes seem to be several improvements on cache checking? I'm going to verify I found the right commit for now; I'm not sure if the test map I was using has the elevation changes that will highlight changes in tree colors.

[nickistre]

Confirmed that I found the right commit in my test branch. I've tagged that one on my fork as "nickistre-tree-first-bad" and my commit right before that one as "nickistre-tree-last-good". Basically, the merge I did in first-bad looks to be what broke trees:

https://github.com/nickistre/Minecraft-Overviewer/commit/7f1989e247b10ded0644b4223a3a750ac8f57bce

This happened before I started my work on exposing a command-line option, so hopefully I can re-integrate that once we figure this out.

[Fenixin]

I was asking for opinions, because I don't know if the improvement is going to be significant.

Also, I can send you small maps with mountains, just send my a message.

[irowboat]

Just upgraded to the current DTT version of overviewer, and discovered much to my dismay that the fading (ala Donkey Kong as mentioned above) is no longer working, but I'm not sure where to hack in the changes now, since it's been several months since the last activity here. I'm sad that this lighting is not one of the rendermodes.

[Fenixin]

If we implement this... should it be a different rendermode? Should we add the rendermodes: night-hightmap, normal-hightmap, lighting-hightmap? Or is this spam rendermodes? This is pretty easy to add with the new rendermodes code, but I'm not sure how to implement it so it make sense.

[agrif]

@Fenixin, I've been tossing around ideas on how to add configurable options to existing rendermodes. Summer vacation is coming up for me, and then I'll have time to actually write the code.

You could implement height-fading as a on/off option for the normal render mode, which would then automatically apply to all other modes derived from it (basically, everything but overlays).

Rendermode options are really cool for other things (like the mineral overlay), so I think this would be a neat way to implement this.

[pironic]

@agrif, i love this suggestion, maybe another option for the settings.py?

[agrif]

I've just added a _heightfading option to the normal render mode on my rendermode-options branch, using Fenixin's exponential-based formula. Here's an example render:

http://overviewer.org/heighttest/

This render was generated with the following settings.py:

rendermode = ['normal', 'normal-height', 'lighting', 'lighting-height']

custom_rendermodes = {
    'normal-height' : {'parent' : 'normal',
                       'description' : 'normal mode, with height fading',
                       'options' : {'height_fading' : True}},

    'lighting-height' : {'parent' : 'lighting',
                         'description' : 'lighting mode, with height fading',
                         'options' : {'height_fading' : True}},
}

rendermode_options = {
    'lighting' : {'edge_opacity' : 0.5},
}

rendermode-options will be merged into master eventually, since it also closes a ton of other issues like this one that involve minor tweaks to existing render modes. It's undocumented right now, but fairly stable, and docs will be written sometime before it's merged.

I'm not set on this particular formula for height fading. If you want to play around with it, it's as simple as changing this line and recompiling.

[pironic]

@agrif, Looks like overviewer.org's terrain.png is outdated...

As for the look, I like the idea a lot, however, I'm not sure if I totally like the formula yet. I think we can do better... No suggestions yet though. The higher the elevation, the more it looks like we are playing half-life with max gamma. It drowns out the detail.

[agrif]

rendermode-options has been merged, including the height-fading option, so I'm closing this.

[leth]

Awesome :) Thanks.