Current light table is poor; suggested enhancement

[Calinou]

Currently, the light table is quite wrong. Torches suddenly attenuate for no reason; it's hard to light up large houses without using dozens of torches; sunrise is a bit dark. Here's an example of old lighting: http://i.imgur.com/7npiAXl.png

Upsides of this table is that it's much easier to light up caves and houses; it allows for creating seemingly brighter lights (lava feels quite brighter now). Light attenuation in caves remains scary, it doesn't make the game too easy. ;)

Downsides of this table is that currently, moonlight is too dark. This should be probably be fixed by increasing moonlight, but I have no idea how. Mods should also be tweaked to use lower light values as the new table makes stuff feel brighter.

Previews of the new table: https://mediacru.sh/5b6d3cae90bb and https://mediacru.sh/9f19a7deff7f The torches were using light level 11 on the screenshots. This allows mods to make noticeably brighter stuff than torches.

The light table can be found in light.cpp, starting with line 26. The first one is used by default, you should replace the values with these ones (with added comments as light values):

u8 light_decode_table[LIGHT_MAX + 1] = {
    17,  // 1
    34,  // 2
    51,  // 3
    68,  // 4
    85,  // 5
    102, // 6
    119, // 7
    136, // 8
    153, // 9
    170, // 10
    187, // 11
    204, // 12
    221, // 13
    238, // 14
    255, // 15
};

(n / 15) * 255 is the formula used to calculate the values. You may argue it's linear, but it looks quite right actually.

This change alone is probably not enough; not only moonlight needs to be tweaked, but lights on entities and non-solid nodes need to be updated (along with shader files, maybe).

Additionally, and optionally, make it so that modders can change the light table in Lua. If this is done, I'd still like this table to become the default.

[ShadowNinja]

If this was generated by a simple algorithm the algorithm should be used instead of the table, as it will be simpler and easier to maintain without slowing it down much.

[RealBadAngel]

algorithm cannot be replaced, while table can be

[SmallJoker]

I agree, the current lights are just too dark sometimes. This is an easy change and looks better than before.

[paramat]

The screenshots do look well illuminated, but a linear fall of light from a light source looks very wrong to me, thats just not how light and energy spreads, light falls with the square of distance, it should be at least a little exponential, which is what the existing table does, it might already be a balance between realistic and linear. I've been looking at lux ore nodes in dark fissures, and for a light source to look right there has to be a noticeable non-linearity. A linear table will result in weird results when placing lots of torches close together. Torches were darkened a little while ago and they therefore do seem dark, but that should not be used as a justification for linear lighting. In your screenshots, the cave walls away from the torches are too well lit, it loses atmosphere, and the areas close to the torches are not bright enough, making the torches seem very false. Exponential across 16 nodes does create rather short range light, but that's the result of light being limited to 16 levels or one mapblock in range.

[Philipbenr]

I do agree with you on this subject Calinou. I have noticed that increasing the light source value for torches and such was a temporary solution, but there are too many other things that are not bright enough.

[Calinou]

Exponential across 16 nodes does create rather short range light, but that's the result of light being limited to 16 levels or one mapblock in range.

It shouldn't be a pain to light up caves, especially when your hand's range is 4 blocks in the default game.

Alternatively, try some Minecraft-like exponential table, where each level is about 85 % of the previous one (80 % is the value Minecraft uses, which is likely a bit low).

[CasimirKaPazi]

One issue I noticed is that the caves, with no lightsource at all are quite bright. At least bright enough to find your way without torches. So I tried the formula (n / 15) * 255 - 15 + n which leads to this table

u8 light_decode_table[LIGHT_MAX + 1] = {
    3,   // 1
    21,  // 2
    39,  // 3
    57,  // 4
    75,  // 5
    93,  // 6
    111, // 7
    129, // 8
    147, // 9
    165, // 10
    183, // 11
    201, // 12
    219, // 13
    237, // 14
    255, // 15
};

It looks quite good this way. http://screenshot.ru/upload/images/2014/06/19/screenshot_2962223682d19f4.png But the screenshot also illustrates what paramat noted.

[Calinou]

One issue I noticed is that the caves, with no lightsource at all are quite bright.

With my table, I can't see anything in caves without light and I hardly see anything at night already…

I realize my screen is poorly calibrated, but many people also have screens that show dark stuff as really dark.

This could be tried (each light level is 85 % of the previous one):

u8 light_decode_table[LIGHT_MAX + 1] = {
    30,
    35,
    40,
    46,
    53,
    62,
    72,
    84,
    98,
    115,
    135,
    158,
    185,
    217,
    255,
};

Anything that fixes light sources attenuating too quickly will do…

[paramat]

Reading light.cpp and the comments there, it seems the current table has been very carefully tuned for good reasons, some of which we are probably unaware of, by someone (probably celeron55) who is aware of all the things the table affects, so it's wise to either leave it alone or ask the original coder why it is optimum. IRL light spreads according to the 'inverse-square law' which is very far from linear, although i don't support strict realism, light will look wrong if it deviates too far from exponential. Light sources are too dark i agree but this is due to the limited light range of 16 nodes. Messing with the light table is a balance between exponentiality and amount of light, the current * 0.8 rule is already brighter and more linear than a realistic 'inverse square law', and may be as linear as it can be without looking wrong. Reading light.cpp, which table is actually used? it is unclear.

[SmallJoker]

@paramat Could you provide a realistic table, which is a bit tuned? Also, this lightening table gets used: https://github.com/minetest/minetest/blob/master/src/light.cpp#L22 All other are commented out or marked with "#if 0"

[paramat]

Thanks, 'middle-raised' means the table started as exponential (a_n+1 = a_n * 0.786) and then the middle light values were carefully raised to create more light. A 'realistic' table would be inverse-square and much darker than current, i really don't think i can do better than the current table, it's gently exponential and tuned for more light.

[sapier]

Doesn't seem like we can get a agreement on a new light table for 0.4.10, I'm delaying this to Pilzadam suggested providing multiple sets of lighttables and make ppl test them. I agree to this suggestion. We're gonna do this right after 0.4.10 is released

[celeron55]

You should also take into account that the values in that file aren't actually what is produced on a display, nor are light values nearly anywhere else either. In 8-bit-per-channel RGB at least the display uses gamma to give more detail in dark areas, so you cannot compare those tables or image files or anything without doing gamma correction first to get the values into linear space. Also doing calculations with those values causes nonlinear errors.

Anyone up for trying to re-evaluate this discussion with gamma in mind? 8)

[RealBadAngel]

One more thing, the table has to start with 0. All the comments in the code says so, but the table happily sets level 0 to 8. Thx to that some nodes become lightsources (nodeboxes).

[paramat]

RealBadAngel why must it start with 0? If it was set to 8 then it may have been done for good reason and because that works best. With a semi-exponential decay setting the first value to 0 will create a lower light range and make everything darker, which no-one wants, this may be why the first value is 8.

[planetguy32]

It'd be neat to be able to set this in Lua. I could imagine this being done per-player to make night-vision effects, for example.