I think it is cheaper to apply additional TEXCOORD than subdividing faces into 6cm (the smallest voxel possible) (or rather n cm) sqares and creating lot's of actually unneeded vertices. Well, we'll see.

Kiel, this is not a crazy idea at all.

I am writing a similar game, and because of my requirement to render huge distances, I have spent a great deal of time on optimization.

I was using per-vertex light data, but as you point out this causes many unecessary subdivisions in the meshes; everyplace, such as under a tree, in my world, the large meshes would degrade into 1x1 meshes.

For one particular world region, containing 382,000 visible faces, my meshing alorithm was only reducing this to ~250,000 quads. Once I moved my lighting data out of the vertices and into its own texture, that number dropped to 145,000 quads, and my frame rate went up by around 50% (on mid- to high-end hardware, and between 25% and 100% on lower end hardware).

I am using 2D, and not 3D textures, and I am packing them so as not to push any more texture memory than is necessary.

I'd love to see some screen-shots or otherwise hear about your project. I am doing this purely because I love it :-)

HScottH,

My project is right now under heavy development, but really early alpha version will be ready soon. Also my website is being created.

I have quite a bit of more important work before I come to lighting system, but if I make any screenshots, they will be posted right onto my website as well as the download of the game and the entinre GDD (Game Design Document).

If you are interested write a reply here or any kind of message to me and I will supply you with some more information.

Funnily enough I've been thinking about the lighting system in my own work recently, and there's some similarities as I'm using an Octree as well.

You can probably do decent per-vertex lighting the Minecraft way by subdividing the large voxels. In my own game I subdivide large nodes to the smallest voxel size for nearby regions, and use higher nodes of the branch of the Octree for level of detail in the distance. Hopefully you can see the LODs working in this (debug rendering) video. Using this approach has the advantage of fast vertex generation without seams, using skirts between LOD regions. So if you use this approach and have slow moving or stationary lights you should be able to do fairly decent lighting which gives you some global illumination like properties.

I'd disagree that deferred rendering doesn't scale well - indeed that's it's purpose. Culling can be done via tiles in DX11+ (or equivalent in OpenGL), see Andrew Lauritzen's work, or you can use the stencil buffers. I've been considering using the voxel octree itself to do CPU side culling, but haven't looked into it yet.

I'm also considering voxel cone tracing or light propagation volumes, doing the work CPU side using the octree and then uploading the results asynchronously to either a light-map or 3D texture cascade. I've no results or even back of the napkin calculations of feasibility yet, but will try to blog the results when I do.

I find it difficult to implement a good LOD in a voxel system that have seamless transitions when you change the distance. In your movie clip, there is such a change at 19s.

Yes, it's tricky. Eric Lengyel's transvoxel algorithm is one of the best for marching cubes (http://www.terathon.com/voxels/), and Miguel Cepero's Voxel Farm seams are pretty decent http://procworld.blogspot.fr/2013/07/emancipation-from-skirt.html, though I'm not sure what technique he uses as he has dual contour voxels. I use simple skirts for now with the skirt normal adjusted to minimize transition contrast, though I've not had time to cater for certain edge cases such as the one you spotted.

The main issue with shadow maps for me is the lack of light propagation in occluded volumes, such as caves. Otherwise they're great.