FOSS gamedev and creative worlds

We've been discussing this frequently on IRC, and it's becoming an important subject in Minetest development. Most users are probably aware that since its existence, Minetest has been using an unique method of doing lighting. Light is simulated by setting face colors (vertex colors when smooth lighting is enabled) to brighter or darken the intensity of surfaces. The correct way of doing lighting in a 3D environment though is by using real light entities (hardware lights or dynamic lights) which radiate lighting in an uniform way.

There are many reasons why this is heavily wanted in Minetest too. First of all, I consider the current method a hack. Surface colors are not meant to be used for simulating light, and this is incorrect in regard to how 3D rendering is meant to work at this day in my opinion. Second, it brings many problems. The mapgen must calculate lighting for each node as it spawns... causing the world to take longer to load, its size on the drive to be bigger, and more information to be constantly networked to the user. Multiple instances of the same mesh are also colorized as one, causing a known bug where a player being in a dark area makes all players turn black. Thirdly, hardware lighting looks a whole lot better, since lighting is always directional to surfaces and ranges properly. Fourth, it unlocks new possibilities such as bump mapping, specular (glossy reflections), light animations (blinking lights) and more graphical effects which can be optional.

Enabling light entities from Irrlicht is very simple, but there's a reason why this hasn't been done already; No one knows how to keep lighting from shining in caves and indoor. A dynamic light goes as far as its range is set, and culling by surface would be tricky. We're still brainstorming for ways to fix the problem. Preferably without shaders, so people who don't enable them can have proper lighting as well. As far as I'm aware, there are two ways we can go about this:

- Use the current voxel light calculation to determine where sunlight should shine. So instead of using it to set surface color, we use it as a mask to influence where lighting shows. Problem is there's no easy way to filter lights per surfaces. It could be done with multiple render buffers but that would be costly on performance. If anyone finds a way to do this with Irrlicht lights (and hopefully no shaders) you could be a hero :)

[EDIT] - Colorize nodes which are out of a light's influence black, reversing the current implementation and above suggestion. A light entity can't brighten a black surface, so darkening the diffuse color can be used to stop lights from shining in caves. Supposing it would work however, you still need to separate lights from each other, so placing a torch in a cave won't cause the sun / moon to show over it. This would get half of the problem solved still.

- Another idea I thought of is using stencil shadows to keep light showing where it should. Dynamic shadows however can be extremely costly, which is why they're always a preference and not meant for anything but visual effects. If we'd rely on them to hide light in caves, we'd need them to be always enabled, which most hardware couldn't handle properly (especially without shaders).

If anyone wishes to contribute to making this happen, everyone would greatly appreciate it. I already looked at the lighting system and it's too large to understand. I easily managed to add a dynamic light once and it looked awesome, but we need someone to figure out the masking. This thread is dedicated to finding ideas and working on adding hardware lighting to Minetest.

Won't using dynamic shadows (or stencil shadows) make it impossible to determine a node's light level (since using dynamic lighting would remove the whole "light level" stuff)?

Calinou wrote:Won't using dynamic shadows (or stencil shadows) make it impossible to determine a node's light level (since using dynamic lighting would remove the whole "light level" stuff)?

That is another problem yes. Nodes need to store their light level which can be read and used by mods accordingly. One reason why the stencil shadows idea isn't really the best for this purpose (but as an optional effect yes).

Oh, and there's a third option I forgot to add to the first post. More possible but still a hack using vertex colors, though better than the current one:

- Colorize nodes which are out of a light's influence black, reversing the current implementation. A light entity can't brighten a black surface, so darkening the diffuse color can be used to stop lights from shining in caves. Supposing it would work however, you still need to separate lights from each other, so placing a torch in a cave won't cause the sun / moon to show over it. This would get half of the problem solved still.

Why would you want to cull the light so that it doesn't shine in caves? In real life (from my exprience) light does normally shine in caves.

In any case, past the turn in the tunnel, its all dark.

EDIT: Oh, now I see. For some reason the light goes through the dirt....

keneticquartz wrote:Why would you want to cull the light so that it doesn't shine in caves? In real life (from my exprience) light does normally shine in caves.

Not all shadows are totally dark due to global illumination; light can "bounce" somehow. Adding that effect to a game is possible, but it is quite expensive in terms of resources. Tesseract is an example of a game that has optional global illumination (and also dynamic lighting, deferred shading and many other things).

Calinou wrote:

keneticquartz wrote:Why would you want to cull the light so that it doesn't shine in caves? In real life (from my exprience) light does normally shine in caves.

Not all shadows are totally dark due to global illumination; light can "bounce" somehow. Adding that effect to a game is possible, but it is quite expensive in terms of resources. Tesseract is an example of a game that has optional global illumination (and also dynamic lighting, deferred shading and many other things).

Yes, I mean sunlight not shining when you're dozens of meters underground exploring caves (radiating through walls). An algorithm to let the sun shine inside cave entrances would be nice, and prolly not as costly if the mask can still be calculated per node like current lights.

+100500 for this to be implemented

If this can be added to Minetest, the beauty factor of the game will go way up. I heard that it will also make it easier to add colored light-rays.

Inocudom wrote:If this can be added to Minetest, the beauty factor of the game will go way up. I heard that it will also make it easier to add colored light-rays.

True for both things.

I was wondering if there are any changes, plans, or new ideas and opinions here. At this point this feels like the biggest bottleneck to MineTest being one of the best voxel engines and on its way to completion. I'm totally set on making it a reality, but can't manage much by myself if other developers don't help, as well as my work being for nothing if the code isn't accepted and others can't help finish it. Are any of the experienced devs willing to gather forces and find a solution on implementing actual lighting?

MirceaKitsune wrote:I was wondering if there are any changes, plans, or new ideas and opinions here. At this point this feels like the biggest bottleneck to MineTest being one of the best voxel engines and on its way to completion. I'm totally set on making it a reality, but can't manage much by myself if other developers don't help, as well as my work being for nothing if the code isn't accepted and others can't help finish it. Are any of the experienced devs willing to gather forces and find a solution on implementing actual lighting?

RealBadAngel (who is a core dev) said he plans to implement the hardware lighting.

I dont think MirceaKitsune understands what she is talking about.

The main way of getting Lighting needs shaders.
Shaders define how pixels/fragments/vertex are rendered, and do not need to be expensive or costly.
Even the default per-vertex lighting in irrlicht uses shaders.

rubenwardy wrote:I dont think MirceaKitsune understands what she is talking about.

The main way of getting Lighting needs shaders.
Shaders define how pixels/fragments/vertex are rendered, and do not need to be expensive or costly.
Even the default per-vertex lighting in irrlicht uses shaders.

The builtin Irrlicht functions for lights are what I was thinking about as an alternative to shaders, were they better. I was preferring them (so people without shader support could use lighting too) but if they work the same way that clears one thing up.

I'm still talking about code changes since I imagine this needs to be done both in code and with a new shader. I have even less experience with shaders than with C++, but if there's a chance of this happening I'll google around for free shaders and GLSL tutorials and see if I could find anything slightly helpful.

MirceaKitsune wrote:

rubenwardy wrote:I dont think MirceaKitsune understands what she is talking about.

The main way of getting Lighting needs shaders.
Shaders define how pixels/fragments/vertex are rendered, and do not need to be expensive or costly.
Even the default per-vertex lighting in irrlicht uses shaders.

The builtin Irrlicht functions for lights are what I was thinking about as an alternative to shaders, were they better. I was preferring them (so people without shader support could use lighting too) but if they work the same way that clears one thing up.

I'm still talking about code changes since I imagine this needs to be done both in code and with a new shader. I have even less experience with shaders than with C++, but if there's a chance of this happening I'll google around for free shaders and GLSL tutorials and see if I could find anything slightly helpful.

The irrlicht build lights are not very good. IIRC they ARE shaders, but in compiled ARB form.

Is it actually a good idea to have a light level per node? The wall of a house can be brightly lit on the outside, but pitch black on the inside. A light level per surface makes more sense.

Eventually you want hardware lightning, because it gives the most beautiful results. The light level of nodes (minetest.get_node_light) can be computed independently in software using ray tracing methods (one ray per surface and light source in reach cached for a few frames).

Ok, I was away and relaxing for a few hours. I thought about this some more and if my understanding of the code and shaders is correct, I have a code plan in mind. I doubt I'd know to implement it myself, but should at least have the right idea. This is what I think the steps are:

- First of all, add a MineTest setting which fully disables the current lighting system (vertex colors) and enables a new shader. However it mustn't disable the usage of param1. Examples for the preference can be found with the existing test_shader_# shaders.

- Next, the MineTest code must inform the lighting shader about the light value of each node. In other words, it must use an "uniform" variable in the vertex shader to tell it what the value of param1 is for every face / vertice of every node loaded into view.

- Next, MineTest must also inform the vertex shader about light sources, by passing each light and its location. So if I place a torch at location 15, 20, 5 and torches have a light value of 13, MT tells the shader "15 20 5 13". In case we also add color lights as an additional feature (which should be easy with this system) we also send the RGB information.

- Lastly, the shader pieces everything together. It knows the "light mapping" of nodes by their param1 values, and it knows what the light sources and their intensities are. So the shader spawns a light at that location, gives it the proper intensity, and uses param1 as a mask on top of that. Obviously the distance of the shader light must match the radius MineTest intended for it, but that can be determined by intensity.

You might be thinking "But how do we tell light sources from each other and from sunlight"? From my understanding, that would be pretty easy. Imagine you're deep underground where no lights exist, then you place two torches close to each other. In MineTest, each torch causes a virtual sphere in which param1 is gradually enabled on nearby nodes. Meanwhile the shader knows the origin and power of the light sources, and uses them to estimate those spheres. The lights will automatically shine within the "lit area" and should overlap correctly in points of intersection.

Now comes sunlight. That should be even easier and there might many ways to detect it. Easiest one is that nodes affected by sun have the biggest light value at day time. That's why torches are defined with "light_source = LIGHT_MAX - 1". The shader simply applies sun light only where param1 is maximum. There might however be issues with making sun lights gradually fade into cave entrances.

I might be missing out on a couple of things, but normally this should do the trick. It should also be pretty easy for someone who knows the code better, especially the C++ part. Am I correct with this approach, and can it be done?

This discussion is alive again. I just hope that this leads to something good this time. The last time that this was discussed, a couple of prominent members left (mauvebic and rarkenin.) Luckily for us, Mito551 returned to our community recently.

Adding hardware lighting to Minetest will likely be a slow and challenging process, but it is not impossible. It will require teamwork from start to finish, but the results will be worth it through and through.

I am not a good modder... so I am not good with code, but if this is possible... DO IT!

Inocudom wrote:This discussion is alive again. I just hope that this leads to something good this time. The last time that this was discussed, a couple of prominent members left (mauvebic and rarkenin.) Luckily for us, Mito551 returned to our community recently.

Adding hardware lighting to Minetest will likely be a slow and challenging process, but it is not impossible. It will require teamwork from start to finish, but the results will be worth it through and through.

Agreed. If the setup in my last post is possible however, it shouldn't even be as difficult. The code just needs to activate and inform the shader... should be easy enough. The real magic would happen in the shader itself, but anyone familiar with GLSL should know how to add a simple light. Using param1 to mask lights is the trickier part and I've no idea about that... but, it should be doable.

And yes, I do hope this time we can find a way to actually make this reality. I heard RealBadAngel is already working on it... I'll try to ask him about it and see what the developers think about what he did so far.

Had an additional suggestion to my code plan. Not sure if it would be more / less costly and correct, but: Maybe we could instead send each light with its list of affected nodes to the shader. So instead of separately sending all instances of param1 then all light sources, send each light source with a list of affected nodes and how much that light changed param1 on each. So the way Minetest notifies the shader of any new light source would be:

Sorry for the triple post... I hope that can be excused by the info and ideas I'm looking into :) I did a quick search on how to setup lighting in GLSL, and found a few pages that can be useful. I don't understand all of it myself especially since I'm rather tired today, but it might make it easier for people who want to try making the shader.

http://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/lighting.php

http://www.clockworkcoders.com/oglsl/tutorial5.htm

http://pyopengl.sourceforge.net/context/tutorials/shader_7.xhtml

http://www.swiftless.com/tutorials/glsl/5_lighting_perpixel.html

Base idea is that the shader function we're looking for is gl_LightSource. Perhaps I'll look more in the next days about it.

MirceaKitsune wrote:Sorry for the triple post... I hope that can be excused by the info and ideas I'm looking into :) I did a quick search on how to setup lighting in GLSL, and found a few pages that can be useful. I don't understand all of it myself especially since I'm rather tired today, but it might make it easier for people who want to try making the shader.

http://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/lighting.php

http://www.clockworkcoders.com/oglsl/tutorial5.htm

http://pyopengl.sourceforge.net/context/tutorials/shader_7.xhtml

http://www.swiftless.com/tutorials/glsl/5_lighting_perpixel.html

Base idea is that the shader function we're looking for is gl_LightSource. Perhaps I'll look more in the next days about it.

Bind gl_LightSource(); to all nodes that add light through the API. Then tune it until it matches the Minetest lighting distance.

I want to create a fork to improve the graphics in minetest, and I have a question. What is the current situation with dynamic lighting? Is they alredy implemented, or there is only in the plan? If not, I'm wondering where do you stop, and if I can help you?

Sorry for my bad english.

fake wrote:I want to create a fork to improve the graphics in minetest, and I have a question. What is the current situation with dynamic lighting? Is they alredy implemented, or there is only in the plan? If not, I'm wondering where do you stop, and if I can help you?

Sorry for my bad english.

If you do indeed intend to help out with this, get in touch with RealBadAngel. Minetest uses software lighting right now, so hardware lighting is not part of the game yet.