CODEWITHSUNDEEP
openglgraphicsdeferred-rendering
nOvoid
nOvoid

Reputation: 109

What should a G-Buffer commonly include in a deferred rendering process?

I am trying to implement a simple deferred renderer using OpenGL and having read various tutorials and papers describing the topic, most only offer very minimalistic or abstract description to the structure of a G-Buffer - usually containing diffuse, depth and normal buffers.

Yet even a simple graphics engine wouldn't be complete without some sort of material rendering, using textures, adjustable specular lighting and more. Adding additional buffers for all properties would obviously bloat the G-Buffer a lot so what is the preffered method of obtaining all that per-material data in the second rendering pass?

In my OpenGL implementation i use Framebuffers rendering diffuse, normal and depth to GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1 and GL_DEPTH_ATTACHMENT respectively. Is there a way to even store an ID or similar for materials, preferrably in OpenGL 3.3 core?

Upvotes: 1

Views: 2133

Answers (1)

user1629823
user1629823

Reputation:

One way to store material ID is by passing that ID to fragment shader as a uniform, and write it to your G-buffer. Assuming that your buffer is 4 channels RGBA8, and material ID is unsigned 8-bit int, which supports 265 materials, your fragment shader in G-buffer pass will look something like this (pseudo):

uniform uint inMatId;
uniform sampler2D inTexture;
void main()
{
    outputColor = vec4(texture(ourTexture, TexCoord).rgb, inMatId/255); 
}

Of course, the best way to draw like this is to sort objects by material then draw. Notice that I devided the material Id by 255 to map it to [0,1] range. During the shading pass you can read it back by multiplying by 255. The same approach can be use for pretty much every other types of data that you need.

Upvotes: 2

Related Questions