-
Notifications
You must be signed in to change notification settings - Fork 62
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
Allow disabling depth prepass with r_depthShaders #1412
Conversation
The benefit is performance, yes. Also, I think you can make it non-latch and instead do the check in |
Actually, there is. We have some shaders that use the current depth image: generic, global fog, motion blur, SSAO and dynamic light shaders (depthtile1/2 and lighttile). While global fog and SSAO would be rendered after all depth is written anyway, the other 5 won't. |
Also, it would break portals. |
Just tried this but it wasn't totally convenient since the depth mask bits of the main shader are modified depending on whether there is a depth shader. I'd have to make a backup copy of the depth bits.
Hmm yeah the light tile is a deal breaker. I don't think any of the others are problems but lighting definitely is. I'll make this a cheat cvar for debugging then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I have realized that even dynamic lights can be made to work, if we disable the last two planes in the lighttile frustum bounds check. But I will do this later. |
This cvar can be used to demonstrate that #119 is caused by a faulty depth shader. Or to quantify the performance benefits of depth shaders.
AFAIK disabling them shouldn't affect the final result of rendering, so it does not need to be a cheat var. But I could be wrong. So in case the performance benefits turn out to be negative on some system, depth shaders could be turned off.