Re-introduction of height gradient about mcmap HOT 15 CLOSED

Minecraft's internal structures changed greatly and I overhauled the whole rendering process, but haven't gotten around to re-implementing skylight. It should be feasible though, at the cost of some performance. However, I fail to see where in your example skylight is used; the map is clearer as I removed a darkening bit of code at rendering time.

from mcmap.

Also, did you disable block-types ? It looks like the new map is missing a lot of details.

from mcmap.

However, I fail to see where in your example skylight is used; the map is clearer as I removed a darkening bit of code at rendering time.

Do you know how to get this darkening effect back?

from mcmap.

Also, did you disable block-types ? It looks like the new map is missing a lot of details.

I was just learning how everything worked and went all the way back to your "virus induced project pickup" when I rendered the second image. Should of been more specific.

from mcmap.

Do you know how to get this darkening effect back?

By darkening effect, are you talking about the slight gradient on the Y axis by any chance ?

from mcmap.

If you look at the first image it's darker overall. Personally I prefer how it looks and wanted to know how to bring that back. I'm a player from an old Minecraft server that up until recently used mcmap and we haven't been able to update the map since minecraft 1.13. https://qkzskrbbwbkyw3lacbvz9w-on.drv.tw/MCTAW%20MAP/

from mcmap.

It's darker on the lower blocks and lighter on top. I'll take a look when I have some time.

from mcmap.

Thanks 💯

from mcmap.

Also, try the latest commit. I sourced the official colors and the resulting map is a bit darker.

from mcmap.

So I slapped the old code back into the project in a new branch, and I have mixed feelings.

It takes twice as much time to render as it invalidates optimizations I made, but it does make it easier to distinguish between heights. I'll merge that if I manage to make it faster, but the 2x performance decrease is a no from me.

I plan to finish what Zahl started and implement "ray tracing" to optimize terrain and render only visible blocks, and this would greatly benefit from it. With this functionnality 90% of the rendering time is spent adjusting colors that will end up overwritten.

from mcmap.

Awesome! Looks great.

from mcmap.

Looking at the code, the brightness pattern follows some kind of convoluted formula, looks like to shade only the underground parts. I feel like shading the overworld is even more important, to distinguish the top of mountains next to the background. Plus it makes the nether look kinda strange.

As the user who requested the feature, do you have preferences ? Or did you just want a darker image ?

from mcmap.

Hi :-)

Zahl originally added shading (skylight)

I think this was another feature, the -skylight switch, which read the actual skylight information from the map file, plus some ugly code to fix bogus lighting information, which happened quite a lot in older map saves. This properly showed shadows unter trees and huge platforms etc.

I feel like shading the overworld is even more important, to distinguish the top of mountains next to the background.

This is what that formula does. It's not linear as to not "waste" gradient on the underground. As you can see from the nether, blocks below ~60 have almost the same shade at all levels. Between 60 and 128, the gradient is quite steep, giving mountains (like the snow covered ones in the first screenshot) some more depth. Above 128 there is no change, since this formula was designed in the alpha days where you could only build to 128. This still makes sense for the default worldgen options though.

Of course as you said, that feature isn't useful for the nether and other realms, but again, these didn't exist when it was introduced, and I never thought about disabling it for those when they were added.

There is another feature added to help with making hills look a little nicer, which is making blocks a bit brighter if there's nothing "behind" them, i.e. it's going downhill from from to back from the camera's POV. (Don't know how to properly describe this.) From the screenshot above it looks like this is actually still present in the current version.

from mcmap.

Hey :)

It's not linear as to not "waste" gradient on the underground.

I see. Now this is a tough situation because this is aesthetics, and everybody has different tastes. I personally build underground a lot, and this just makes everything darker. Some people love mountains, and it makes everything way sharper.

From testing I got some more nice looking results with a linear shading profile, which were not as strange as the inverted exponential one in the other dimensions. I might switch to that, as I feel it is more relevant now with 255-high worlds and other dimensions.

There is another feature added to help with making hills look a little nicer, which is making blocks a bit brighter if there's nothing "behind" them, i.e. it's going downhill from from to back from the camera's POV. (Don't know how to properly describe this.) From the screenshot above it looks like this is actually still present in the current version.

I did see that in the legacy version, but it has not been reimplemented. The world is now rendered on a per-chunk basis, so checking for surrounding blocks is kinda awkward on the edges.

from mcmap.

Shading added in main branch with #39. Make sure to use -shading to toggle it !

from mcmap.