How do I render light propagation volume without aliasing?

Question

I have two major problems in my LPV implementation:

1. The "blockyness" of my LPV light rendering (yes am using trilinear interpolation when sampling for the coefficients)
2. The flickering that happens as I rotate the camera (see this question )

Is see on the internet people do manage to get very smooth lighting and almost zero flickering across a surface, don't see how that's possible given how coarse the LPV (32x32x32 in my case) is..

Here is one with trilinear sampling, you can see it aliasing, specially in the slanted wall in the background:

Here is one with GL_NEAREST, this I use to tell me which pixels are falling on which LPV boxes. The coarseness of the LPV is obvious, I can't comprehend how you reconstruct smooth lighting from this.

Answer 1

I've done lots of research on this problem and I think I've found some hints as to why things look so blocky. This is text straight from "Octree-Based Sparse Voxelization using the GPU and Hardware Rasterizer":

Once voxel-fragments have been generated in the fragment shader, their values can be written directly into the destination 3D texture using image load/store operations. However, multiple voxel fragments from different triangles can fall into the same destination voxel in arbitrary order. Since voxel fragments are created and processed in parallel, the order in which they will be written is not predictable, which leads to write-ordering issues and can create flickering and non–time-coherent results when dynamically revoxelizing a scene. In standard rasterization, this problem is handled by the ROP units, which ensure that fragments are composed in the framebuffer in the same order as their source primitives have been issued.

I'm using deferred shading in my program, which means that multiple fragments from the G-Buffer can contribute to one voxel, as I rotate the camera I get flickering because it all depends on which fragment gets selected to contribute to the voxel, that's pretty much random. The paper goes on to discuss solutions to this problem which rely on OpenGL 4.2 and above, Apple only supports up to OpenGL 4.1.

In hindsight, othographic projection could help here, as long as I adjust the glViewport in such a way that the LPV fits tightly in the rendered scene, that way every pixel matches exactly to a texel in the LPV.

The blockyness issue has to do more with under-sampling the scene and I don't know if there is a solution that fixes it perfectly. (search for Nyquist Theorem from signal processing)

If you look at the demos from people who have implemented this, you see lots of straight line walls lit by sunlight (orthographic proj. is perfect for this because is a directional light) which I bet are aligned to the LPV. In my demo scene, I happen to choose the worst case scenario inadvertently. Look at the plane in the screenshots I posted, it looks very smooth, this is because is aligned with the LPV, this is in contrast to the slanted wall in the background.

One last thing: in order to avoid cracks when you render the LPV in meshes where the incident angle of the camera to the normal of the mesh/triangle is large, it is a good idea to consider Conservative Rasterization.