Thanks again you both.
Indeed, the mipmapping issues are giving the tiled look I think. It will be hard to solve, but eventually I'll find something on that. I've also been thinking about scrapping the whole brick idea (which is already problematic on my somewhat older hardware) and to fall back on 3D textures covering the world. Like you described earlier. But, instead of raymarching through the textures (thus sampling 3 textures each step), I could still keep using the VCT octree to see if there is anything useful to sample at a certain point. So, a hybrid solution. I think sampling textures is actually faster than keep using a SVO, but it might be worth a try. Especially if the opacity calculation becomes more complicated (see below).
If I may ask, how do your textures cover the world (texture count, resolution, cubic cm coverage per pixel)? I suppose you use a cascaded approach like they do in LPV, thus having multiple sized textures following the camera. Do you really mipmap anything, or just interpolate between the multiple textures?
Anyhow, you said your solution didn't show banding errors. How did you manage that? Even with more steps and only using the finest mipmap level (which is smooth as you can see in the shots above), banding keeps occuring beceause of the sampling coordinate offsets. In the shots above, you'll see the banding on the wall. The finest brown bands on the wall are sampled from smoothed bricks (mipmap level 0). For the info:
* the smallest octree nodes are 25 cm3
* the ray takes about 4 steps in each node (slightly less, as the travel distance increases each step, depending on the cone angle)
Of course, there still could be a bug in the sample coordinates, but I'd say bandless sampling is just impossible. At least not in the way how I push the ray forwards.
>> Try to remove the opacity calculatuon
Good idea, and just did it. Didn't do any blocking at all, just to see if those dark T-junction corridor parts would catch light now. To exclude eventual other bugs. And... yes! A lot more light everywhere. As you say, the corridors quickly close in, blocking light on the higher mipmapped levels. But, just removing the opacity also leads to light leaks (and much longer rays = slower) of course.
Unless there is another smart trick for this, the only way to fix this is by providing more info to the voxels. In my case, the environment typically consists of multiple rooms and corridors close to each other. Voxels could tell from which room they are. So if the ray is suddenly sampling values coming from another room while the occlusion factor is already high, you know you probably skipped a wall. But yet, this sounds like one of those half-working solutions.
>> The red carpet receives some reflected light from the object in the center
True, but would that really result in that much light? Maybe my math is wrong, but each pixel in my case launches 9 rays, and the result is the average of them. In this particular scenario, the carpet further away may only hit the object with 1 or 2 rays, while the carpet beneath is hits it much more times. In my case the distant carpet would probably either be too dark, or the carpet below the object too bright. In the shot the light spreads more equally (realistically) though.
@Frenetic Pony
Thanks for the OpenGL demo, though it doesn't run on this computer hehe. Trying to dig out the shaders but asides from some common and mipmapping shader, I couldn't find the ray marching part.
Probably Unreal4 GI lighting solution isn't purely VCT indeed, but all in all, it seems to be good enough for true realtime graphics. One of the ideas I have is to make a 2 bounce system. Sure, my computer is too slow to even do 1 bounce properly, but I could make a quality setting that toggles between 0, 1 or 2 realtime bounces. In case I only pick 1, the first bounce is baked (using the static lights only) into the geometry. Not 100% realtime then, but hence none of the solutions in nowadays games are. A supercomputer could eventually toggle to 2 realtime bounces.
And yes, some extra's like SSAO, secundary pointlights or manually overriding the coloring of some parts should stay there. In the horror game I do, we don't always necessarily want realistic lights! Horror scenario's often have large contrasts between bright and dark.
Not sure if I get the Pixar method right... You mean they just add some color to all voxels in the scene?
Cheers