11

It is possible to avoid overdraw from opaque objects even with forward rendering by doing a depth pre-pass and using that information to reject any pixel that is not actually visible. However, depending on the vertex cost of your scene, a depth pre-pass may add an unacceptable amount of performance overhead. Additionally, rendering using the pixel shading ...


9

After more analysis, the TL;DR here is that, yes, the slowdown is due to memory locality, and yes the pixel order is to blame. More interestingly, by writing the shader differently, we can greatly surpass the fragment shader's performance—though we obviously shouldn't rely on being able to do that regularly. First, to expand on the analysis: the best way ...


9

Yes, occlusion culling is still worth it. At minimum, a draw call that you skipped due to culling is a draw call that doesn't have to run the vertex shader. Triangle count goes up as quickly as GPUs start supporting more triangles, because why not? With unified architectures, vertex shaders use the exact same hardware that pixel shaders do, so every vertex ...


7

Typically in a deferred engine, you would render unlit objects directly to the color buffer, bypassing the lighting system entirely. You would likely also output zeroes to the G-buffer so that deferred lights don't add anything to those pixels (and possibly also mark them in the stencil buffer, to avoid running the lighting shaders on them, for efficiency). ...


5

PaulHK is right in what he said: you have to consider that there may be more than 2 transparent objects behind each other. Also, the idea of deferred shading is to render the geometry only once to be more efficient. If you render the geometries multiple times, you lose (part of) your efficiency. Moreover, the lighting is deferred, thus you'd need to do ...


4

Projective transformations (represented by 4×4 projection matrices) are invertible. You can go from NDC coordinates back to view space using the inverse of the projection matrix, in the same way that you go from view space to NDC. That is: take your NDC $x, y, z$ coordinates, append $w = 1$ to make a 4D vector, transform by the inverse projection matrix, ...


4

First of all, you don't need position in the G-buffer at all. The position of a pixel can be reconstructed from the depth buffer, knowing the camera setup and the pixel's screen-space xy position. So you can get rid of that whole buffer. Also, you don't ordinarily need tangent vectors in the G-buffer either. They're only needed for converting normal maps ...


4

How are screenspace normals created, and is this step before or after using normal maps or bump maps? They are created after using normal maps. In deferred rendering, you write to the various buffers (diffuse, normal, depth, etc.) in fragment shaders. By this time, the normal maps would have already been read. If it's done before using normal maps, how ...


4

Alan Wolfe is pretty spot on, but I will sum up any way :) render the back-faces of your "unit"-sized-box, [-1;1] sample the zbuffer and transform into light-local coordinates (see our slides for a fast way to do that). early-out of the pixelshader if outside of the box, i.e. if any coordinate in the local-position is outside of -1;1. then do the dot-...


3

You have a bit of a misunderstanding there. The paragraph you quoted doesn't actually say anything about framebuffer objects yet. It just talks about a single texture. While we usually understand a texture as a single image, it is (or can be) actually comprised of a set of images. This might be because it is an Array Texture or, even more common, it just has ...


3

I'm trying to condense my Deferred Rendering G-Buffer. So I have some questions about getting 2-component Screenspace Normals. I know Frostbite and Killzone (the only two AAA company's G-Buffers I could find) use them. I'm confused when you say "screenspace normals", Killzone uses view-space normals, they store the X & Y coordinate of the normal in FP16 ...


3

You have not set a viewport with RSSetViewports. You need to set this to the pixel dimensions of your render target. Without this the viewport will be set to 0,0,0,0 meaning no pixels will be touched. Additionally you have not set a raster state or blend state. It is good practice to set these and can be helpful early on to set the winding order in the ...


3

A very novice mistake, I was compiling with the old HLSL compiler. But why would that be the default? Very strange. For anybody wondering, just right click the HLSL file in the solution explorer and go to properties -> HLSL Compiler -> General, and switch Shader Model to the one you want which was newest one for me (5.0)


2

It depends on the game style just how much culling is needed. For instance first person shooters benefit from this a lot, having a lot of stuff in the frustrum at any one time, while an overhead view RTS does not since you are effectively looking at a plane with things on that plane. Even in an RTS though, doing a "depth only render" to eliminate overdraw ...


2

I can't believe it has taken me this long to find this... So the array I was giving the Index Buffer Desc that contains the data was the wrong one... It was a blank one that I forgot I didn't need, the vector if you look at the code. Look at that garbage. Those are supposed to be the indices... Well at least I know how to use the debugger now, thanks guys ...


2

I would start by looking into deferred decals (you can start here for example, this blogpost has a lot of useful links) If you understand how the positions are calculated and compared with the volume then you should be able to apply the same logic in the lighting phase.


2

Deferred rendering does not have an asymptic complexity of O(lights+fragments). It has a complexity of O(fragments+visibleFragments*lights). What you are doing in deferred rendering is preventing having to calculate lighting for many fragments that cover the same screen pixel. Once you have found which ones are visible, all of those still have to calculate ...


1

Broadly speaking, the way to deal with this is to check the depth value for that position on the screen. If the value is the value you cleared the depth buffer to, then you didn't write anything to that fragment.


1

This question is a bit too broad to answer, but I'll try. Right now you have a screenshot and you are not really sure whether it's correct or not, and if it turns out it is not, it will be difficult to know what is incorrect about it. I would recommend to split your problem into smaller, isolated, problems that can be validated separately. For example, is ...


1

A fundamental assumption of deferred shading is that there will be only one surface, and therefore only one depth, at a given pixel. An effect that contradicts that assumption will require some sort of special handling in a deferred renderer. Translucency, because it allows to see through multiple layers, is such an effect and therefore will need its own ...


1

For completeness (and in addition to Nathan Reed's answer), I explicitly add the inverse projection matrices for perspective and orthographic cameras. Perspective Camera $$\begin{align} \mathrm{T}_{\mathrm{view \rightarrow projection}} &= \begin{bmatrix} \mathrm{T}_{00} &0 &0 &0 \\ 0 &\mathrm{T}_{11} &0 &0 \\ 0 &0 &\...


1

This is based on the formula for a sphere that expresses its surface $z$ as a function of $x, y$: $$z(x, y) = \pm\sqrt{r^2 - x^2 - y^2}$$ So, if $x, y$ is the vector from the sphere's center to your sample point, the total length of the line segment (both occluded and unoccluded parts) is the distance between the top and bottom surfaces, which is $L = 2\...


1

Your indices are wrong, they should start at 0. Correct indices: unsigned int quadIndices[] = { 0, 1, 2, 2, 1, 3 };


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