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.
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
Nodes: Add PixelationNode #28802
Nodes: Add PixelationNode #28802
Changes from 7 commits
b1275d8
1da945a
67c89e0
dd03bf7
43cb319
5648328
57a011f
e0d49da
9269101
4db388a
036af7e
550f063
7788849
63dfe76
58cc81c
c16e316
03f1135
db46ead
09893e9
2ea62ee
cff1d4d
98e4c0e
99a9e23
8742026
e338644
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Do you mind creating the example with the exact same lighting conditions than the original version?
It's important to perform a 1:1 comparison so we can see possible deviations.
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 apply the same lighting parameters to the scene, but the original lighting can't be replicated due to the shadow artifacts present, as mentioned in #28642. In my testing, recreating the lighting conditions of almost any webgl example that uses standard Three.js lights and casts shadows onto other objects exhibits similar rendering issues when that same sample is ported over to the WebGPURenderer.
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.
Then ignore the shadow casting for now. However, the type of lights and their parametrization should match otherwise the scene's color tone is different which makes it impossible to review the PR.
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 just
normal: normalView
.In the shader, you can then directly use the sampled normal values and don't have to convert them anymore. The render target is of type half float so there is not need to convert to RGB8 and back.
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.
That certainly makes sense to me, although for some reason when testing, the output of directionToColor(normalView) matched the normal output of RenderPixelatedPass while normalView did not. That never seemed right to me though, so I'll go back and check.
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 reverted back to normalView, but the effect of normalEdgeStrength is noticeably different/weaker compared to using directionToColor(normalView). I'll add some images to show what I mean, but I believe in this instance, to replicate the effect properly, directionToColor( normalView ) is the correct way our normal pass needs to be configured.
WebGL Pixelation tNormal texel output:
WebGL Pixelation Output ( Max NormalEdgeStrength)
WebGPU Pixelation normalView texel output ( i.e the raw output of the scenePass's normal texture node when the normal render target is set to normalView ):
WebGPU Pixelation Output ( Max NormalEdgeStrength with normalView as scenePass normal output )
// Note the complete lack of any edge detection on the Icosahedron
WebGPU Pixelation directionToColor( normalView ) texel output
// Image is not pixelized since the resolution is adjusted as a post-step in this implementation
WebGPU Pixelation Output ( Max NormalEdgeStrength with directionToColor( normalView ) as scenePass normal output )
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.
These are roughly analagous to the same effects I noticed before, which is why I ultimately chose directionToColor( normalView ) over normalView, even if intuition would lead us to use normalView.