Well, I'm not planning to update the PolyVox external soon (if at all), so I'm happy
Now I'm using 3D textures even for lighting. First lighting experiments seems promising, however, still no proper radiosity simulation

That lighting looks great! So you're storing it in 3D textures, but how are you computing it? Do you compute lighting for every texel in the 3D texture, or only those near the isosurface? Will other game objects be able to pick up the lighting information?

On Chunk Data Regeneration (where meshes and Material ID Textures are generated), now I also generate a 3D texture in following format: RGB = RGB light components, A = Sunlight Level.

The shader looks up this texture, applies the RGB texels to lighten the world and sums it with clamping by the Sun color multiplied by Alpha channel. So, when the game is running, I can change the Sun color without regenerating the chunk data. However, placing a light or removing it forces recalculation of light contributions for affected chunks.

Sunlight is calculated by casting rays from the top of the map to first non-zero material ID. Light levels are stored into my voxel type, so every texel is lit.

Then, while I apply my low-pass filter, I also blur the sunlight value. I blur densities oncce, light values thrice per chunk.

But soon I will write radiosity simulation (on the CPU) which will calculate small distance light spread.

I'm still at research, but colored torches are a must

Just, LargeVolume seems to be slow as hell for direct access, so I very often clone data to temp RawVolumes where I perform heavy processing, calculate there and write back the changes.

I have to refactor the way I store and process chunks, so while sun-casting we work only with RawVolumes. Now I sufferr from many chunk sync problems and when to run the Relight pass for given chunk.

Point lights are with distance calculation and adding color values to otherws so we can mix colors from lights.

Spotlights are pure simulation and relight properly unlights then relights the voxel data.

However, no screen shots yes, because the performance is horrible.
I have to fix my threading, because the concurrent access to LargeVolume is only working if I read/write to different regions, so I am now allowing only one thread at a time to access the volume.

In the future when I light the game objects, corresponding 3D texture will be passed to their shaders, so each vertex is properly lit from this 3D texture's texels.

I am sure that I will have problems with chunk boundaries and game object lighting, but my objects will often be small enough so their light level is only based on the interpolated texel objects reside in.

In case this experiment fails I will be forced to use some classic form of lighting.

Very interesting. For Cubiquity I would like to add computation of ambient lighting (probably storing it in the vertices), but I think directional lighting will be left on the GPU with conventional shadowmaps.



There is indeed some extra overhead with LargeVolumes, as when you access a voxel it needs to look-up which block it is contained in, and then the block might need to be paged in. Multiple sequential access to different voxels in the same block should avoid this overhead, but I expect lighting calculations are likely to involve hitting many blocks at random.

But maybe the performance can be improved... I'd be interested in how a hashmap compares to a map for block look-up. Also, you could try increasing the number of blocks which are allowed to be loaded into memory at a time.

Even a map is no-no here, just plain offset caclculation is enough So I don't have other solution.

That's what the SimpleVolume does, because it has a fixed number of blocks it can just calculate the block index based on the voxel position. I expect it is faster than LargeVolume but I haven't really profiled.

It is. C++'s [][][] does offset calculation. It's tricky to overuse this for calculation, but it's possible (casting to void*** then to int)

Anyway, RawVolume is about 30 times faster than LargeVolume for my light computations - 1.03 sec vs 0.03 - 0.07 sec in Release is ... ;]

STL is the bottleneck.
Also I will try completely bypassing volumes and using VT*** arr = new VT[xmax][ymax][zmax]; - and will benchmark with this one.

I ended up dropping PolyVox's LargeVolume and RawVolume completely. I switched to an C-style one-dimension array with 3D index calculations and based my Chunk Manager on that. The world is stored in these arrays.
http://sourceforge.net/p/kitten-platform/code/HEAD/tree/trunk/pgf/array3d.h

Currently surface extraction runs on a temporary RawVolume created from this world data, but soon I will drop this and will write own surface extractor based on PolyVox's code. (this code is still not committed to the repo).

I do hope you have some success. As you said in your PM, your lighting solution is indeed very data-heavy and will require fast access to voxels. For Cubiquity I would like to add some pre-computed lighting (probably just ambient occlusion) but it's not yet clear if it will be practical. I'll do experiments with that once a faster volume class is in place.

Be aware though that switching to plain arrays can have other problems. Although the PolyVox's Iterator/Sampler has some issues it does serve a useful purpose, which is that it keeps track of which block you are currently pointing at. This makes it faster (in principle) to access neighbouring voxels (which are likely to be in the same block).

Anyway, my current plan is to start looking at the new volume class in about two weeks, though as always that can change!

Now with 3D-array per chunk section, while I run classic for loop on the chunk data, if an index is <0 which is invalid and > of dimension's length, which is also invalid, I use the Chunk Manager's APIs for getting voxels by world position. This API does chunk lookups. In case iteration indexes are in range I sample chunk's array directly. I think it should be way faster than before. I have also to find a way to run marching cubes inside such a loop, but I must first learn how exactly Marching Cubes work.

And this is the second huge refactor of my game.