Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix OIT depth test #15991

Merged
merged 1 commit into from
Oct 19, 2024
Merged

Fix OIT depth test #15991

merged 1 commit into from
Oct 19, 2024

Conversation

IceSentry
Copy link
Contributor

@IceSentry IceSentry commented Oct 18, 2024

Objective

  • The depth test was only using the final depth but it should be testing each fragments
  • Fully transparent fragments should not be added to the list

Solution

  • Test each fragment after sorting

Testing

before:
image

after:
image

@IceSentry IceSentry added C-Bug An unexpected or incorrect behavior A-Rendering Drawing game state to the screen labels Oct 18, 2024
@IceSentry IceSentry modified the milestones: 0.16, 0.15 Oct 18, 2024
Copy link
Contributor

@hexroll hexroll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
I also tested this with two scenes and it's working as expected \o/

@@ -5,6 +5,12 @@
#ifdef OIT_ENABLED
// Add the fragment to the oit buffer
fn oit_draw(position: vec4f, color: vec4f) {
// Don't add fully transparent fragments to the list
// because we don't want to have to sort them in the resolve pass
// TODO should this be comparing with < espilon ?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this could be something like:

const EPSILON: f32 = 4.88e-04;
if color.a < EPSILON { ... }

But tbh I'm not seeing that this is done when comparing color values anywhere in the codebase.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea behind that comment is more about having a cutoff for almost transparent pixels. Instead of fully transparent, the reason is that every fragment we add to the list costs us more memory. Right now it doesn't really matter because we have a fixed buffer size, but eventually I want to work on making it smaller.

Copy link
Contributor

@tychedelia tychedelia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, might be worth filing a ticket so that we don't lose track unless this is something you think you'll get to for work anyway.

@tychedelia tychedelia added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Oct 18, 2024
@IceSentry
Copy link
Contributor Author

All the various TODOs in the OIT code are very much for future me when I'll work on it. Some of the improvements I need for work but some are a bevy specific.

@cart cart added this pull request to the merge queue Oct 19, 2024
Merged via the queue into bevyengine:main with commit fcf6067 Oct 19, 2024
32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants