[no squash] Make static world lighting (light curve & AO) configurable via API

[sfan5]

closes #14900

Demo video of switching between the normal and Minetest 0.3 light curve:
https://0x0.st/KW6c.mkv.mp4

To do

This PR is Ready for Review.

• AO gamma

How to test

randomized light curve every 5s:

local xtimer = 0
core.register_globalstep(function(dtime)
	xtimer = xtimer + dtime
	if xtimer >= 5.2 then
		xtimer = 0
		local c = {math.random(0,128+64)}
		c[16] = math.random(128-64,255)
		for i = 2, 15 do
			local frac = i / 16
			c[i] = math.floor(c[1] * (1 - frac) + c[16] * frac)
		end
		local g = math.random(0,1000) / 1000 * 2.75 + 0.25
		core.chat_send_all(table.concat(c, ",") .. " | " .. tostring(g))
		for _, player in ipairs(minetest.get_connected_players()) do
			player:set_lighting({
				static = {
					light_curve = c,
					ao_gamma = g,
				}
			})
		end
	end
end)

fullbright toggle:

core.register_chatcommand("fb", {
	func = function(name, param)
		local player = core.get_player_by_name(name)
		if player == nil then return false end
		local c = {}
		if player:get_lighting().static.light_curve[1] ~= 254 then
			c = {254,254,254,254,254,254,254,254,254,254,254,254,254,254,254,255}
		end
		player:set_lighting({
			static = { light_curve = c }
		})
		return true
	end
})

[sfan5]

Question (not necessarily for this PR): should the server get to decide about smooth lighting or not, too?

[HybridDog]

Maybe this also closes #6509 (Feature Request: Night Vision.).

[kromka-chleba]

Question (not necessarily for this PR): should the server get to decide about smooth lighting or not, too?

This setting is not a setting that changes gameplay much and the only use case I see for it on the server would be enforcing certain looks of the game. Perhaps the server should only set the default value? Luanti's setting system also has its limitations so perhaps the best solution is leaving this a client-only setting.

[sfan5]

Maybe this also closes #6509 (Feature Request: Night Vision.).

You can use this to implement night vision, but a shader-based effect would be better.

[kromka-chleba]

Feature request: add a smooth transition/interpolation so that the transition is smooth.
This way we could implement the effect of eye getting used to light level changes in a seamless way, e.g. going into a dark cave from the outside world -> making shadows a bit brighter.

[sfan5]

Not feasible and we already have auto_exposure.

[ryvnf]

Can we make it possible to adjust the lighting color with this API as well? Also allow configuring natural and artificial light to have different colors?

Might feel out of scope for this PR, but I think we should account for that when designing the API to not end up with two different API that overlap significantly. To me it seems like going from this to full color configurable lighting is not very big.

Someone should ideally adopt #11060 also to make that look as good as possible.

[ryvnf]

I am in favor of having a 2D texture that is sampled for lighting color to make it as flexible as possible. It would have one dimension for artificial light and another for natural light. With the legacy OpenGL renderer removed this does not seem like that complicated of a change.

The advantages of that are that it makes it more flexible and makes it a very efficient/cheap operation to change the lighting color/intensity on clients as only the texture needs to be swapped and mapblocks meshes do not have to be regenerated (which is the case now as far as I know).

That would also allow for efficient blending/interpolation like @kromka-chleba suggested if that is desirable.

[sfan5]

This PR only concerns itself with making what I call "static lighting" configurable. "Static" because they're baked in the block meshes. That's also why we can't smoothly update it by blending or whatever.
All of these parameters already exist so this PR is purely an API feature.

I think we should account for that when designing the API to not end up with two different API that overlap significantly.

where's the overlap? The light curve/LUT maps a light level to an intensity and you can add configurable color to that later.

I am in favor of having a 2D texture that is sampled for lighting color to make it as flexible as possible. It would have one dimension for artificial light and another for natural light. With the legacy OpenGL renderer removed this does not seem like that complicated of a change.

That's possible, but we have left the scope of this PR by about 300 miles.

[ryvnf]

where's the overlap? The light curve/LUT maps a light level to an intensity and you can add configurable color to that later.

It is mostly that it feels like a limitation that it exposes how lighting is currently implemented as a array of lighting intensity values internally, which also does not include color. If one wants something more flexible (like what I proposed), then I would expect one to have to introduce a different API in the future, but then this one has to be preserved indefinitely for backwards compatibility.

That's possible, but we have left the scope of this PR by about 300 miles.

Would you support something like that? Because I have thought about trying to implement it along with adopting #11060. I would need to learn to work with shader code though.

It seems like a simple solution that would cover the use cases of both this and #16560

[ryvnf]

I tried doing a proof of concept, and it seems simpler to implement than I thought. It is mostly that I need to figure out how to expose a texture to the shader now.

Would you mind me making a PR to demonstrate the concept, before proceeding with this?

[sfan5]

It is mostly that it feels like a limitation that it exposes how lighting is currently implemented as a array of lighting intensity values internally

It is a limitation, but I don't see an use case where a linear mix (final_light = artificial_color * light_curve[i] + sun_color * light_curve[j]) isn't good enough. Do you have one?

I tried doing a proof of concept, and it seems simpler to implement than I thought. It is mostly that I need to figure out how to expose a texture to the shader now.

How are you separately passing natural and artificial light for each vertex? Did you change how the light banks work, also?
How do you plan to handle calls to decode_light in C++?

[Wbjitscool]

dose this allow for light level 15 for the future updates too oneday?

[sfan5]

You can set all light levels including 0 and 15.

[Wbjitscool]

cool so it won't ignore light level 15 for blocks no more?

[sfan5]

Nothing changed in that regard.

[Wbjitscool]

oh okay

[ryvnf]

It is a limitation, but I don't see an use case where a linear mix (final_light = artificial_color * light_curve[i] + sun_color * light_curve[j]) isn't good enough. Do you have one?

One limitation with that proposal is that you do not have separate brightness control for artificial and natural light. Another valid use case would be to have ambient lighting be a different color. Of course all these things could be resolved that by extending the API with separate light curves and other parameters, but that complicates the API further. Not being able to use different blending mode from linear RGB may not be an issue, but that is a limitation as well.

Other than that, there is hidden logic for lighting like this blue color emphasis in darker areas

luanti/src/client/mapblock_mesh.cpp

Lines 309 to 314 in f91e58a

	// Emphase blue a bit in darker places
	// Each entry of this array represents a range of 8 blue levels
	static const u8 emphase_blue_when_dark[32] = {
	1, 4, 6, 6, 6, 5, 4, 3, 2, 1, 0, 0, 0, 0, 0, 0,
	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
	};

If I wanted to make my own game have a unique look and differentiate myself from other games, it would be nice to have control over such parameters. Perhaps I want that blue emphasis to be stronger? Perhaps I do not like it or want darker areas to get a different color like purple? Having such non-customizable logic in the engine seems contrary to the roadmap goal of not hardcoding things.

With a lightmap texture, you could add slight color shifts in darker areas (like the current blue emphasis). You get full control of the color blending and can adjust brightness of natural and artificial light separately. The texture can also be swapped out for various effects like night vision with practically no runtime cost.

How are you separately passing natural and artificial light for each vertex? Did you change how the light banks work, also? How do you plan to handle calls to decode_light in C++?

I did not plan for changing light banks to be part of the POC. Ideally #11060 would be adopted as well, but that does not seem like a necessity at first.

Working with shader code proved to be harder than I expected. In any case, I think what I propose should be simple to implement. One just needs to pass the raw lighting data for each vertex and use that to sample from two 2D textures for night and day, then add blending in between depending on time of day.