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.

Sign up for GitHub

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

Jump to bottom

Severe Z-fighting on geometry that is "too close" #24

Open
w23 opened this issue Oct 20, 2017 · 2 comments
Open

Severe Z-fighting on geometry that is "too close" #24

w23 opened this issue Oct 20, 2017 · 2 comments
Assignees
@w23
Labels
bug
Milestone
Half-Life 2

Comments

@w23
Copy link
Owner

w23 commented Oct 20, 2017

I don't mean coplanar surfaces from different maps.
Should either tweak z-buffer params, or completely change z buffer approach to something less naive and more contemporary.
@w23 w23 added the bug label Oct 20, 2017
@w23 w23 added this to the 0.2: reimplementaion in bare C on top of atto milestone Oct 20, 2017
@w23 w23 self-assigned this Oct 20, 2017
@w23 w23 modified the milestones: 0.2: reimplementaion in bare C on top of atto, Half-Life 2 Nov 1, 2017
@w23
Copy link
Owner Author

w23 commented Dec 21, 2017

Reversed-z would be ideal. However, OpenGL is crap (for its -1 to 1 mapping which destroys precision for no good reason), and OpenGL < 4.5 (which also implies ES) is double crap, because it doesn't have a way around that (glClipControl is either ext or gl 4.5).

So, according to this: https://developer.nvidia.com/content/depth-precision-visualized my best option seems to be to try separating projection matrix from model-view.

@w23
Copy link
Owner Author

w23 commented Dec 21, 2017

Separating projection matrix from model-view matrix doesn't lead to image improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@w23 w23

Labels
bug
Projects
None yet
Milestone
Half-Life 2
Development

No branches or pull requests
1 participant
@w23