Skip to content
This repository has been archived by the owner on Aug 28, 2020. It is now read-only.

Z fighting issues #8

Open
PiKeyAr opened this issue May 19, 2018 · 4 comments
Open

Z fighting issues #8

PiKeyAr opened this issue May 19, 2018 · 4 comments

Comments

@PiKeyAr
Copy link

PiKeyAr commented May 19, 2018

These happen only when OIT is on, 32-bit Z Buffer doesn't help

Pool in the Ice Cap cave in the Mystic Ruins (DC level only)
image
Water ripple (happens only with the SADX version of the ripple)
image
Hard to see but this thing in MR Past appears to have some kind of shadow that flickers when the screen moves. It shows up only with OIT when a 24-bit Z Buffer is used, but it also shows up without OIT when a 32-bit Z Buffer is used.
image
Sky Chase sky looks weird in motion (DC level only)
image
Character shadow at the bottom of Emerald Coast 2 pond
image

@michael-fadely
Copy link
Owner

michael-fadely commented May 19, 2018

The reason for this is the use of a less-equal comparison for transparent fragments. The only reason I do this is for HUD elements (for example, the pause menu). You can mess with the comparison here and the normalization here. Might be worth somehow special-casing the HUD, or perhaps using a different method of storing depth.

Currently transparent fragment depth is stored normalized (0 to 1). The reasons for this are:

  • We must manually check against the opaque depth buffer to reject fragments in the composite shader because SADX draws opaque and transparent geometry interchangeably, not in separate passes like you might expect.
  • Compact storage. We could easily store z and w* components of the depth, but that would increase the storage requirements by another 4 bytes, and this becomes quite significant at 32 layers per pixel, particularly when statically allocated like it is now. This could be alleviated by using an append buffer, however.

*z is the depth from the far plane to the near plane, effectively world-space; dividing by w normalizes it, making it screen-space

If I had full control over the entire pipeline, I could easily draw opaque first, transparent second, and then draw hud elements over the top after composition of the scene fragments. I could of course take control over the entire pipeline by force, but that will be very time consuming if not impractical (says the person who just shimmed D3D8 to D3D11 for OIT).

So it turns out to be a bit of a complex issue.

@PiKeyAr
Copy link
Author

PiKeyAr commented May 20, 2018

If you can test which texlist is being used, maybe it's possible to whitelist all HUD texlists and get rid of the less-equal check?

@PiKeyAr
Copy link
Author

PiKeyAr commented Jul 17, 2018

Sky Chase got worse with the latest update.
image
Looks fine without OIT though. It also looks fine with the SADX version of the level, so maybe it's some depth manipulation that I'm doing in the mod causing this.

@PiKeyAr
Copy link
Author

PiKeyAr commented Sep 3, 2019

Sky Chase works fine with the latest generic build (or maybe it's because I reworked it a while back, not sure), all other issues are still there. I fixed the Emerald Coast pool thing manually.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants