2 ms·

It stand for geometry buffer. It looks like none of the replies led with that. If you render positions into a pixel buffer and normals into another pixel buffe

It stand for geometry buffer. It looks like none of the replies led with that. If you render positions into a pixel buffer and normals into another pixel buffer, you can shade the pixels and avoid shading lots of fragments that will be hidden. It gets more complicated obviously (material IDs, reflection roughness, etc.) but those are the basics.

account42 6y ago
> If you render positions into a pixel buffer and normals into another pixel buffer, you can shade the pixels and avoid shading lots of fragments that will be hidden. Avoiding unnecessary shading is only one small reason to use a G-buffer - you could just do a depth pre-pass for that. The bigger advantage of deferred shading is that it gives you a lot more flexibility with lighting, letting you decouple lighting complexity from screen complexity. This is especially useful with many tiny lights that only affect a small portion of the screen.
- CyberDildonics 6y ago
  I didn't say it was the only reason, but it is a big reason. Even if you use a depth map to exit early on fragments you are still going through all your geometry twice, once to get your depth map and again to do all your shading. The history of renderman (prman) went in a similar same way, though not through using actual g-buffers. Originally it would shade and then hide because of memory constraints and displacement of micropolygons happening in the surface shader and not in a separate displacement shader. Eventually the architecture shifted to try to do as much hiding as possible and split out displacement shaders into a separate type. Another thing that can be done with g-buffers is using mip-mapping and filtering of the g-buffer to do some sampling or effects on lower resolutions. Pixels can also be combined into distributions instead of just averages, though I'm not sure how much this is done currently.

account42 6y ago

> If you render positions into a pixel buffer and normals into another pixel buffer, you can shade the pixels and avoid shading lots of fragments that will be hidden. Avoiding unnecessary shading is only one small reason to use a G-buffer - you could just do a depth pre-pass for that. The bigger advantage of deferred shading is that it gives you a lot more flexibility with lighting, letting you decouple lighting complexity from screen complexity. This is especially useful with many tiny lights that only affect a small portion of the screen.

CyberDildonics 6y ago
I didn't say it was the only reason, but it is a big reason. Even if you use a depth map to exit early on fragments you are still going through all your geometry twice, once to get your depth map and again to do all your shading. The history of renderman (prman) went in a similar same way, though not through using actual g-buffers. Originally it would shade and then hide because of memory constraints and displacement of micropolygons happening in the surface shader and not in a separate displacement shader. Eventually the architecture shifted to try to do as much hiding as possible and split out displacement shaders into a separate type. Another thing that can be done with g-buffers is using mip-mapping and filtering of the g-buffer to do some sampling or effects on lower resolutions. Pixels can also be combined into distributions instead of just averages, though I'm not sure how much this is done currently.