1
\$\begingroup\$

Recently I have programmed a raytracer for fun and found it beutifully simple how shadows are created compared to a rasterizer. Now, I couldn't help but I think if it would be possible to implement somthing similar for ray tracing of shadows in a deferred renderer. The way I though this could work is after drawing to the gbuffer, in a separate pass and for each pixel to calculate rays to the lights and draw them as lines of unique color together with the geometry (with color 0). The lines will be cut-off if there is occlusion and this fact could be used in a fragment shader to calculate which rays are occluded.

I guess there must be something I'm missing, for example I'm not sure how the fragment shader could save the occlusion results for each ray so that they are available for pixel at the ray's origin. Has this method been tried before, is it possible to implement it as I described and if yes what would be the drawbacks in performance of calculating shadows this way?

\$\endgroup\$
4
  • \$\begingroup\$ deferred rendering != deferred shading. it sounds like you're referring to the latter. \$\endgroup\$ Nov 29, 2012 at 17:56
  • 1
    \$\begingroup\$ I didn't know there was a difference between the two. What is the difference really? \$\endgroup\$ Nov 29, 2012 at 18:03
  • 1
    \$\begingroup\$ Deferred rendering is when a GPU buffers and preprocesses geometry before rasterization. Deferred shading is a multi-pass lighting algorithm. A lot of folks mistakenly use "deferred rendering" when they mean "deferred shading" so it can be a little murky if you just Google the terms. (Likewise, a lot of folks mistakenly use "deferred shading" when they mean "light pre-pass" or "inferred shading" or so on.) \$\endgroup\$ Nov 29, 2012 at 18:45
  • \$\begingroup\$ "Draw them as lines of unique color" - draw them where? If you're drawing these lines in screen space, they'll be occluded by anything that happens to be closer to the camera, even if it shouldn't block the light. And they won't be occluded by anything that the camera can't see, even if it should block the light. The only way this makes sense is if you draw in light space...in which case you're just doing shadow mapping. \$\endgroup\$ Nov 29, 2012 at 22:12

1 Answer 1

0
\$\begingroup\$

The point of deferred shading is ambient occlusion samples a small number of pixels surrounding each pixel in the depth buffer. That's what makes it fast and real-time.

If you're talking about ray-casting in the deferred shader, you're significantly increasing the cost of deferred shading.

If you're ray-casting in the GPU to figure out your deferred shading shadowing, you may as well raytrace the entire scene.

\$\endgroup\$
2
  • \$\begingroup\$ Ambient occlusion is just that though, it's not calculating actual shadows. What I was trying to describe is a replacement for shadow mapping / shadow volumes. I do recognize that texture lookups are costly and I thought what I described would be possible with no texture lookups or only a few. My intention was to draw lines for all lights at once instead for each light, but in this case I do see the problem of rays occluding each other. This could be perhaps overcome by checking if the occlusion is only a one pixel occlusion (Here you would need texture lookups). \$\endgroup\$ Nov 29, 2012 at 18:11
  • \$\begingroup\$ After some thinking, I've realized that you indeed need texture lookups, i.e. having calculated the ray origin and direction for each pixel, you have to do an AND reduction on the pixels the ray covers. This could perhaps be optimized using mipmaps to quickly find the pixels that are occluded and thus minimize the texture lookups. But you would probably still need to do this on a per light basis due to memory limitations, which kinda beats the purpose (calculating shadows for all lights in one pass). \$\endgroup\$ Nov 29, 2012 at 19:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .