Overlay: Wireframe: New method to avoid zfighting with geometry
ClosedPublic
Actions

Authored by Clément Foucault (fclem) on Mar 25 2020, 8:51 PM.

Details

Reviewers

Brecht Van Lommel (brecht)
Campbell Barton (campbellbarton)

Commits

rBe000dcb84908: Overlay: Wireframe: New method to avoid zfighting with geometry

Summary

This method gives really nice results but has some downside:

Require a depth copy or loose the ability to write wire depth to the depth buffer and have correct depth ordering of wires. This patch use the former, with its associated cost.
Require some depth sampling and prevent early depth test (i.e: has some performance impact).
Has some relatively minor instability with geometry that are perpendicular to the view and intersecting with other geometry.

Pros:

Compared to a fullpass approach this is surely going to have less performance impact and much higher quality.
Removes the additional vertex offset. (see T74961)
Fixes all half edges z-fighting.

I'm just not sure if this is worth the cost.

Diff Detail

Repository

rB Blender

Branch

tmp-wireframe-zfighting-fix (branched from master)

Build Status

Buildable 7315
Build 7315: arc lint + arc unit

Event Timeline

Clément Foucault (fclem) created this revision.Mar 25 2020, 8:51 PM

Harbormaster completed remote builds in B7294: Diff 23092.Mar 25 2020, 8:51 PM

Clément Foucault (fclem) edited the summary of this revision. (Show Details)Mar 25 2020, 8:53 PM

Clément Foucault (fclem) edited the summary of this revision. (Show Details)Mar 25 2020, 9:04 PM

What is the cost in numbers (time, memory)?

Irfan Celik (irfan) awarded a token.Mar 25 2020, 9:59 PM

Asher (ThatAsherGuy) added a subscriber: Asher (ThatAsherGuy).Mar 25 2020, 11:52 PM

In D7233#172986, @Brecht Van Lommel (brecht) wrote:

What is the cost in numbers (time, memory)?

Memory is using a temp depth texture which is likely to be reused in other places. It's also not too bad (32bits per pixels only since it's only a depth texture).

In terms of timing it seems to not do much difference here on my AMD workstation (AMD Radeon (TM) Pro WX 7100 Graphics) and measured a ~1ms difference on the wanderer scene without animation with a roughly 3Mpx viewport. This is mostly due to the blit.

noki paike (amonpaike) awarded a token.Mar 26 2020, 8:23 AM

Tobias Fuchsberger (Kronk) awarded a token.Mar 26 2020, 11:42 AM

I'm guessing it's worth it? I don't really have a good insight in the relative cost of this kind of thing.

This revision is now accepted and ready to land.Mar 26 2020, 12:49 PM

On my intel iGPU i lost 8ms on a 500K tri scene. I found that the primary issue is modifying the gl_FragDepth which bypasses the early depth test.
I'll enable this path only if using smooth wires since this is a quality option. But the option is enabled by default.

I don't know if that would be helpful, but you may not even need an early depth test.
Since we are reading a copy of the depth texture, the depth test can be done on the fragment shader itself.
(I may have got it wrong).

In D7233#173229, @Germano Cavalcante (mano-wii) wrote:

I don't know if that would be helpful, but you may not even need an early depth test.
Since we are reading a copy of the depth texture, the depth test can be done on the fragment shader itself.
(I may have got it wrong).

You have it wrong. We still need the depth test to test against the other wires depth. Removing the depth test has the same impact on performance as using gl_FragDepth. All fragments will create shader invokation, sample the depth and result in overshading.