Note 1: this issue is independent of the general brightness of the player’s view underwater reported at (MCPE-55701).
Note 2: this issue does not occur with vibrant visuals enabled.
When the player is underwater, the sky light level at the player’s position affects the illumination (visual light level) of all blocks seen through the water. This is different from how illumination works when the player is not underwater, where the block light level of the blocks themselves determines their illumination. This affect of sky light is unrealistic and unintuitive.
Steps to reproduce
Set graphics to fancy.
Set time to day
Place a light-emitting block at the bottom of the ocean
Slowly move up and down in the water per the video below.
Expected result
The blocks on the bottom of the ocean are always dark except around the light-emitting block.
Observed result
When the player goes underwater, the blocks on the bottom of the ocean illuminate based on the player’s sky light level, i.e. inversely with the player’s depth.
Water is supposed to block sky lighting and get it to decay by 3 for each block to eventually 0, meaning it should be dark at the bottom at the ocean. However, this is not how water is currently behaving.
I have included two screenshots showing how I'm clearly able to see the bottom of the ocean at day time when swimming at 1-3 block deep under water like I'm having a night vision effect (screenshot on the left), and, when going deeper, everything slowly becomes dark and turns back to what it's supposed to look like (screenshot on the right).
Nonetheless, it's only a visual bug depends on where the player is underwater and it's less noticeable at night time.
The expected behavior:
Whatever the light level is (underwater), it should stay consistent wherever the player is.
This issue existed since the Aquatic Update and is yet to be fixed.
Steps to reproduce:
Open World
Set time to day
Find a deep ocean
Go underwater one block deep, and then slowly go deeper.
You'll notice how deeper levels of the water is going slowly darker, until you go deep enough and it'll stop.
Linked issues
Attachments
Comments 32
Confirmed: the illumination of blocks underwater is determined first by the sky light level at the player's position. The block light level of the blocks themselves is only visible if it is greater than the player's sky light level.
[media]
That is similar to the lighting issue with chest minecarts, MCPE-22533. It also relates to the general problem with water lighting being too bright and affecting non-water blocks based on the player being in water, reported at MCPE-57701.
One thing I'd like to mention is that it doesn't get dark enough underwater even at night time. I still can clearly see the bottom of the ocean without the need of other night sources even at night time. I think it's mainly because there isn't much difference between light level 15 and 0 underwater OR it simply doesn't reach light level 0 underwater.
Reply from @unknown: that's the issue tracked at MCPE-57701.
This bug is still present in preview 1.21.80.25.
This bug is referenced, but not linked in the “Known Issues” section of 1.21.80.25’s Minecraft.net article.
This bug is connected to MCPЕ-57701, which details how a sort of unlisted night-vision effect is granted to the player in Bedrock Edition anytime they are under water.
With this bug, elevation affects the intensity of this night-vision effect.
This bug should be considered a parity issue, as this behavior does not exist on Java Edition.
Artlees: this issue is not what the 1.21.80.25 Preview changelog referred to in stating that surfaces 8 blocks or more underwater were dark in vibrant visuals. Indeed, this issue does not occur in vibrant visuals at all. This issue is also not causally connected to the “water vision” described in (MCPE-57701). Please see my comment from October 25, 2020, and and other comments where I distinguished the two issues. In particular, the player’s elevation is not affecting the “water vision” effect. This bug is independent of (MCPE-57701).
This bug is too old to qualify for the vanilla-parity label. The java-parity label is used only for bugs where the parity difference is the main factor in what makes us think an issue is unintended. That is not the case for this issue. This bug simply does not make sense on its own.
I think it is not a bug, I think this is supposed to be like this