Lighting technique

Hi!
I'm working on a game similar to yours. It's coming along nicely, recently I implemented some lighting effects within a pixel shader.
I've been following your videos for a while now and have seen that you seem to be able to have an unlimited amount of coloured lights in your scene without any FPS drop. It seems to be smooth lighting in contrast to Minecraft's per-block lighting. Would you mind sharing some information about what technique you are using here?
Thanks in advance!

The best way to describe the lighting algorithm is a floodfill.

The lighting values are 'baked' into the vertices of my chunk meshes.

To generate the values for each vertex i need to first calculate the light in each (empty) block.To do this i need to factor in 2 light sources; sunlight and local lights.


First i clear out all the light values for each block. I need to do this because the player may have removed a light source, or may have blocked the only hole in the roof of a cave that was letting sunlight in etc.

After each blocks light has been zeroed i can fill in the blocks that are light sources. For sun, I start at the top of the world and fill each block column in with a max sunlight value until i hit a block that is solid to light, everything from that block down has zero sunlight.

I then fill in the light values for each light source in the chunk, just a single block for each source (lava has loads of sources, 1 per block of lava). Now i have a bare bones light setup.

I then iterate through each block and call a function PropgateLight, passing in the light value of the current block. This function plonks the light value into the current block and then calls itself with a slightly dimmer light value for each of the 6 directly adjoining blocks.

The function exits when the light value is too dim to bother about, when it hits a light solid block, or when it hits a light value already there that is greater or equal to the light value it is about to place.

I do this latter part 4 times, once for sun, R, G and B channels.

Then when i am generating the vertices for my mesh i refer to the light values and average the 4 blocks in a plane directly touching the vertex (with the vertex in the centre). Note i average all the blocks, even solid to light ones. These zero light blocks pull the average down and give me the mock Ambient Occlusion in interior corners. This process also gives me smooth lighting rather than blocky.

When i actually am drawing the mesh i use the sun channel as an intensity and pass in the current ambient light colour as a full blown RGB triplet as a parameter to the draw call. In the vertex shader i multiply the ambient color by the vertex 'sun intensity', and this allows me to instantly change from full bright to full dark rather than rebuild the chunk to accomplish this. The RGB channels are passed in for each vertex too.

My light range is 16 blocks for a light source and slightly less than 16 blocks for sunlight. I lowered sunlight to get a little bit of extra performance, since there is a lot of it.

So, lighting only impacts chunk regeneration time, not draw time.

Thanks for your answer!
Your approach is completely different from what I had expected I will have to rework lighting in my game soon, too. I'll probably try a different technique first and see how it works out. If that fails I might try out your approach as it seems to work really well. Thanks for the info!

Very smart way to pre-compute lighting.

Just one small question concerning your explanation :

When you say :

... average the 4 blocks in a plane directly touching the vertex ...

Do you mean you are only averaging following 1 plane ? Because every vertices are touched by 8 cubes, and so are contained inside 3 differents planes (X, Y and Z planes).

S33m3 wrote:
Do you mean you are only averaging following 1 plane ? Because every vertices are touched by 8 cubes, and so are contained inside 3 differents planes (X, Y and Z planes).

I only use the average of 4 cubes...

If you consider a vertex on an upward face in the middle of a flat piece of terrain, then the 4 cubes below are all solid (= fully dark), so i only use the 4 cubes above that are touching the vertex.

Also consider a vertex on a large wall facing North; the South side cubes are solid again, so i only use the 4 cubes to the North of the vertex.

Thus depending on the orientation of the face that holds the vertex i have 6 possible sets of 4 cubes to use, if you can follow that.

Tx you So you are using the vertex's normal to decide the blocks that needs te bo used in the averaging.

S33m3 wrote:Tx you So you are using the vertex's normal to decide the blocks that needs te bo used in the averaging.

Ah, not quite i'm afraid, but i do end up with the same result. The way i generate the vertices is i do one face direction at a time (so the normal is implied i suppose you could say). I generate all the up faces, then all the down etc. They generate into seperate vertex buffers so i can draw (or not draw) each face orientation seperately for each chunk.

I actually don't have vertex normals as such, but i do imply them.

Indeed with cube, if you know the face being created (up, down, back, front left or right) your know without computation the normals of its 4 vertices.

Hi

interesting technique and dicsussion. I have a question and thurst for knowledge that is burning in my mind, I hope you can share some light with me on these questions:

How do you deal with vertices in A and B that you can see on this pic:
https://i.imgur.com/UDb80.jpg

To which plane do they belong? Do the belong to the wall or to the plane looking up?

When you mention that you separate the vertices one face direction at the time, does that mean that you are are using 24 vertices per cube, 4 vertices for each face?

If that is the case then A and B are actually not just simple 2 vertices but they are points containing 3 vertices each.

When you compute the lightning for each vertice you then already know to wich face it belongs since you have grouped the faces up, down, east, west, south, north?

Also how do you create chunks if you have splitted your vertices into different buffers depending on direction? How do you join all the buffers into one chunk, instead of having just one buffer of vertices for each chunk?

Point A: Contains 2 vertices since it lies on 2 planes. I'm assuming from your diagram that each of the 4 quads it lies on has the same texture.

Point B: contains 3 vertices since it lies on 3 planes.

Point C: Contains 2 vertices even though it is a single plane. This is due to the differing textures on your diagram.

Yes, i am using 24 vertices per cube, but you've actually got me thinking i could be using less. When i was using texcoords i would have needed to use 24 vertices but i don't use texcoords as such so possibly could get away with only 8. Well spotted , i'll have to have a think about that.

I'm not sure what you're getting at with the last part. But, i use 6 vertex buffers and 6 index buffers, one for each face direction, for the main blocks. I then use 1 vertex and 1 index buffer to handle liquids, then 1 vertex and 1 index buffer to handle models (anything which isn't completely square).

The idea is that i wil be able to quickly decide which faces to draw for each chunk. EG, if a chunk is to the north east of you then you don't have to draw any north or east facing faces, because you simply can't see them. If the chunk is due north of you then you will have to draw both east and west faces but you don't have to draw north faces etc.

Thanks that explains some things.

By the way how do you get away not using textcoords? If you don't use them, how do you get faces textured correctly?

Also I'm thinking about point A again, you mentioned that since there are 2 planes that intersect at point A and you asumed that each of 4 quads are using same texture there are only 2 vertices there. Does that means you have already some optimization there?

If you didn't have any optimization would there not be as many as 4 vertices in point A, one vertice for each quads that surrounds the vertice?

Also why are there 2 vertices in point C? Its a single plane and If I understood that you are using 24 vertices per cube, then you should actually even there have 4 vertices, one for each quad that is around point C. I'm puzzled right now

I use Texture Arrays (a DX10 feature) and use the world coords as the texture coords (with wrap). All i pass into the vertex shader is a texture number.

I do share vertices wherever possible. So point A has one vertex for the up facing quads and one for the right facing quads. This relies on all the texures being the same, or i can't share the vertex.

You're correct, without the optimisation point A would have 4 vertices, one for each quad.

I said there were 2 vertices for point C since your diagram shows the top right quad with a little circle on it. The other 3 quads don't have the circle, so i assumed you were indicating differing textures. Therefore i need 1 vertex for the 3 plain quads and 1 vertex for the quad with the circle on it.

I hope that removes some of the confusion

Yes thanks I have better understanding now, I appreciate you taking time to explain, I'm sucker to learn the techniques to create voxel worlds.

Btw one last question, since you are using this particular techniqe, that that mean that using this tehnique withouth modifications, having boxes half size would not work that well with lightning? For example if you would throw in "steps" that player can step on and they would be 1/2 size of normal boxes.

I already have half blocks in. I just treat them like normal fullsize blocks for lighting but draw them half vertical size. The snow in my videos is a half size block.

Hats off, what you did with this engine is amazing I'm so jelous I can't be this good!

One tip for the lighting algo concerning only the "sunlight" : you only have to try to propagate the sunlight up and down when the value is not max (= not light sources).

It drops a lot of propagations tests !

Thanks for all the tips and answers, I have much better understanding now, I may even be able to whip up something that looks like something

I can't realize this technique because i can't understand one thing:
You said that first step - set all lightness of all blocks in chunk to 0. What about some lightness that comes from neighbor chunks? It will be lost. Example - player place light source on the border of chunk. Light from this source might be on 2 chunks (or more) but if we update second chunk, which not exists this source, it will be not-lightning. What about this situation? Thank for answering!
Sorry for all mistakes, my english is very bad.

Once you clear the light and then put in basic light sources. The trick is to fill with a margin of an extra block round the area you cleared.

So, if you clear 32x32 you then fill 34x34.

This has the effect of 'pulling' in the light from neighbouring chunks.

There is one other spot you may have problems with; consider a river of lava cooling down...

The lava spans multiple chunks.
It cools at the same time over the whole river.

If you process one end of the lava and remove the light because it has completely cooled, you clear the area where you remove the light(s) and 'pull' in light from your nearby chunks with the fill.

You have now pulled in light from a neighbour chunk that you are going to remove light from the very next operation.

I've found that this can leave remnants of light when you try to perform mass operations, like cutting off the flow of lava etc.

The way to solve this is to clear All the light chunks that are affected and then fill them All in one operation rather than as seperate chunks.

I've solved this problem by division lightness computation on two stages:
1. Computing light in all chunks in the world considering only sunlight and light sources inside chunks. Looks like that any chunk isolated from another one. This is a long stage.
2. Computing light (without nulling lightness) considering only borders. All chunks gets information from their neighborhoods. This's short stage.
I've done some optimizations and get result: 33x33 chunks computing in ~25 seconds (sunlight can move through 15 blocks).
p.s. as you know my English is very bad, can you correct my mistakes please? This is a good help in learning.

Archidevil, did you have another post here? I was going to write something in reply but i see it's gone now.

Slaihne wrote:Archidevil, did you have another post here? I was going to write something in reply but i see it's gone now.

Yeah, it was here. But i've deleted it. So, can you tell me in detail - how works your light algorithm. All details - what to do when the light reaches border. So i can't make this in my voxel engine. I need only 1st part - propagation of light in blocks. Problem is: how to solve problems with light on borders? I can make 2 images of problem if you want.

When i do the lighting i don't work on chunk boundaries.

If a player removes or adds a block you have to worry about 2 different things; has light been blocked or has it been unblocked.

Rather than mess about with 2 seperate cases i regenerate al llight in the affected area.

the basic concept is to clear out a region of 33 x 33 x 33 blocks centered on the altered block. This is 16 blocks in all directions. The light in this area is set to zero.

Then you fill in the default light sources back into this darkened area. This mean 'pulling' the sunlight down from the single block layer above the area and propogating it down as well as putting in the light sources where they should go within the area.

Now you should have the basic light all set up.

So now you go through a region of 35 x 35 x 35 blocks (note the 35 not 33) and perform a 'floodfill' type routine on each block checking to see if the fill hits an already illuminated block that is brighter than what you wanted to place (this gets you out of this branch of the fill).

By erasing 33x33x33 you have removed all trace of any light that the altered block may have affected. By filling using 35x35x35 you are pulling in neighbouring light and re-filling it (the flood fill doesn't have to start at a light source) into the area you have darkened.

Thanks - my general problem was: i thought that you recalculate lightness in all chunk, which was modified.
So, how do you store data (cubes, chunks) in your game?