-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Add ability to display depth buffer in editor 3d preview. #67735
base: master
Are you sure you want to change the base?
Conversation
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.
Good idea! I think this will be nice addition and it makes sense seeing as how we already have a display mode for the normal buffer.
One thing I am unsure about is whether we actually need to invert the depth. I left some comments on implementation assuming we keep the inverted depth code, but to me it seems like it may make more sense for the debug mode to show users something closer to the actual value instead of inverting the range. Did you do it this way because non-inverted depth was too difficult to read?
depth = depth * 2.0 - 1.0; | ||
depth = 2.0 * params.camera_z_near * params.camera_z_far / (params.camera_z_far + params.camera_z_near - depth * (params.camera_z_far - params.camera_z_near)); | ||
|
||
depth = params.camera_z_near * params.camera_z_far / | ||
(params.camera_z_far + depth * (params.camera_z_near - params.camera_z_far)); |
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.
Could you explain in more detail what is wrong with this way of linearizing depth? This is the same method used throughout the engine, so if it changes here it should change there as well
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.
I think I was a bit quick in editing that shader, I've restored line 248 in a commit I'll be pushing.
In terms of line 247, if I have understood the maths correctly that sort of conversion should not be needed in Vulkan compared to OpenGL, is it correct that it is no longer needed?
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.
No, it is still needed. We aren't dealing with NDC values here, we are dealing with the contents of the depth buffer which are still values in the 0-1 range regardless of using Vulkan or OpenGL.
If you look at other parts of the codebase, they all use the same function to convert depth buffer depth into linear depth. I would stick with using the same code here as elsewhere so that everything matches.
@Joxno You need to run |
doc/classes/Viewport.xml
Outdated
@@ -436,54 +436,56 @@ | |||
</constant> | |||
<constant name="DEBUG_DRAW_NORMAL_BUFFER" value="5" enum="DebugDraw"> | |||
</constant> | |||
<constant name="DEBUG_DRAW_VOXEL_GI_ALBEDO" value="6" enum="DebugDraw"> | |||
<constant name="DEBUG_DRAW_DEPTH_BUFFER" value="6" enum="DebugDraw"> |
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.
This should be filled in
// Depth. | ||
bool inverse_depth; | ||
uint32_t pad3[3]; |
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.
This should replace one of the pads above (I would replace pad
) There is no reason to introduce 3 new pads when there is already so much padding
depth = depth * 2.0 - 1.0; | ||
depth = 2.0 * params.camera_z_near * params.camera_z_far / (params.camera_z_far + params.camera_z_near - depth * (params.camera_z_far - params.camera_z_near)); | ||
|
||
depth = params.camera_z_near * params.camera_z_far / | ||
(params.camera_z_far + depth * (params.camera_z_near - params.camera_z_far)); |
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.
No, it is still needed. We aren't dealing with NDC values here, we are dealing with the contents of the depth buffer which are still values in the 0-1 range regardless of using Vulkan or OpenGL.
If you look at other parts of the codebase, they all use the same function to convert depth buffer depth into linear depth. I would stick with using the same code here as elsewhere so that everything matches.
Discussed in the PR meeting today. Consensus was that this looks mostly good, but both non-inverse and inverse result in far away objects being difficult to see. Lawnjelly helpfully suggested (and the other contributors agreed) that we should use the non-inverted linear depth, but we should set the far plane to a fixed color so that far objects contrast well against it. I am thinking a dark blue colour from this page would be good https://davidmathlogic.com/colorblind/#%23D81B60-%231E88E5-%23FFC107-%23004D40. There are a few colours suggested here that have good visibility for many different types of colourblindness. |
@Joxno Could you look into applying clayjohn's suggestions above? The PR should be good to merge afterwards. If you don't have time, let us know and we'll mark this as |
…ersing depth values.
Changed mode to push constant instead after feedback. Changed method of separate copy function to boolean flag instead after feedback.
…alculations. Added background colour at max depth. Corrected and moved documentation.
Tested locally (rebased on top of simplescreenrecorder-2024-02-14_22.21.50.mp4Testing project: test_shadowmask.zip Notice how selecting Disable Mesh LOD shows directional shadow splits instead, for instance. |
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.
Tested locally, it works as expected in Forward+. I can't get this debug draw mode to show up when using the Mobile rendering method though, even though it should be able to work according to what I see in the diff.
It would be nice to get it working in Compatibility too, but this can be left for a future PR.
I noticed there's quite a lot of banding in the debug view:
Even with camera near set to 1.0
and far set to 25.0
in the editor view settings, I still get a fair amount of banding:
It appears the stepping is actually correct (there are no shades of gray "missed" between the bands), but since the depth is displayed in a non-linear manner, the banding in near-black shades gets pretty obvious. This may be less noticeable depending on viewing conditions or the display you're using (I'm using a LG C2 42" at 120 nits brightness in SDR).
PS: This PR will likely need changes if #88328 is merged before this one.
This pull request implements the ability to quickly display the depth buffer in editor 3d preview and fixes a bug in the copy.glsl shader related to how linear depth is calculated.