I'm interested, I'd love to see a relative simple solution since I'm hurting myself with trying realtime GI (I tried by sampling with nodes per vertex, and now trying SH like the ATI demo does).

If you want it pixel-perfect, you could measure the incoming light for each pixel POV, basically by rendering the surrounding environment. This is how lightMap generators with radiosity can work. But of course, doing that per pixel is way too slow for now. Even when doing it in larger steps (pixel chunks/patches or something) its either very low-res, and/or still slow.

As for your approach, I don't quite understand how you "lit" pixels indirectly. From a light POV, you only the say the pixels that would normally be litten directly as well, just like you can make shadowMaps. If I understand you right, the G-Buffer data you use only contains data of the pixels that the light actually sees. How can you use that data to determine which light(s) / how much / from which direction, the unlit pixels should use? Probably I don't understand step 2 :)

Greetings,
Rick

So if I understand you right, in the final pass you calculate the indirect contribution by checking out all the neighbour pixels. From previous passes, each pixel already has its diffuse/specular/depth(or xyz)/normal data stored in buffers, just like you would do with deferred lighting.

All the surrounding pixels act as lightsources, since they have a reflection and a normal that can be used to determine the light direction. You downsample the buffers in order to gain speed(far less neighbour pixels to check).

Correct? Probably not, but ifso, I've been thinking about something similiar as well, but there a couple of problems. First of all, you can't tell if something is blocking the light between neighbour pixel X and the receiver pixel Y. Imagine a screenshot with a chamber. The pixels from the left wall affect the pixels on the right wall, which is good. But what if there is a large pillar in the center? Unless you do some collision detection on the screenshot for each pixel, there is no way to tell something is blocking the light.

Maybe that is not so bad, since GI doesn't have to be 100% perfect (for now). And with enough bounces, the light from the left wall will eventually reach the wall on the right anyway. But there is another bigger problem. What about all the stuff behind the camera? The wall behind you reflects light as well, but its never rendered in the final pass, so you can't check its pixels as well.


Unless you do it a little bit different. Probably this is what you mean. You mentioned earlier that the G-buffer data is from a lightsource point of view, so basically you would have textures with diffuse/normals/specular/.../ for each light (which can consume quite a lot of memory if you have a lot of lights, but lets forget about that for now). You can check the buffers for each light, and project them in the final pass. For example, one light shines on the wall behind you. You won't render those pixels in the final pass, but its data is stored in the buffers from that light. When doing the final pass, you loop through the pixels in that buffer, check the direction between the receiver pixel and those from the light-buffer. This would add light, depending on the pixel normal, its reflected color, and distance between the 2 pixels.

Collision detection is still difficult though. Imagine all the lighting is done behind the camera. Somewhere behind you, a light is shining on the wall behind you. Everything in front of you will catch the reflected light from the stuff behind the camera, which is good again. But what if there is a another wall between you, the light, and the wall that reflects:

            north------------x------------------|                             ||      ^ camera, looking north||                             ||   ------------wall------    ||      L light, pointing south||                             |------- wall, reflects L ------            south

When rendering pixel X, it will use the buffer from light L. In this case you have to, since the wall between L and the camera is not entirely closed. The problem is that the wall in between is never rendered, so it won't be blocking any light.

Interesting method nevertheless... Little bit difficult to imagine how it exactly performs, I would say just try it :)

Greetings,
Rick

Quote:
actually no - if light points towards the wall it will be included in light gbuffer like you said latter

In the ASCII picture, the light is pointing south, to the wall at the bottom. Well, try to imagine, I couldn't make a better picture :). Anyway, the camera and light L are pointing in the opposite directions. The wall in between will never be rendered since its in none of the view frustums. Not in the final view, not in a shadowMap and/or G-buffer from light L. Therefore I guess its impossible to involve the wall for the collision detection. It will alot of light in this case, but you can't tell it from the light or final screen.

I guess the approach will work in quite alot situations. Not 100% physically correct though, but that is for most of the GI techniques. Its an approximation. However, there are cases where the light leaks through objects if the objects are outside the camera and light frustum. Maybe not that much of a problem, as long as the blocking objects aren't very big. But imagine the ASCII situation, but then with a couple of skyscrapers. Maybe the users won't even notice it, its hard to tell if the indirect lighting is correct or not (you first notice the direct lighting, ambient is an extra to make realism). But you might need to be aware of light popping in when the camera or light frustum changes, because that is an artifact that users will definitely notice.

Quote:
there is no need to keep all gbuffers, iteratively render the lights with deferred shading so you can just allocate one gbuffer and use it for all lights

True. But in case you have quite alot lights, it can slow down the rendering pretty much because you need to switch between FBO's and depth buffers with different resolutions all the time. Its either speed or memory that has to suffer. Also if you want multiple bounces to increase realism, you might need to store the data somehow.

But... as long as you don't have a huge collection of lights and/or keep low resolutions, it won't be that much memory I think. By the way, have you considered storing all light data in a texture array or 3D texture? Might be usefull, since you don't have to swap textures for each light in that case.

When it comes down to performance, I think your technique can run pretty fast, as long as there are not too much lights. The nice thing about other GI technqiues using nodes, is that you don't need to update all the nodes per frame. In case the framerate is low, just do less nodes. Your situation is a little bit different. If you store the g-Buffer data, you don't have to update all lights for each frame as well. But the processing of the lights in the final pass(es) is still quite a heavy operation, for each light and frame again. You could (greatly) reduce it by limiting the lights that affect a piece of geometry. The user won't be able to tell if 10 lights are indirectly shining on a wall anyway. Just pick the strongest lights.

Succes!
Rick