-
Notifications
You must be signed in to change notification settings - Fork 855
[ShaderGraph] [2022.1] [Ruby] Fix screen position behaviors #6040
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
Conversation
Hi! This comment will help you figure out which jobs to run before merging your PR. The suggestions are dynamic based on what files you have changed. HDRP URP Shader Graph VFX Depending on the scope of your PR, you may need to run more jobs than what has been suggested. Please speak to your lead or a Graphics SDET (#devs-graphics-automation) if you are unsure. |
… threshold for error
…and reduce screen position test sensitivity by half OSX GL tests fail even at 1/4 sensitivity.. seems to have unusually large error (but still small on the scale of things)
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
The main ShaderGraph PR job won't run the built-in pipeline tests. You'll need to kick those off manually (I think just the "foundation" one should do for this PR). |
I ran ShaderGraph nightly to make sure I got all of the reference images updated -- looks like it ran built-in foundation too? |
Ah, cool. That didn't used to trigger automagically. |
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.
Current PR looks good, but it seems like the vertex and tessellation templates also need updating
|
||
// Initialize Camera Render State | ||
ClearRenderingState(cmd); | ||
SetPerCameraShaderVariables(cmd, ref cameraData); |
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.
Changes to this file are from PR #6114 and will be backed out before this PR is merged.
It was merged locally to test the combined behavior, as we can simplify the logic in this PR using the fixed _ScreenParams behavior in 6114.
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.
Seems to look good on VFX side. Checked Screen Position behavior and compared VFX with regular primitives that have SG assigned. Tests included:
- Vertex Stack, Fragment Stack with various particle outputs (Output Mesh, Quad, etc)
- DX11 (HDRP and URP), DX12, Vulkan (URP only)
- New and old (URP only) SG integrations
- MockHMD (URP)
- SG Scene from our VFX QA FTP project, checked if everything remains in the same places (URP)
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.
Looks good to me from the VFX side.
Thanks for the update.
N.B.: I think it could appropriate to have some helper function in core to factorize these implementation.
com.unity.visualeffectgraph/Editor/ShaderGraph/VFXShaderGraphParticleOutput.cs
Show resolved
Hide resolved
com.unity.visualeffectgraph/Editor/ShaderGraph/VFXShaderGraphParticleOutput.cs
Show resolved
Hide resolved
$SurfaceDescriptionInputs.PixelPosition: output.PixelPosition = float2(input.positionCS.x, (_ProjectionParams.x < 0) ? (_ScreenParams.y - input.positionCS.y) : input.positionCS.y); | ||
#else | ||
$SurfaceDescriptionInputs.PixelPosition: output.PixelPosition = float2(input.positionCS.x, (_ProjectionParams.x > 0) ? (_ScreenParams.y - input.positionCS.y) : input.positionCS.y); | ||
#endif |
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.
Not related to VFX but following the remark from this discussion
Should the _ScreenParams.y reflect the actual render target after renderscale ?
Is it a change of behavior in that case ?
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.
Looked at yamato. Seems good coverage.
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 ran included PixelPosition graphs, dithered SGs and checked material samples on HDRP,
- Tested on DX11, DX12, Vulkan, PS4
- Tested all DRS upscale filters
- Thanks @remi-chapelain for checking DLSS
No issues or regressions seen. Looks good to me! 👍✔
…e (target PR was already merged) This reverts commit bc3cd3f.
Does this, by any chance, offer a fix for this Issue: My team has been trying to get HDRP VR Render Texture Portals to work in HDRP which both use the ScreenPosition Node. |
Purpose of this PR
Proper Fix for: https://fogbugz.unity3d.com/f/cases/1369450/
MUST LAND AFTER (and remove changes from merged):
Original fix PR here (that just unblocked Universal Tests, but didn't properly fix the whole issue): #5867
This addresses a number of additional platforms and render pipelines, adds a standard for pixel position (origin in upper left), and also adds some tests.
This PR ensures that "Default" Screen Position and Pixel Position work identically across:
Specific changes:
Console Reference Image PR:
https://github.cds.internal.unity3d.com/unity/ScriptableRenderPipelinePrivate/pull/306
Testing status
Added automatic editor tests to verify that screen position and pixel position produce the expected result relative to raw clip position, in both the pixel and vertex shaders.
Manually tested that ScreenPosition and PixelPosition always have consistent origins in both vertex and fragment stages, and the sample depth and sample scene nodes operate as expected, and that the _ScreenParams return the correct value.
Note: The double UV flip introduced in this PR caused the dither node tests (in the Artistic Nodes scene) to change. But it is because those tests were extremely sensitive to screen position (output was heavily dependent on the least significant bits). I updated the Dither node test -- the new tests are more robust, and won't change results based on lowest bit discrepancies (or device/platform vagaries).
Yamato:
Nightly ShaderGraph: 🟢
https://yamato.cds.internal.unity3d.com/jobs/902-Graphics/tree/sg%252Ffix%252Fscreen-position2/.yamato%252Fall-shadergraph.yml%2523Nightly_ShaderGraph_trunk/9504802/job/pipeline
PR ShaderGraph (with latest test updates): 🟢
https://yamato.cds.internal.unity3d.com/jobs/902-Graphics/tree/sg%252Ffix%252Fscreen-position2/.yamato%252Fall-shadergraph.yml%2523PR_ShaderGraph_trunk/9576253/job/pipeline
PR HDRP: 🟢
https://yamato.cds.internal.unity3d.com/jobs/902-Graphics/tree/sg%252Ffix%252Fscreen-position2/.yamato%252Fall-hdrp.yml%2523PR_HDRP_trunk/9594824/job/pipeline
PR URP: 🟢
https://yamato.cds.internal.unity3d.com/jobs/902-Graphics/tree/sg%252Ffix%252Fscreen-position2/.yamato%252Fall-urp.yml%2523PR_URP_trunk/9598485/job/pipeline
Comments to reviewers
Notes for the reviewers you have assigned.