
Modern textureless deferred rendering techniques - z3phyr
https://forum.beyond3d.com/threads/modern-textureless-deferred-rendering-techniques.57611/
======
vardump
Disclaimer: I've played with toy deferred renderer a bit, not a graphics guy.

This not about "traditional" deferred rendering, but textureless deferring
rendering. No textures, surface normals, material information or other data
typical to deferred renderers is baked in the per pixel MRT buffers. Just
barycentric coordinates and a "pointer" to the geometry and material data.

In this technique, and texturing (unlike in traditional deferred rendering) is
only done at the final texturing and lighting pass (or passes). Thus no
texturing or lighting will ever need to be done for occluded objects.

Textureless deferred rendering technique can get away with rendering
significantly less and with a tiny 64-bit (8 bytes) per pixel buffer. Only 2x
16 bits for barycentric coordinates and triangle + instance id stored in 32
bits -- as a memory pointer or with some type of packing, like 16 bits for
both.

This saves a lot of buffer memory (2-4x), computation (each screen pixel is
lit and textured just once) and memory bandwidth.

Traditional deferred rendering is used so that lighting and material
calculations (fragment shader) needs to be done just once per rendered screen
pixel. It requires a huge buffer, usually either 16 or 32 _bytes_ per each
screen space pixel. Or in other words, 128/256 bits.

Deferred renderers bake texturing in the pre-lighting passes as well as
information about material, surface normal, etc., which the final lighting
pass will use. That's why they have to store so much per pixel data. Just
16-bit per component RGB alone is 8 bytes. That's why they're limited to
relatively small number of materials (or at least parameters for them),
because the final lighting step fragment shader must get all of the lighting
related data from the per pixel buffer.

------
fitzwatermellow
Mozilla Hacks article on deferred shading in WebGL, for anyone looking for
some weekend fun ;)

[https://hacks.mozilla.org/2014/01/webgl-deferred-
shading/](https://hacks.mozilla.org/2014/01/webgl-deferred-shading/)

------
xwintermutex
For people with just some basic computer graphics background that don't know
what this "deferred rendering" is: when this technique became popular, these
[1] slides were popular and inspired many.

[1]: [http://www.slideshare.net/guerrillagames/deferred-
rendering-...](http://www.slideshare.net/guerrillagames/deferred-rendering-in-
killzone-2-9691589)

~~~
CliffyA
It even inspired a WWII plane game to use deferred rendering, which optimizes
for having many lights on an object. Even tho they for the most part had only
one light source (the sun)...

[https://www.youtube.com/watch?v=UuDPTw_j6zw](https://www.youtube.com/watch?v=UuDPTw_j6zw)
(it's somewhere in this presentation, but I'm on mobile ATM)

~~~
joeld42
Many lights is not the only advantage. There are some deferred decalling
techniques that I could see be very useful to a flight simulator for terrain
drawing, for example.

------
ginko
In tiling rendering architectures like you usually see them on mobile GPUs you
can also use pixel local storage[1] to have G-buffer information never leave
the on-chip memory. The Vulkan api also introduces subpasses that implicitly
support this.

[1]
[https://www.khronos.org/registry/gles/extensions/EXT/EXT_sha...](https://www.khronos.org/registry/gles/extensions/EXT/EXT_shader_pixel_local_storage.txt)

------
deepnet
Deferring a Phong shader gives 'good enough' dynamic lighting for 2D dynamic
sprite lighting and is fast.

[https://29a.ch/2010/3/24/normal-mapping-with-javascript-
and-...](https://29a.ch/2010/3/24/normal-mapping-with-javascript-and-canvas-
tag)

~~~
ashmud
The demo on the left (the face) has a disorienting "ripple" effect, at least
in FF44. The Buddha appears fine, though.

------
Negative1
No props to Wolfgang Engel on his Light Pre-pass Deferred Renderer or am I
missing something?

