Page 1 of 1

Light levels above 15

Posted: Sat Jul 16, 2016 12:31
by ABJ
Hello all.
My suggestion is simple; we need light levels above 15. The current light level is surprisingly limitive, for example the super-bright lights, flashes of explosions, the like are not done. At least, is there a way to simply increase the light level above 15 by making it longer range, and make the increaseable amount infinite?

Re: Light levels above 15

Posted: Sat Jul 16, 2016 12:35
by Calinou
Doing so would likely break all existing Minetest maps, not to mention it would make light computations more expensive.

Re: Light levels above 15

Posted: Sat Jul 16, 2016 13:23
by ABJ
But how does this happen? Do you mean those lights with default lightmax as their light value? And the calculations part...........?

In any case, what about a finite number, such as 100, 500, 1000? Also, skipping that bit about how the light will simply be made longer range?

Re: Light levels above 15

Posted: Sat Jul 16, 2016 18:54
by paramat
Light cannot exceed a range of 16 nodes unless a complete new lighting system is created (this might actually happen, some devs are keen to do this eventually). Lighitng update calculations are already very intensive even with only 16 nodes range. For details read through the last 1-2 years of IRC dev channel logs.

Re: Light levels above 15

Posted: Sat Jul 16, 2016 19:20
by ABJ
Al sh*t wa sh*t
So, again, here comes the powers of two.
I hope that the devs actually do this, and also paramat is it really that easy to read 2 years of irc log?

Re: Light levels above 15

Posted: Sat Jul 16, 2016 22:22
by kaadmy
Just went through the math...
(Try it in Python...)

Code: Select all

>>> nodes = 2000 ** 3
>>> bytes = nodes / 8.0
>>> kb = bytes / 1024.0
>>> mb = kb / 1024.0
>>> mb
953.67431640625
Yes, that's around 950 MEGABYTES of data that must be stored in a world file in a 2k node cube to double the light levels from 16 to 32.
Correct me if I'm wrong, I went through the math a couple times to make sure...

Re: Light levels above 15

Posted: Sun Jul 17, 2016 08:07
by ABJ
Well, this is too bad. How about replacing all air nodes around with light-emitting airlike nodes above 15? Could you not preserve the calculations this way? It would look slightly absurd, sure, but would it work?

Re: Light levels above 15

Posted: Sun Jul 17, 2016 17:38
by kaadmy
There's one thing that would help immensely with lighting; HDR+eye adaptation.
Then the light levels can stay 0-15, and have a much higher range. Then outdoor lights(Outdoor is always 15 light) can be really, really overbright and have the eye adaptation darken the rest of the world.

Re: Light levels above 15

Posted: Sun Jul 17, 2016 17:40
by ABJ
OMG are you talking about that like in those new high-end games?

Re: Light levels above 15

Posted: Sun Jul 17, 2016 20:00
by kaadmy
@ABJ MT doesn't have HDR yet, but it might be possible if a MT dev figures out how to deal with shaders.

Re: Light levels above 15

Posted: Mon Jul 18, 2016 08:10
by ABJ
Er......What if I told you that, thanks to a crappy Windows format and reinstall, I no longer have OpenGL?

Re: Light levels above 15

Posted: Mon Jul 18, 2016 09:43
by Calinou
ABJ wrote:Er......What if I told you that, thanks to a crappy Windows format and reinstall, I no longer have OpenGL?
When you install a graphics driver on Windows, you automatically have both OpenGL and Direct3D, regardless if it's Intel, AMD or NVIDIA.

Re: Light levels above 15

Posted: Mon Jul 18, 2016 10:33
by ABJ
So, why is it that many things that formerly worked are not working properly after the format, such as KSP, Golems, Minetest's shaders, and Blender giving me a warning about OpenGL?

Re: Light levels above 15

Posted: Mon Jul 18, 2016 17:38
by TenPlus1
That all depends on your Windows version and the graphics driver you installed. Also try adding the following line to your minetest.conf file to force opengl support:

video_driver = opengl

Re: Light levels above 15

Posted: Mon Jul 18, 2016 17:42
by ABJ
ABJ wrote:Blender giving me a warning about OpenGL
Just in case you misunderstood and thought I'd written that part like a noob.

Re: Light levels above 15

Posted: Wed Jul 20, 2016 20:46
by ARCHLINUX
display_gamma = -4
address = 98.166.90.48
fast_move = true
free_move = true
noclip = true
remote_port = 30000
anisotropic_filter = true
bilinear_filter = false
cinematic = false
connected_glass = false
enable_parallax_occlusion = true
enable_waving_leaves = true
enable_waving_plants = true
enable_waving_water = true
fsaa = 16
leaves_style = fancy
mainmenu_last_selected_TP = 1
mip_map = true
node_highlighting = box
opaque_water = true
texture_path = /home/tr0llc0re/xray_xanadu
tone_mapping = true
trilinear_filter = true
viewing_range = 90
fullscreen = false
enable_3d_clouds = true
enable_particles = true
enable_shaders = true
smooth_lighting = true
generate_normalmaps = true
enable_bumpmapping = true
fps_max = 100


Try this cfg i dont feel the night

Re: Light levels above 15

Posted: Thu Jul 21, 2016 07:16
by ABJ
I hope no one complains the he is hacking/cheating.
Actually, instead of copy/paste, I'd prefer to see what is making it look good. I run no shaders, thanks to OpenGL flack-up

Re: Light levels above 15

Posted: Thu Aug 04, 2016 09:46
by Gael de Sailly
Light level is stored in one byte: 4 bits for day light, and 4 bits for night light. Since night light level can't be bigger than day light level, many combinations are unused.
In fact, with 16 light values, we have 256 combinations, but only 136 (16+15+14+13+12…) are used.
With 22 light values (0~21), we would have 484 combinations, but only 253 would be used. So, light max can theoretically be extended to 21. But things will become much more complicated…

Re: Light levels above 15

Posted: Thu Aug 04, 2016 10:11
by ABJ
So, what would it cause?

By the way, I've fixed my OpenGL problem. Thanks Amaz and the_raven_262.

Re: Light levels above 15

Posted: Tue Jul 23, 2019 02:10
by neoh4x0r
Gael de Sailly wrote:Light level is stored in one byte: 4 bits for day light, and 4 bits for night light. Since night light level can't be bigger than day light level, many combinations are unused.
In fact, with 16 light values, we have 256 combinations, but only 136 (16+15+14+13+12…) are used.
With 22 light values (0~21), we would have 484 combinations, but only 253 would be used. So, light max can theoretically be extended to 21. But things will become much more complicated…
There are only 16 light levels defined...which are re-mapped to be a value between 0 and 255.
That doesn't give 256 combinations but only 16.
(these 16 levels are shared by day and night). [this is done to make the actual light levels to be tied to the display_gamma setting]

[/begin rant]
Currently an 8-bit value (u8) is used (cut in-half) giving 2^4 (16) light levels
Honestly the light levels could use a 16-bit value (u16) (cut in-half) 2^8 (256) light levels.

LIGHT_SUN could then be defined as 255 instead of 15 and LIGHT_MAX could be defined as 254

Allow the use of the full-range between 0 and 255 -- giving a better resolution or gradient of light levels.
(it will also have the benefit of making the value of display_gamma unnecessary for light level calculations)

Instead of setting a value between 0 and 15 for the level, we could just set it directly 0 to 255, by implementing the former.
EG:
100% bright = LIGHT_SUN * 1= 255
99% bright = LIGHT_SUN*0.9999 = 254
50% bright = LIGHT_SUN * 0.5 = 127
25% bright = LIGHT_SUN * 0.25 = 63

In fact multiplying by a percentage to get the brightness factor is exactly what is done in the code

Code: Select all

float brightness = decode_light_f((float)i / LIGHT_SUN)
(this would make the whole thing a lot more manageable....)
Intead of re-mapping/converting the light levels we could make the relationship be one to one.
[/end rant]
----------
See the below for more information:

https://github.com/minetest/minetest/bl ... ht.cpp#L75

A value of 0 and 255 (no light and max light are hard-coded).

Here's the relevant code snippet from light.cpp

Code: Select all

 
#define LIGHT_MAX 14
#define LIGHT_SUN 15

void set_light_table(float gamma)
        light_LUT[0] = 0;
	light_LUT[LIGHT_SUN] = 255;

	for (size_t i = 1; i < LIGHT_SUN; i++) {
             float brightness = decode_light_f((float)i / LIGHT_SUN);
             light_LUT[i] = rangelim((s32)(255.0f * brightness), 0, 255);
        }
So we have at most 16 light levels (shared by both day and night)

Code: Select all

light_LUT[0] = 0
light_LUT[1] = some value
[...]
light_LUT[14] = some value
light_LUT[15] = 255
The fact that the light levels (0...15) are remapped to be between 0 and 255, really makes no difference since there are still only 16 values being defined -- this means that 240 (ie 256-16) values aren't being used).