spoutn1k/mcmap

Re-introduction of height gradient

Ayleids opened this issue · 15 comments

Is it no longer possible to bring this back? Zahl originally added shading (skylight), but it's no longer present in the updated version of mcmap.
1 12 render
new version 1 12 rende

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.

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

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?

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.

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 ?

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/

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

Thanks 💯

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

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.

Awesome! Looks great.

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.
strange
As the user who requested the feature, do you have preferences ? Or did you just want a darker image ?

Zahl commented

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.

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.

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