Ever since I got a taste of Atomontage and how awesome it is, I've been studying more about voxel compression and CPU usage, hoping to figure out how if we might be able to achieve something similar. So I haven't really spent a lot of time on the baked-light meshing technique. The naiive method of using 4 vertices for every tile still works, and at least this way you get to share the vertices, so that's ~1/4 the geometry usage right there, but we should still be able to do better than that.
A big part of it is I'm having trouble visualizing how this fits together. You have a polygon, triangle or quad, doesn't really matter which, and light values on the vertices. Light is smoothly interpolated between the points. So long as the light has a natural gradient, this should work perfectly, only it doesn't.
Minecraft light propagates with manhattan distance from the light source, which produces a diamond shape, rather than a circle. The easiest way to render the light gradient is to set two point on a triangle on corners with equal light levels and point the third towards the light source. So 4 of these triangles make up the diamond shape of a torch light, roughly. But, through the magic of interpolation, if you move one of those outer points closer to the light source, you should still get the exact same result. For some reason, that is really hard for me to picture, and it's making the logic difficult to work out.
Then there is the matter of light level being on the corners and not the center of blocks. This means the gradients won't be perfect. A diamond light source becomes an octagon, and the central axis have an even gradient, while everything else is 45 degrees. It does pretty much require using triangles instead of quads to get the edges correct, or it will add a lot of wasteful vertices, so triangulation becomes that much more important to solve efficiently.
I really need to start graphing this out.
Another rendering update
-
fr0stbyte124
- Developer
- Posts:727
- Joined:Fri Dec 07, 2012 3:39 am
- Affiliation:Aye-Aye
-
fr0stbyte124
- Developer
- Posts:727
- Joined:Fri Dec 07, 2012 3:39 am
- Affiliation:Aye-Aye
Re: Another rendering update
It's been forever since I've updated this thing, and even this isn't really an update because I am still busy with job stuff. Story of my life.
Anyway, looks like Minecraft 1.5 will continue to have lighting errors (this one), which is a problem for the render engine.
There are a couple rules which need to be accepted in the way smooth lighting is handled for anything in Minecraft to work. The first is that light level is specific to a face on a block, but the actual values are stored at the corners. These values can be at most ±1 level from the face value, the one exception being fake ambient occlusion, which will drop the corner light by another 1 or 2 levels. The second rule is that all blocks sharing a corner at a specific point in space will all have the same light value at that corner. The one exception here is blocks bordering on the diagonal. They share a corner, but the light can't pass through, so they are treated separately. And that's basically it, those two things.
Normal Minecraft terrain is always going to have steady gradients, fluctuating predictably across a space. This is a necessary requirement for the reduced polygon rendering, as we won't be able to mark the absolute light level on each individual tile. If these artifacts are still in the game and we try to mimic it with the new method, it's going to break because those gradients are physically impossible to resolve in the new model. Hopefully it gets fixed before it becomes a problem for us. We'll have to see who gets done first...
Anyway, looks like Minecraft 1.5 will continue to have lighting errors (this one), which is a problem for the render engine.
There are a couple rules which need to be accepted in the way smooth lighting is handled for anything in Minecraft to work. The first is that light level is specific to a face on a block, but the actual values are stored at the corners. These values can be at most ±1 level from the face value, the one exception being fake ambient occlusion, which will drop the corner light by another 1 or 2 levels. The second rule is that all blocks sharing a corner at a specific point in space will all have the same light value at that corner. The one exception here is blocks bordering on the diagonal. They share a corner, but the light can't pass through, so they are treated separately. And that's basically it, those two things.
Normal Minecraft terrain is always going to have steady gradients, fluctuating predictably across a space. This is a necessary requirement for the reduced polygon rendering, as we won't be able to mark the absolute light level on each individual tile. If these artifacts are still in the game and we try to mimic it with the new method, it's going to break because those gradients are physically impossible to resolve in the new model. Hopefully it gets fixed before it becomes a problem for us. We'll have to see who gets done first...