shadow problems
Gorderok opened this issue · 7 comments
Dynmap Version:** 3.4-beta-3
Server Version:** 1.18.2
Hello, there are always problems with the shadows.
@mikeprimm bump as this looks like a render problem, you might know a way to fix this?
Not seeing this for properly current and lit chunks: example from 1.18.2:
Unfortunately, here's the deal: vanilla minecraft, for a few releases, has seen fit to discard lighting data in chunks that have not yet been FULLY updated to the current version's format. Chunks have several 'states' they go through (versus just the 2-3 that they had for most of MC's history), and when an existing chunk gets pulled in at a distance from a player OR if you use the 'migrate' command line option, it doesn't REALLY migrate the chunks - it updates them to the new format, but rolls back their state to before lighting is done (which is one of the last states out of like 7) and throws away the perfectly good lighting data. Then until the chunk is driven through the remaining states (generally meaning that a player is within about a 5 or 6 chunk radius of the chunk, OR if a tool like WorldBorder is used to drive chunk lighting to be generated), there is no lighting data. This was why lots of folks, after version upgrades, used to see Dynmap problems with 'black borders'.
I've implemented logic to come up with very basic lighting when a chunk lacks lighting (which is why your examples aren't all dark or all light), but I cannot and will not waste time and compute resources writing code to attempt to replicate the (frankly poor, buggy, and computationally expensive) lighting model of Minecraft chunk processing - when there are other tools to drive lighting refresh that keep Dynmap out of the 'potentially destroying world data' business of bypassing vanilla chunk generation and management.
Sorry if this isn't the answer folks might prefer, but it is the only one I've got. If you don't like the shadows, turn off the lighting on the map (e.g. noshadows for lighting).
That's exactly where you see in the picture. In the picture, players were there very often and a radius render was done several times after that. I can make new pictures, but these would show exactly the same.
I am not sure if this is really the problem. The chunks in my picture have been fully updated to the latest version of the chunk (with chunky and player on this place). Also I used the light cleaner to make sure that lighting data is generated. You can see the result on my last picture.
Do you KNOW that 'light cleaner' drives the lighting to be regenerated immediately, or that it only marks it as invalid and causes vanilla to regenerate it once the chunk is loaded by normal activity. Or (looking at https://github.com/bergerhealer/Light-Cleaner), that the lighting is being generated by a non-vanilla process that doesn't necessarily produce equivalent results (this code looks like it implements its own lighting algorithm, versus driving vanilla lighting, but I could be wrong). If you send a player over to the same location, in game, grab a screen shot of the in-game view, and THEN rerender the section of the map, I'll look at the difference you see under those conditions. Please don't show me an area where the lighting was generated by some other tool - I render based on the lighting data in the world data, and when it's incorrect, I'm not in a position of fixing it - and vanilla generated lighting is the definition of 'correct'.