Hey hey, I am currently working on lights. I am only starting to get a basic understanding of them. And I still have to learn the mathematics behind them.

But I've come far (in my eyes atleast), I've created a light source, and defined it's "length" if you would. And also I have positioned it.

        light.setParams(GL_POSITION, new Vector4f(lightPos.x, lightPos.y + 0.5f, lightPos.z, 1f));
        glLightf(GL_LIGHT0, GL_SPOT_CUTOFF, 180);
        glLightf(GL_LIGHT0, GL_SPOT_EXPONENT, 2f);
        glLightf(GL_LIGHT0, GL_CONSTANT_ATTENUATION, 1.5f);
        glLightf(GL_LIGHT0, GL_LINEAR_ATTENUATION, 0.5f);
        glLightf(GL_LIGHT0, GL_QUADRATIC_ATTENUATION, 0.2f);

Thoose are my calls. and light.setParams is basically glLightf, but it creates a bytebuffer and converts it to a floatbuffer.



This is the output, the light source is approximately in the middle of the house, one "block/square" is 1f.
As you can see the light is leaking outside the house through the wall. And again since I haven't read up on the mathematics for this lighting process I wouldn't know what caused this.

So my question becomes, is there anyway to stop the light from leaking outside my solid primitives? I have a normal for each of the 6 faces in each "block/square".

i imagine someone will chime in with the fact that you will need to tessellate your landscape.
basically there's not enough polygons between the vertices to define more normals in order to block the lighting.

but I can in fact block the lighting with my glLight parameters? Meaning a solid object will actually stop some light from coming through?

but I can in fact block the lighting with my glLight parameters? Meaning a solid object will actually stop some light from coming through?

As far as I know, no. Remember that polygons are drawn one after another, with no state kept except what state you explicitly set. So after you have drawn the outer walls, the state is lost, and the interior is drawn with no knowledge about the walls' existence. You might also draw the interior first, so just keeping state wouldn't solve the problem.

Shadows are in itself a very complex topic in 3d rendering. You might want to take the shortcut and do what Minecraft does (you're still writing that Minecraft clone, right?): For each rendered face, draw the face in a light color if the cube it faces (note: not the filled cube that "presents" the face) is "lit", and use a dark color if not. Drawing a texture in dark or light colors can be done with glColorxx and an appropriate (color/texture) blending mode -- the latter should automatically be the case unless you turned it off.

A cube is lit if there is only air above it. You'd probably want some optimized data structure again to keep this information ready when rendering. This is the shortcut you're taking with this approach: The nature of your light source is fixed.

As far as I know, no. Remember that polygons are drawn one after another, with no state kept except what state you explicitly set. So after you have drawn the outer walls, the state is lost, and the interior is drawn with no knowledge about the walls' existence. You might also draw the interior first, so just keeping state wouldn't solve the problem.

Shadows are in itself a very complex topic in 3d rendering. You might want to take the shortcut and do what Minecraft does (you're still writing that Minecraft clone, right?): For each rendered face, draw the face in a light color if the cube it faces (note: not the filled cube that "presents" the face) is "lit", and use a dark color if not. Drawing a texture in dark or light colors can be done with glColorxx and an appropriate (color/texture) blending mode -- the latter should automatically be the case unless you turned it off.

A cube is lit if there is only air above it. You'd probably want some optimized data structure again to keep this information ready when rendering. This is the shortcut you're taking with this approach: The nature of your light source is fixed.

Well, I am now drawing all the blocks in a 16x16x16 "chunk", and it works almost perfectly (or well, in my eyes it's perfect compared to my last try), and yes I have implemented a feature that allows a block's faces to be coloured. So that means I only have to do the light calculation whenever light changes.

Thank you again Morin for your brilliant insight

Cheers