jcabeleira

Yeah, these differences between vendors are a bit annoying even though everything is fairly well defined in the OpenGL specification.

For a simple guy like me the only option would be to either buy an AMD or borrow it from a friend just to adapt the source code to it. I'll see what I can do about it, I'd really like to all of you guys to be able to run it. I'll keep in touch.

Thanks for your feedback, guys. I'm sorry to hear that you guys with AMD's are having problems running the demo. Unfortunately I have no means to address this problem since I do not own an AMD graphics card to test it. The demo uses a lot of advanced GPU features so this may be due to the driver not supporting some OpenGL extensions or simply some shader syntax which isn't 100% correct (NVIDIA is more permissive in this aspect). For now assume that only NVidias 600 series are supported, in the meantime I'll try to figure out a way to test it on AMDs.

That happens because of the mipmapping and the lack of correct derivatives. In forward rendering pixels are processed in 2x2 groups, even if some of the pixels don't fall inside the primitve they are still processed as if they were just to provide you with the screen space derivatives that you need to perform mipmapping.

In deferred rendering you haven't such derivatives, you're processing pixels in 2x2 groups but you're reading your data from a buffer so at the edges of objects some pixels may fall inside of a different primitive than the one you'd expect.

The simplest solution for that is to disable the mipmapping for that texture or supply your g-buffer with the screen space derivatives and use them when sampling from the texture.

So I've done the transformation of gsout.oProj*voxSpace*vsout[i].ndcPos, so can anyone elaborate on what "clamping to world-space voxel-sized increments" actually means?

I don't think that trick applies to you. The realtimevoxels use a voxel volume that follows the camera to provide GI around the viewer for arbitrarly large scenes.

The clamping they suggest is to be applied to the volume position, not the voxels/fragments/triangles or whatsoever. That is, instead of the volume following the camera position exactly, it will instead snap to the nearest voxel position.

And although in theory it's a good idea, in practice it doesn't fix the flickering because as the volume moves a slightly different portion of the scene is included in the volume which is enough to change the entire lighting in a noticeable way.

Your images look quite noisy, do you have mipmapping enabled?

Other than that, nice work! Keep it up.