Tomorrow I will read your posts. Right now I don't have time.

Not sure if you really need screen space ao. What I did was to simply store for each quad on which sides there are other cubes and put gradients on them accordingly.

ok well, I managed to get to get it to work, but its still kind of odd, and I don't fully understand how did I make it work...

I have some fx files, one does the normal rendering to 3 rendertargets2D, which I draw on the screen above with a spritebatch call of the rendertarget, and then another fx file, does the lighting taking as input the render targets from the first file, but the thing is that I had to render a quad to make it work???

You always have to render some geometry on the GPU. If you render text or textures on screen, the SpriteBatch internally renders a quad for you with a texture on top of it. And when you want, for example, post process an image, you want to apply some code (shader) to all your pixels, therefore you render a quad to cover the entire screen and in each pixel the pixel shader will perform the calculations that post process the image (the image you want to post process should be a different texture because you can read the destination texture on a shader). The quad is a medium to indicate to the pixel shader where to perform its calculations.
With deferred renderers, you have the scene preprocessed (G-Buffer). You have the depth of the pixels, the normal in each pixel and some other information. What you do in latter stages is to use this information and compose with other information. For example, in the stage you want, I guest, to calculate an ambient light or directional light, lights that affect potentially all your pixels, therefore you render a quad to cover all screen and in each pixel you read some scene information (from GBuffers) and compose with some other information (light information in this case) to produce the lighting result.
Light intensity is additive, if you want to apply another light, just render another quad (this time with another light information) and you add the new result to the previous result (you need to set the blending states to do this automatically).


Lunch!! When I’m back I continue.

so you had a base color, and just changed the gradient of that color, but you need to check if they are kind of occluded right, so you need to get some samples around the world to test for occlusion, right?

I stored that info in the vertex data itself... for each quad I checked the eight neighbor cubes that can create a concave edge and put that into the vertices (or in my case quads since I used a geometry shader). That way I know where to put gradients without any screen space pass. Or at least you could, I think what I did was render the texture coordinates to a buffer and applied the gradients in screen space for performance reasons.

result:
[attachment=9437:vertexao.png]

top down view of a hole that shows the gradients a little better:
[attachment=9438:vertexao2.png]

hmpf, no idea why the mouse pointer ended up in the screenshots when it's deactivated on screen...