-
-
Notifications
You must be signed in to change notification settings - Fork 35.5k
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
WebGPURenderer: Fixed shadows not rendering correctly with logarithmicDepthBuffer
#29447
Merged
sunag
merged 6 commits into
mrdoob:dev
from
PoseidonEnergy:bugfix/logarithmic-depth-shadow-fix
Sep 28, 2024
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
4ca3e3c
Fixed shadows not rendering correctly when logarithmicDepthBuffer = t…
PoseidonEnergy c3a5cb6
Further improvements to the logarithmic depth buffer shadows bugfix:
PoseidonEnergy 6a2d716
Further improvements to the logarithmic depth buffer shadows bugfix:
PoseidonEnergy 779d372
Further improvements to the logarithmic depth buffer shadows bugfix:
PoseidonEnergy fb3e23d
Merge branch 'dev' into pr/29447
sunag 8b09308
cleanup
sunag File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
In post processing we have to compute the view position of a fragment in various effects. We do that with
getViewPosition()
:three.js/src/nodes/utils/PostProcessingUtils.js
Line 15 in 9e5528d
This method does currently not work if a logarithmic depth buffer is used. How would the reverse operation of
perspectiveDepthToLogarithmicDepth()
look like that computes a "normal" depth value based on the logarithmic depth?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.
Update 2024-11-13 | This post and info on the logarithmic depth buffer calculation is outdated. Please see the new revisions to the logarithmic depth functions in the pull request here: #29870
####################################################################
####################################################################
####################################################################
@Mugen87 Computing the perspective
w
value from a logarithmic depth value using the new formula would look like this. Note that this gives you thew
value, as inmodelViewProjection.w
. To getviewZ
, just dividez
byw
(I know you know that already but I'm just saying it for posterity).The TSL node function based on the math shown above would look like this. Like mentioned before, this returns the perspective
w
value, and notviewZ
. To getviewZ
, just doz / w
:NOTE: I have not tested the above node function above...it looks correct though...needs another set of eyes.
As an aside, should the functions
perspectiveDepthToLogarithmicDepth()
andlogarithmicDepthToPerspectiveDepth()
be renamed toperspectiveWToLogarithmicDepth()
andlogarithmicDepthToPerspectiveW()
to make it more clear that thew
component is being used?Desmos graph: https://www.desmos.com/calculator/1e3ttyfe6q
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've tried to replace the
sampleDepth()
function inGTAONode
for quick testing but it does not work yet. Here is the code:Do you see an obvious issue with the above code?
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 can say the following at the moment:
depth
inconst depth = this.depthNode.uv( uv ).x;
should range between 0 and 1 before being passed tologarithmicDepthToPerspectiveDepth( depth, this.cameraNear, this.cameraFar )
this.cameraNear
andthis.cameraFar
should be uniform nodesIn the meantime I will continue verifying that the
logarithmicDepthToPerspectiveDepth
function is correct.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.
Both requirements were true when during my tests. I'll revisit the code tomorrow.
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.
Yes, I think otherwise the names are confusing. Let's use
perspectiveWToLogarithmicDepth()
.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 can't get it to work with the proposed formula. I've also tried a slightly different formula but with no success.
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.
Update 2024-11-13 | This post and info on the logarithmic depth buffer calculation is outdated. Please see the new revisions to the logarithmic depth functions in the pull request here: #29870
####################################################################
####################################################################
####################################################################
Perhaps your
mvp.z
equals (or is very close to)mvp.w
? You may be returning1
after dividingz
byw
.Here is a fiddle where
mvp.z
is extremely close tomvp.w
(even at a camera distance of 9,000): https://jsfiddle.net/h7sd13pjIf that is the case, then try returning just the inverse:
return float( 1 ).div( logarithmicDepthToPerspectiveDepth( depth, this.cameraNear, this.cameraFar ) );
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.
Can you tell me how I can use
GTAONode
on my own to help you work on this? Maybe some little example or screenshot of what works whenlogarithmicDepthBuffer
isfalse
compared to when it istrue
?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.
There is an example for demonstrating the AO: https://threejs.org/examples/webgpu_postprocessing_ao
I suggest you test this locally by turning on logarithmic depth buffer in the demo. You will see the AO breaks.
For testing I have added
logarithmicDepthToPerspectiveW()
toViewportDepthNode
and then tried to use it inGTAONode
(with no success so far).