Jump to content
  • Advertisement
Sign in to follow this  
GeneralQuery

Deferred Shading: View Space or Screen Space?

This topic is 2477 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've got the basics of a deferred shader up and running. I store all my G Buffer data and perform all my lighting in view space. However, most of the tutorials and discussions I read on the topic work in screen space. What are the merits and drawbacks of operating in view space and screen space?

Share this post


Link to post
Share on other sites
Advertisement
I'm sure whatever tutorials you're seen don't actually perform lighting calculations in screen space, since it doesn't make any sense to do that. They're probably just referring to the fact that with deferred rendering you can determine the extents of a light's contribution in screen space, and restrict your lighting calculations to those pixels (and also only apply lighting to pixels that are visible in screen space). If you take a closer look at the shader code, I'm sure you'll find that they calculate lighting either in world space or view space.

Share this post


Link to post
Share on other sites

I'm sure whatever tutorials you're seen don't actually perform lighting calculations in screen space, since it doesn't make any sense to do that. They're probably just referring to the fact that with deferred rendering you can determine the extents of a light's contribution in screen space, and restrict your lighting calculations to those pixels (and also only apply lighting to pixels that are visible in screen space). If you take a closer look at the shader code, I'm sure you'll find that they calculate lighting either in world space or view space.


Yeah, I've noticed that since reading over my bookmarks again since making this thread. Would you mind expanding on "you can determine the extents of a light's contribution in screen space, and restrict your lighting calculations to those pixels (and also only apply lighting to pixels that are visible in screen space)", please? I'm stil a bit cloudy as to this aspect. Thanks :D

Share this post


Link to post
Share on other sites
Say you have a single spot light lighting your scene. For that spot light, there's a cone-shaped volume that will be affected by that spot light. So if you can figure out where that cone is in screen space, you can only apply lighting to those pixels and skip the rest. Take a look at the picture I attached, which shows the conical region for a spotlight and the resulting lighting in a scene. The typical way to handle this in a deferred renderer is to actually render some cone geometry for the light, which is rotated + translated + scaled to fit the spotlight. Then you apply lighting in the pixel shader, which restricts your lighting calculations the pixels that need it. You can do the same for point lights with a sphere, rather than a cone. Alternatively, you could figure out a screen space bounding rectangle for the cone/sphere and use that to apply lighting (although this will be more coarse than a bounding volume). You can also apply lighting in screen space tiles of around 16x16 or 32x32 pixels each, and for each tile figure out which lights overlap and apply lighting for those lights only.

Share this post


Link to post
Share on other sites
Thanks for that, it's cleared some things up a bit. I've got a couple more questions, if you don't mind :D So with that cone model, how is the base of it projected onto the geometry? The lit area does not match the shape of the actual geometry of said cone so I think I'm misunderstanding an important piece of the puzzle.

Share this post


Link to post
Share on other sites
Hang on, I think I understand it now. I've re-read some tutorials and posts again so I think I'm there. Let me jot down how I have it worked out in my head:

Say, for a point light, we'd render some geometry like a rough sphere (or even BB, although there's be some wastage shading fragments outside the radius of the light) and use that almost like a stencil mask. The fragments rastered by said rough geometry will be roughly the fragments that the light falls upon. We then use the fragment's screen space position (passed along to the fragment shader by taking the x and y values of the rough geometry vertices as multiplied by the MVP matrix) to lookup our G Buffers and shade the fragments in the same manner as usual forward lighting, passing along the view space (or whatever space is desired) position and radius of the light to be used in the lighting equation along with the G Buffer data.

Does that sound about right?

Share this post


Link to post
Share on other sites
Your explanation sounds about right. The reason that the lit area and the cone's area don't exactly match up is because the lit part is generally the 3D intersection of the cone with the rest of your geometry. So towards the top of the cone you have parts where the cone is "floating in air", and hence those pixels don't get lit. Then towards the very bottom you have parts of the cone that are "buried underground" (it's a bit hard to see from the picture, but the cone extends down through the ground) and those don't get lit either. So while just rendering the cone does give you a potential set of lit pixels, any number of those might end up not getting lit due to being floating in air or buried underground. With depth + stencil testing it's actually possible to reject both of those cases, but that's a more advanced topic that you can come back to later.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!