As per the note on Discord, water blocks that are surrounded by other blocks don't look right.
This is obviously because the rendering isn't done when a block is fully enclosed. However, due to the 'height' of the water block, that idea doesn't float.
HAHAHAHA see what I did there? :D
ahem
See this pic in case you've been hiding under a block.

Thanks for the report @misterHippo 馃挌
Can confirm this is an issue with the engine:loweredCube shape with occluding blocks. The same effect happens when placing CoreBlocks:Dirt:engine:loweredCube the same way (give dirt 16 loweredcube).
It does not happen for engine:halfBlock though, not sure what the difference is. Should be fairly simple to debug and fix.
For a bit more historical background: water is a bit of a special case as it is meant to not appear flush with the block line at the _surface_ of the body of water - that's why it uses the lowered cube shape. However it'd look silly if every layer of water had a little gap at the top, so there's some special handling for that somewhere. That might be what causes some quirks around other related cases.
Hi there. Is this as simple as adding a check in BlockMeshGeneratorSingleShape?
In the isSideVisibleForBlockTypes method I tried adding a conditional of if the block above is not water return true for this block. I can open a PR if that sounds fine. I was trying to follow the new contributor guides but wasn't sure where to ask questions first.
Before:

and After

Hi @cvennel ! This is fine although our Discord is sometimes better as it is easy to miss all the GitHub notifications.
If that fixes the problem then that's probably fine for a PR already :) Maybe we need to improve the setup further (for instance for things other than water), but if this fixes the initial bug then we can submit an issue for further refactoring later. That might be a much bigger task.
Thanks @Crevator, I'm lurking on the Discord but wasn't sure which channel to try. I've only started looking at the source today so I'm not really sure what other conditions may need to be accounted for but this should help specifically for water under not water at least :) Looking forward to getting more involved!
Closing as fixed by #3911 ! Thanks @cvennel :-)
@misterHippo this should now be available along with other recent fixes in dev build 1086 via launcher
@Cervator I think the fix was kind of temporary so It would be better to keep this open until there is a more ~temporary~ permanet solution or would it be better to make a new issue.
The issue is fixed as written though. It doesn't talk about refactoring the overall logic in general, which is what we need. We _could_ add that here, but might as well write that as a new issue to keep things less confusing ... :-)
I found and linked https://github.com/Terasology/FlowingLiquids/issues/7 to this for relevance, am happy enough to have that reminder as it would be nice to just move toward where that'd be the implementation for "nice" water 馃憤
Going to close this again and deal with the further refactoring elsewhere, maybe by elevating the role FlowingLiquids will play. Going to get into the partial block stuff liquids there for sure.
Most helpful comment
Thanks @Crevator, I'm lurking on the Discord but wasn't sure which channel to try. I've only started looking at the source today so I'm not really sure what other conditions may need to be accounted for but this should help specifically for water under not water at least :) Looking forward to getting more involved!