After using depth testing, the transparency became quite strange

[ouzhou]

I drew two circles. To increase the z-index of the first circle, I tried to modify its depth, but it seems that the background color has become strange.

https://codepen.io/ouzhou-the-bashful/pen/YPKRbXz

I tried adjusting the blend parameters, but I haven't found a solution yet.
The desired outcome is to elevate the hierarchy like CSS does, while ensuring that background colors can be properly overlaid

[greggman]

You have the wrong offset

           { shaderLocation: 2, offset: 8, format: "float32" }, // depth

should be

           { shaderLocation: 2, offset: 12, format: "float32" }, // depth

note that the normal way to do this is without a depth buffer. Just draw things in order, back to front. That's what the browse does with CSS.

[ouzhou]

Thank you for pointing out the error. However, even after the correction, the style still seems odd. Are you saying that I can't achieve CSS-style layering by modifying the depth?

Here's the functionality I want to implement: I need to render many points, and when the mouse hovers over a point, that point should have the highest layer (i.e., appear on top).

If I need to modify the data, I can think of two potential solutions, but neither feels ideal:

Solution 1: Use the CPU to modify the data and send it to the GPU.
Solution 2: Use the CPU to pass the index of the point, and a compute pipeline on the GPU modifies the data.

demo after correction

[greggman]

You can do whatever you want. My only point was you mentioned CSS. The browser does not use a depth buffer. It just draws things back to front by rearranging on the CPU and then drawing in order (see "painter's algorithm")

Setting one circle to the highest depth will not draw correctly though. Let's say you have cricles, A, B, C, D, E in your data in that order. You tell the GPU to draw them but you tell it draw C as the closest depth. You'll run into the same issue you saw before because D and E will get drawn after C so even though you wanted C to be "above" D and E, D and E can not draw behind C. They have to be drawn first so that C can then drawn over them.

In your code you're not drawing circles. You're drawing rectangles with a circle image on them. Each pixel of that rectangle gets drawn. In your case, some with 0,0,0,0 (outside the circle) and others with vsOut.color. So, in the case above drawing circles A,B,C,D,E, with C at the front, 0,0,0,0 gets drawn everywhere the rectangle for C is drawn, including the pixels outside the circle. When D tries to draw, those pixel with 0,0,0,0 are marked as closer than D so D will not be drawn there.

If you don't care about blending you can tell the GPU to not draw a pixel. Change

        if(dist > 1.0) {
          return vec4f(0,0,0,0);
        }

to

        if(dist > 1.0) {
          discard;
        }

This means if it's outside the circle then don't draw the pixel. For more than simple shapes, this is often done with an alpha channel where you check the value of the alpha from some image and if it's below some value you discard. A good example is leaves on a tree. You have a leaf texture, If you draw lots of leaves unsorted then you'll have the same issue. You're drawing rectangles that have leaf textures. Even where the texture is 0,0,0,0 you're still drawing 0,0,0,0 so any leaves behind that leave will not get drawn.

discard will work but it only works for cases where you don't care about antialiasing and blending on the edges of shapes or transparent colors. For those cases, the common solution is to sort on the CPU and then draw things in order, back to front, furthest to closest.

[ouzhou]

Unfortunately, I plan to use smoothstep to apply anti-aliasing to the circle, which means I won't be able to use discard.

So now, the only option is to sort by modifying the data to change the hierarchy.

--- Add a few more questions

Is the priority of depth higher than blend？

 blend: {
              color: {
                srcFactor: "src-alpha",
                dstFactor: "one-minus-src-alpha",
                operation: "add",
              },
              alpha: {
                srcFactor: "src-alpha",
                dstFactor: "one-minus-src-alpha",
                operation: "add",
              },
            },

[greggman]

Yea, sorting is no fun but it's in most solutions for this kind of thing.

One idea: You're storing much of the data in a vertex buffer which means it's always going to be used in the same order. If you use a storage buffer, then you can choose the order since you can randomly access the data. That means, all you'd have to do is pass in a sorted array of indices. Use effectiveIndex = sortedIndices[instance_index] or something like that and then accesss the data you have now in a vertex buffer, in a storage buffer instead.

It's probably not worth it. Your circles are only 4 values right now (x, y, depth, size). But just passing it on.

Is the priority of depth higher than blend？

I'm not sure what that means. It effectively works like this

• for each vertex

  • call vertex shader for each vertex and save off the values of @builtin(position) and the user's inter-stage variables

• for each 3 vertices saved from the previous step

  • for each pixel who's center is in the triangle that these 3 vertices cover
    • call the fragment shader, passing in the interpolated inter-stage variables
    • check the depth of the fragment. If it fails the depth test then don't draw this pixel
    • update the depth buffer for this pixel
    • use the blending options to figure out the final value
    • write the value to the pixel

[greggman]

I don't know if this will be confusing but, note that these two steps

• call the fragment shader, passing in the interpolated inter-stage variables
• check the depth of the fragment. If it fails the depth test then don't draw this pixel

Can be reversed if the fragment shader does not return a value for @builtin(frag_depth). In other words, if the fragment shader does not compute the depth value then the GPU already knows what depth value will be used. So, it can check if the depth test passes or fails early AND not execute the fragment shader for that pixel if the depth test fails. This is just an optimization. The result is the same.