Tag Info

Hot answers tagged

37

The defining characteristic of deferred rendering is that it essentially changes the complexity of scene rendering from O(geometry * lights) to O(geometry + lights). This is achieved by first rendering the scene using shaders designed to output basic attributes such as (at a minimum) position*, normal, and diffuse color. Other attributes might include ...


31

Deferred shading is only a technique to "defer" the actual shading operation for later stages, this can be great to reduce the number of passes needed (for example) to render 10 lights which needs 10 passes. My point is regardless of the rendering technique you are using there are certain possible rendering optimizations that reduce the number of objects ...


13

This is an old question, but I wanted to mention something. Deferred rendering hits GPU bandwidth hard. The lighting passes fetches from anywhere from 3 to 5+ textures, for every pixel on the screen, for every light. That's a lot of bandwidth. This hurts mobile GPUs, an increasingly important segment, more than others. Yes, they're low-power chips, but ...


12

A semi-common approach is to make what I call shader components, similar to what I think you're calling modules. The idea is similar to a post-processing graph. You write chunks of shader code that includes both the necessary inputs, the generated outputs, and then the code to actually work on them. You have a list which denotes which shaders to apply in ...


11

Additive blending, i.e. glBlendFunc(GL_ONE, GL_ONE) and glEnable(GL_BLEND).


10

In deferred shading all the material properties are rendered into the G-buffer, e.g. albedo, normals, roughness, metalness, etc. that are needed for BRDF evaluation. After this step shading is performed for pixels within light volumes using light and material properties as input to the BRDF. The problem with deferred shading is that more complex BRDF's (e.g. ...


9

need to handle rendering large astral bodies from extreme distances Consider the scale of the Solar System. 8 planets, and we're currently on one. Our closest neighboring planet, Venus, is almost the same size as Earth. Yet, it is so far away from the Earth that it appears as nothing more than just another star in the sky. Jupiter is the largest planet ...


7

The attenuation equation you posted, strictly speaking, does not allow for any finite light radius, since the attenuation will not go to zero at any finite distance. However, in practical terms there will be some distance at which the light becomes too dim to see. If you define a luminance threshold, you can plug this into the attenuation formula and solve ...


6

Also referred to as Deferred Shading, Deferred Rendering refers to a wide set of possible rendering paths that store intermediate results into textures, then complete the rendering equation later by sampling the intermediate data. Geometry buffers are an early example, where the scene is rendered into a series of buffers that contain e.g. the position, ...


6

You can easily use the Z-Buffer to render only the pixels that matter during skybox/light passes. I render the skybox last (after all lights). When rendering the skybox, make sure your depth buffer is still intact and use GL_GEQUAL for the depth function. Then in the vertext shader of the skybox, set the z value of gl_Position to its w value. This makes ...


6

The skybox should be drawn after all lighting has been done. It's done exactly the same way as in a forward-shaded renderer; it shouldn't go into the G-buffer at all, and the lighting shaders shouldn't need to know anything about it. I don't think there's any need to fiddle around with the viewport depth range or stencil either. If you use a projection ...


6

Your problem is not related to deferred shading whatsoever, you need to implement the basic core elements of a renderer before you try to speed up some specific part. When you have finished with what concept3d has explained, if you actually find that you need to optimize the deferred shader itself (as opposed to the whole rasterization pass) you can ...


5

Right, normal mapping isn't done by componentwise multiplying the object normal and the texture normal. They're vectors, and that operation doesn't make geometric sense for vectors. For the standard way of doing normal mapping - tangent-space normal maps - the idea is to construct a 3x3 tangent-to-world matrix at each fragment and transform the texture ...


5

Optimising render state changes is definitely good. You should sort the materials by render state, preferably rating more expensive states (texture change, shader change) higher. You should render big and visible geometry first, to increase z culling efficiency. Eg level geometry. When there are no expensive render states to change between a group of ...


5

As you highlight yourself, deferred rendering isn't a silver-bullet which solves all problems, and it also introduces new issues. So no, it's probably not the future, nor will it be used in all engines. Instead I think you're going to see a mix of technologies, including forward and deferred rendering used for some time to come.


5

You don't choose which render target to present. The IDXGISwapChain object owns the back buffer (the render target that gets presented); it's automatically created when the swap chain is set up. To draw to the back buffer, you first get a reference to it as a texture by calling IDXGISwapChain::GetBuffer; then you set up a RenderTargetView from that. In ...


5

In your shader, you'll need to remove the position.xyz /= w; as this is what is causing your resizing issue: // Transform position from screen space to world space position = mul(position, InvViewProjection); position.xyz /= position.w; <<-- Comment this out That should do the trick.


5

Anti-aliasing in a deferred shader is a complex topic. WikiPedia lists a number of techniques for doing anti-aliasing in a deferred-compatible way. Typically you'll need to do it after lighting, otherwise you can end up with lighting artifacts. Most approaches I know of do another pass on the scene after the entire deferred pipeline is complete. If you ...


4

1. "The lights in the scene are rendered as geometry" means that you draw a polygon mesh that encloses the light's region of influence. For example, if it's a point light you draw a sphere of the light's radius. For a spotlight you draw a cone, etc. The reason to do this is you are trying to select exactly those pixels on the screen that the light will ...


4

I found the problem. It was a really stupid mistake, I didn't know you had to specify glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_COMPARE_MODE, GL_NONE); to get the correct depth values and thus, I wasn't sampling the Depth values. Now I get a nice SSAO effect:


3

Copy the depth information to the la-buffer and then render normally to the la-buffer using forward shading. All you need to do to copy over the depth information is add this to the light accumulation fragment shader: gl_FragDepth = texture(depthBuffer, texCoord).r;


3

I believe having a lot of ifs in a fragment shader could have a serious performance impact. You could probably use the stencil buffer for this purpose. Or save up to 4 light types in the color channels of a separate rendertarget and do this: fragColor = shadingFun0(...) * texColor.r + shadingFun1(...) * texColor.b and so on. Or as a hack, you can ...


3

What does the projected texture represent? Projective texturing is a means of generating texture coordinates from vertex positions, to make it appear that the texture is projected over the scene like a film projector. Can you still do these computations in deferred rendering? Yes. But when and how you do it depends on what the values in the texture ...


3

You can use any shader to fill the g-buffer, it doesn't have to be generic. That's not the point of deferred, the point of deferred is when you come to do the lighting pass you combine the various render targets in the g-buffer with your lights; your lighting pass is confined to pixels on-screen (rather than shading pixels which may be occluded). But it's ...


3

It's going to depend on the hardware and app, of course, but on current generation GPUs (NVIDIA Kepler, AMD GCN), I believe there is no penalty for using different render target formats at once. On older GPUs you simply couldn't do it; all render targets had to be the same format. Writing out to multiple render targets is usually memory-bound, so you can ...


3

Branching incurs overhead on GPU if the threads take different branches, which leads to serialisation. Thus, if all of your pixels take the same conditional branch, the overhead is negligible. In addition, if the condition is complex, it can increase the number of registers used per thread which can impact performance depending on how much is this ...


3

Final answer, solved the performance problem! Changed my culling loop to this instead (based on the one used by Dice in BF3) uint threadCount = WORK_GROUP_SIZE * WORK_GROUP_SIZE; uint passCount = (numActiveLights + threadCount - 1) /threadCount; for (uint passIt = 0; passIt < passCount; ++passIt) { uint lightIndex = passIt * threadCount + ...


3

The draw order often implied by tutorials, where you do something like this: for each object: for each pass: apply pass state draw object is actually backwards from how it makes sense to do it in a "real game" context. Rather, you'd be more likely to do something like: for each pass: apply pass state for each object (grouped ...


2

Yes, you just have to perform regular projective texturing in the GBuffer pass and add to the the albedo. If wnat you want to do is shadow mapping, do it in the lighting pass when you reconstruct the pixel postion


2

yuumei, I do not believe you are accounting for the perspective divide in your calculations. You are correctly determining the depth in the picture plane in your first equation, but then using a simple linear interpolation (mix()). See entry 12.070 here: 12.070 Why is there more precision at the front of the depth buffer? After the projection ...



Only top voted, non community-wiki answers of a minimum length are eligible