Currently I have something similar to Minecraft's lighting in my dynamic world, which I am considering rewriting yet again to fix issues related to chunk/region borders and performance issues when lights or voxels change...

But wondering if there are any other practical options? In the past I have mostly just used whatever the engine provided, and even that often had a lot of caveats that are not suitable here (slow/expensive light map creation process, a limit on dynamic lights in an area, no support for day-night cycles, little/no indirect lighting, etc.) so not really sure if there is much better out there.

At the very least a fairly comprehensive explanation of the minecraft style voxel lighting would be nice (how to minimise how much needs to be recalculated, how to handle chunk boundaries without issues, etc.), but if there is a generic lighting system these days I am much more inclined to put effort into implementing/integrating that since I really would like angled lights (rather than only vertical sunlight for example), full colored lighting, dynamic/moving lights, etc.

My main concern with just going straight to shadow mapping etc. is the potentially large number of light sources in each region, and the relatively large area covered by a single draw call, since it currently groups and batches by texture, but that results in each draw call being fairly spread out, with many having a very low "density" faces, and with the majority of faces behind hidden behind something, whereas with non-voxel games with BSP and such the engines seemed very capable of only rendering local/visible stuff, and not things hidden behind walls etc..

Mimicking Minecraft is in noway my goal here, its just the only solution to this problem I know of, and even that I am finding has a very large list of complexities and problems.

My goals basically are

• I want to have a day-night cycle, so need to be able to efficiently vary the brightness of sky light (easy enough with any system I can think of)
• Light must be obstructed ("shadows"). While in open areas and caves/tunnels this is not such an issue, in user created buildings I feel it is important to not have light sources go through walls, floors, etc.
• I want decent indirect lighting. For example windows, or small openings in the tops of caves should light the general area, Likewise a player placed light should not cast an area into total darkness because of a small obstruction.
• Areas with no light sources should actually be dark (taken with the above, this makes anything apart from a highly minimal ambient light value problematic, meaning I really do need a way to at least approximate indirect light for an area)
• The number and density of light sources may be fairly high (since player placed).
• I would really like to be able to have colored lights.
• I would really like to have dynamic/moving lights.
• I want to be able to get approximate lighting values for a location outside of rendering (e.g. for plant growth, and NPC/AI interaction).

The Minecraft solution was the best idea I had at the time or have now, since it gives a reasonable approximation for shadows and indirect lighting. But there is a lot of limitations, so why I am wondering if there are any other options (or at least known solutions to all these limitations)?

• It is not practical to have full coloured lighting
• It is not possible to have directional or spot lights, everything is a point, except a special case to let sky light go directly down (but really id like it to have a proper angle based on the time of day).
• It is not practical to have moving lights because the light "source" is always an entire voxel so such moving lights are not smooth.
• The maximum "range" of a light is highly limited, e.g. 15m in my case)
• When dealing with chunks and the need to efficiently update the lighting data without recomputing the whole world, the algorithm is extremely complicated and prone to bugs (e.g. it just occurred to me that even with my conceptual system without any bugs in the implementation, near the border between the voxel grid and "empty space" there will be lighting glitches in certain situations because I am not propagating light through the empty space).
• Dealing with opaque blocks that are not cubes is also highly problematic (and I believe minecraft has had and still has some issues with half slabs and stairs).

With deferred shading and a well optimized lighting setup, you could go fully dynamic with your lighting.

Now I don't know about Voxel setups as I always went with traditional 3D Scenes... still, heres my 2 cents base on my asumption that any Voxel engine today will use a traditional poly engine for the graphical rendering:

As long as your scene is small enough, you somehow manage to partition the the scene well or just either go down with the quality settings / make sure it runs on a highend PC, modern engines and hardware can actually deal with a reasonable dynamic setup.

Be aware that there might be problems with realtime shadows that I haven't seen a real solution for yet. In most engines, shadows flicker at the edges with movement. And when your lightsource moves, you get constant flickering! This is less noticable with erratic movement of car headlights, flickering flame lights and such, but a sun moving at a constant pace over the skydome will cause noticable edge flickering.

Depending on how much you can up the quality settings (resolution of the Shadowmap (as long as shadow distance is reasonably small), softness of shadows, ...), the flickering might be less of a problem. But it is something to always keep in mind.

Well I don't render a voxel scene directly, each region of the scene gets turned into a triangle (currently list) mesh for each surface material present, allthough that does require a lot more draw calls for non-visible triangles than Ive got with say a BSP scene (allthough I have not tried, I assume then further processing my mesh into a BSP or such is not practical, given how long it used to take with Gold Source and Source maps even without the lighting compile step, and rooms designed to be friendly with that step so they didnt fragment into 1000's of pieces).

So would that be basically using the traditional shadow maps possibly with the cascading thing to get higher resolutions near the camera or somthing more advanced than those (I didn't see a name for a lighting method in your post)?

I have done shadow maps before with forward rendering, but lavk of indirect lighting proved to be a big problem, which I had to work around with carefully picked and scene dependent ambient values and fake light sources (e.g. putting a fairly dim point light just inside the window). I have also done just simple pixel or vertex lighting, but that only uses the light source and vertex/pixel normal, so no shadows at all.

Well I don't render a voxel scene directly, each region of the scene gets turned into a triangle (currently list) mesh for each surface material present, allthough that does require a lot more draw calls for non-visible triangles than Ive got with say a BSP scene (allthough I have not tried, I assume then further processing my mesh into a BSP or such is not practical, given how long it used to take with Gold Source and Source maps even without the lighting compile step, and rooms designed to be friendly with that step so they didnt fragment into 1000's of pieces).

So would that be basically using the traditional shadow maps possibly with the cascading thing to get higher resolutions near the camera or somthing more advanced than those (I didn't see a name for a lighting method in your post)?

I have done shadow maps before with forward rendering, but lavk of indirect lighting proved to be a big problem, which I had to work around with carefully picked and scene dependent ambient values and fake light sources (e.g. putting a fairly dim point light just inside the window). I have also done just simple pixel or vertex lighting, but that only uses the light source and vertex/pixel normal, so no shadows at all.

If you translate your Voxel Scene to a polygon scene before rendering, why not look up how polygon engines do dynamic lighting?

As said, I cannot help you directly with your problem due to my limited knowledge with anything Voxelbased, but there is plenty of information around about dynamic lighting in polygon rendering.

Cascaded Shadow maps will be needed if you go with the traditional approach and want more than just a few meters of shadow range, yes. Be aware though there are more modern approaches to shadow mapping, so if you have to develop your own anyway because you do not use an engine like Unity or Unreal, you might want to research these shadowmapping methods first.

Forward renderer is a good choice as long as you have a single light source. As soon as your lighting setup gets fairly comples, look into the deferred rendering path.

I don't think any of the big engines has the indirect lighting really solved outside of PBS, but they give you the option to use an ambient light color value. I think it does nothing else than what you did with the ambient values.

If you want to have REALLY accurate ambient lighting, you might want to look up physically based shading, espcially the image based lighting involved in most PBS Systems. You will now use a HDR Cubemap to define the ambient value for each pixel being shaded. It seems some people even got a system for the PBS System to rotate the cubemap, or lerp between two cubemaps, first for faking movement of clouds and sky elements (like a moving sun), second for changes in the lighting settings (sunset and day night cycle).

IDK how far you want to take it, but Physically base shading/rendering is all the rage at the moment, articles on it pop up on the internet like mushrooms, yo you might have a look at the solutions proposed there anyway, as some might help you even if you're not heading fully physically based (yet).