Lighting API features

[Athozus]

Problem

Recently, we got many visuals improvements, such as dynamic shadows, and more are upcoming, according to the milestone. However, creating light sources itself is still weird, on many points, notably for entities.

Solutions

Here are my proposal features/changes. A day or not, I'll work on it. But, if someone else does it, that's 100% okay.

• [ ] lightning_box, following the syntax of collision_box and those. However, we should be able to change the lightning box during the game, or at least make "pre-configurations". It presents many advantages.
  1. First, not all your block is lighted. For example, with an advtrains signal, only the color itself should emit lit, not the black borders.
  2. Secondly, it should significantly reduce the number of nodes in the game. To take again the example of advtrains, just switch to another configuration to let the green signal emit light and the red shutdown. Also for works for many lamps (mesecons, morelamps, digistuff...) that are registering a lot of nodes.
  3. Thirdly, it will emit light in the color of what's wanted. Again, example of an advtrains signal. It is more realistic to get a red/yellow/green light (and also on walls, get green-colored walls is better). Related : #2670
• [ ] Entities/bones emitting lights. Probably one of the most wanted features of mod developers. Can't enumerate how many aliases of default:air.
  1. We should be able to give to bones a light value like with nodes. Will be very useful for moving lamps (on vehicles such as APercy planes), for example.
  2. At contrary, some bones should brake the light, the body of a vehicle for example.
• [ ] A new parameter for lighting nodes (and also bones if above is accepted). Take an irl metro tunnel. The lights on the tunnel are emitting very-white light, but for only 2-3 meters. Currently I'm almost sure we don't have that, but I think this is a low-priority feature compared to both above. Related : #14717
• [ ] Reflected lights should get some properties of nodes/entities whose reflected these.
• [ ] As far I know, refraction isn't implemented. This could be another visual improvement.
• [ ] EDIT: I forgot to tell about dynamic shadows, sorry.
  1. Artificial light sources should generate dynamic shadows.
  2. Several shadows should be created for each entity (one per light source, approximately, think about irl).
  3. Shadows should overlap themselves. When two shadows are overlapped, it creates a darker shadow (irl)

Alternatives

• If solutions above aren't accepted (np btw), another solution would be to refactor the light propagation. I don't really used it so I'm not an expert, however I think some physics could be improved.
• The problem of limited registered nodes is a problematic for nodes that could have different lights behaviors. Again, if the solution of a lightning_box is not confirmed, we should find a solution to "merge" some nods that just differ of light values. This takes a part of the resources, so it affects performances.

Additional context

Thanks for reading all the message =) Note that I'm most an ingame coder than a mod developer, however I already made some edits on mods.

[hecktest]

Shadows should overlap themselves. When two shadows are overlapped, it creates a darker shadow (irl)

This isn't what happens in real life, what happens in real life is that light is combined additively rather than shadows being combined subtractively.

[Athozus]

This isn't what happens in real life, what happens in real life is that light is combined additively rather than shadows being combined subtractively.

Yes, thanks for the precision. That should be taken in account for the coding of it.

[Athozus]

@y5nw suggested me in a Matrix discussion to add the following parameter : lighting_direction, which is a good call I think.

I don't really know how this would be defined, I'm not a physicist (only 1st year of studies), but I would in the first place propose a lighting_vector then a lighting_angle which would be the range around the vector, which would be the « middle ». But I'm waiting for better physicists than me.

[Athozus]

And a small patch to apply to @APercy's PA28 if you'd like to test the light_source for entities (I've tried small things but didn't spend much that time) :

The patch

```lua diff --git a/entities.lua b/entities.lua index 7ecfc28..beb5f91 100644 --- a/entities.lua +++ b/entities.lua @@ -39,6 +39,7 @@ minetest.register_entity('pa28:p_lights',{ collide_with_objects=false, pointable=false, glow = 0, + light_source = 0, visual = "mesh", mesh = "pa28_lights.b3d", textures = { @@ -66,6 +67,7 @@ minetest.register_entity('pa28:light',{ collide_with_objects=false, pointable=false, glow = 0, + light_source = 0, visual = "mesh", mesh = "pa28_light.b3d", textures = { diff --git a/init.lua b/init.lua index 7cda764..6da0a63 100755 --- a/init.lua +++ b/init.lua @@ -55,15 +55,15 @@ end function pa28.step_additional_function(self) --position lights if self._engine_running == true then - self.lights:set_properties({textures={"pa28_l_light.png^pa28_l_light.png","pa28_l_light.png","pa28_r_light.png"},glow=15}) + self.lights:set_properties({textures={"pa28_l_light.png^pa28_l_light.png","pa28_l_light.png","pa28_r_light.png"},glow=15,light_source=8}) else - self.lights:set_properties({textures={"pa28_l_light.png","pa28_l_light.png","pa28_r_light.png"},glow=0}) + self.lights:set_properties({textures={"pa28_l_light.png","pa28_l_light.png","pa28_r_light.png"},glow=0,light_source=0}) end if self._land_light == true then - self.light:set_properties({textures={"pa28_landing_light.png"},glow=15}) + self.light:set_properties({textures={"pa28_landing_light.png"},glow=15,light_source=8}) else - self.light:set_properties({textures={"pa28_metal.png"},glow=0}) + self.light:set_properties({textures={"pa28_metal.png"},glow=0,light_source=0}) end if (self.driver_name==nil) and (self.co_pilot==nil) then --pilot or copilot ```