Fix node-nodebox lighting difference in direct sunlight

[numberZero]

Fixes smooth lighting part of #7040

1. In getSmoothLightCombined (which is called for each corner of the node), it now checks for direct sunlight (light level of 15). If it is detected, full brightness (255) is used instead of the average. Then, ambient occlusion is applied, if necessary; otherwise it returns 255 for the day light bank.
2. MapblockMeshGenerator::getSmoothLightFrame checks for that value and marks the corresponding corner and its bottom counterpart (for convenience) as exposed to direct sunlight.
3. MapblockMeshGenerator::blendLight now calculates two values for the day light bank: a base light value (used for sides), computed as usual, and a boosted value (used for sun-facing quads), computed considering marked corners as having full light.
4. LightInfo::getPair blends these values using given factor, for which dot product of sun direction (0, 1, 0) and face normal, clamped to [0, 1], is used. This way, sides and bottom faces are not affected, but top faces get full sunlight. This feature is only used for nodeboxes and mesh nodes.

Note: lighting settings on screenshot are extreme to make defects, if any, more noticeable. That’s the reason for such dark shadow.

[Fixer-007]

Do I need to apply 7051 as well?

[numberZero]

#7051 is for flat lighting. This one is for smooth lighting. They happened to be completely independent.

…

On Wed, Feb 21, 2018 at 03:16:28PM -0800, Fixer wrote: Do I need to apply 7051 as well? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #7061 (comment)

[Fixer-007]

Checked this PR in game, it fixes my problems with smooth lighting (on snow and slab+full) 👍

[paramat]

From IRC http://irc.minetest.net/minetest-dev/2018-02-20#i_5234396

16:05 numzero okay, now #7061 works for nodeboxes and meshnodes; other cuboid-using nodes (framed glass) are affected but should be fine as well
16:05 ShadowBot #7061 -- Fix regression after #6696 by numberZero
16:07 numzero I saw a glitch on extreme settings (lighting_beta=4.0 and plain white texture) but even in such conditions it is barely noticeable
16:07 numzero it also may be GPU-specific
16:08 numzero as it is fixed by moving one multiplication from the vertex shader to the fragment one (with unlimited precision, that move would not change anything)
16:10 numzero but without shaders such change is not possible ofc
16:12 numzero note that it doesn’t affect flat lighting, my previous PR fixes that

[paramat]

Don't understand how the code works but will test.

[paramat]

Please can you help reviewers by explaining in the first post what this does, how it works and why it works this way? We're short on reviewer time and available reviewers may not be good with this area of code, if i understand how this works i may be able to +1 it.

[numberZero]

@paramat Done. I should probably document that in the source briefly, though. UPD: done that as well

[paramat]

Sorry for delay, i will test this as soon as possible.

[rubenwardy]

Change set looks good, although I'm not familiar with this area of the code

[SmallJoker]

Side-by-side comparison using the default settings:

Looks much better now.

[paramat]

Tested your branch, there is a bug with smooth lighting disabled but i assume that's because #7051 is not included in this branch.

With smooth lighting and a white snow texture, snow slabs next to snowblocks, identical whiteness:

[paramat]

^ Facing W

^ These lines align to NW-SE (player facing NW)

Ambient occlusion is different for different corners.

[paramat]

Maybe i should test master plus your patch instead.

[paramat]

Applying patch to master, same appearence, all else looks fine though:

[paramat]

In master appearence is the same, so this is not caused by your mod:

So this PR tests fine.

[numberZero]

Ambient occlusion is different for different corners.

@paramat It isn’t. Each quad is drawn as a pair of triangles (check the wireframe view), and the same diagonal is used for that split, regardless of node position; that is, it is aligned identically relative to the world, but therefore differently relative to the corners. That’s not a (new) bug if these are slabs; there was some code to choose the diagonal based on lighting to make gradients look nicer, but it was for fast-faces (solid nodes) only. It might be possible to do the same for nodeboxes, however.

[paramat]

Yes i suspected that was nothing new, good to know thanks.
Your PR tests fine then, will look at code again.

[paramat]

I'll look at code then will probably +1 and merge it.

[paramat]

Thanks to your description i have a rough understanding of this.
👍

[nerzhul]

Merged, thanks