# Tag Info

10

Any techniques that involve raytracing in the fragment shader might want to write Z in order that the depth buffer contain an accurate representation of the raytraced surface. For example: Distance-field ray marching, as seen in many shadertoys and demoscene productions. Here, only a full-screen quad gets rasterized, and all the geometry is generated by the ...

6

If you use alpha blending, then the order of rendered polygons matters even if you use depth writes & tests. E.g. imagine you render two triangles A (red) and B (blue) with 50% opacity where the smaller triangle B is in front of A. If you render A before B then the B will appear purple, but if you render B before A then B will appear dark blue (pixels ...

5

Short answer: Move your near clip plane further away. Depth buffer precision is very sensitive to the near clip plane distance. Complicated answer: Use different math in your view projection. There are a few techniques that can help, some of them are outlined here: https://developer.nvidia.com/content/depth-precision-visualized

5

What your teacher means is that at the end of the frame, once all polygons in the scene have been drawn, the z-buffer will have the same values. This is because the z-buffer keeps the minimum Z within each pixel, over all the polygons drawn to that pixel, and the minimum doesn't depend on the order. If you look at the z-buffer in the middle of the frame, ...

3

Assuming the small triangles form continuous surfaces, although many of the small triangles "fall through the gaps" (so to speak), some should still cover the samples. If on the other hand, they are separate/independent triangles then it will alias very badly. One possible alternative to just doing higher resolutions would be to simulate an Accumulation ...

3

The camera does not need to move for this problem to exist. You can see the mixed polygons as in your linked image even with a static camera. Things are worse with a moving camera because it makes the position of the polygons change, which can lead to different rounding. This means it may not be the same polygon which comes up in front at a given location ...

2

The values for each pixel in the Z-buffer are interpolated from the values at the corners of the triangle during rasterization. To make this work, the projection matrix produces depth values that are a function of the reciprocal of the original depth value in camera-space. That is, the $Z'$ value in each transformed vertex is of the form $aZ + b$, where $a$ ...

2

Yes, that's correct. Perspective-correct interpolation works by (for some quantity $u$ to be interpolated) calculating $u/z$ and $1/z$ at each vertex, linearly interpolating those values in screen space, then calculating $u = (u/z) / (1/z)$ at each sample point. This is done by the GPU hardware behind the scenes.

2

Congratulations for having progressed so far. Context, first analysis Your explanation: I am using a z-buffer, with one stored length to a wall for the x coordinate of each ray. Means the z-buffer is currently one-dimension. One dimension is enough in the first case (your first two images) but not in the second case. To see why, imagine that the red tomato ...

2

That's how I used to initialize viewport (CD3DX12_VIEWPORT). But I didn't realize that there are two additional fields minDepth and maxDepth. Therefore, I have min/max depth set to 0.0 and objects rendered to depth buffer are always black: m_viewport.TopLeftY = 0.0f; m_viewport.TopLeftX = 0.0f; m_viewport.Width = static_cast<float>(m_windowSize.x); ...

1

The code for mip1 and mip2 (and higher mips if you have them—SSR ray marching can benefit a lot from higher mips) is identical except for which mip is being read and written; you don't need separate PSOs for those. Instead of creating bindings for mip0, mip1, mip2, you could rather create bindings for "source mip" and "dest mip" and set ...

1

The Z buffer used to be specialized memory set aside for a single purpose, some web sites still explain it like that, but no longer. Now the Z buffer is just a chunk of memory you allocate, or an API like OpenGL allocates on your behalf. The size of that chunk of memory will depend on the type of the Z buffer values, in the example you gave it is a 32bit [...

1

Unfortunately, I don't know how 3ds max handles its Z-buffer or its near and far planes so I can't give a definite answer. There are many ways the software could handle this. However, you are on the right track. Z-fighting occurs when there is not enough numerical precision to distinguish two "objects" from the scene rendered at the same pixel. In such ...

1

As others mentioned, z-fighting/stiching occurs even if the camera is not moving. However, when the camera is moving and you're getting z-fighting, it will appear as though the polygons are flickering. This link helped me to understand the depth buffer much better. Here he generates depth values and simulates the different kinds of precision errors you ...

1

Z-fighting is not related with camera movement. But this issue can be avoided by moving the near plane of the view frustum a little further away from the viewer. As you know, depth testing is the stage in the graphics pipeline which is used to determine whether one pixel is in front or back of the other pixel. It is done by having a buffer known as the z-...

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