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:
http://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.