-
Notifications
You must be signed in to change notification settings - Fork 839
[XR][URP] Fix issue with vignette location in XR #5471
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
Changes from all commits
a31f3bc
118a617
263cb31
348e23b
9364b7d
323a155
3b89c75
890ee1f
3c100ed
875610e
958d05c
85c3375
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -46,6 +46,9 @@ Shader "Hidden/Universal Render Pipeline/UberPost" | |
float _Chroma_Params; | ||
half4 _Vignette_Params1; | ||
float4 _Vignette_Params2; | ||
#ifdef USING_STEREO_MATRICES | ||
float4 _Vignette_ParamsXR; | ||
#endif | ||
float2 _Grain_Params; | ||
float4 _Grain_TilingParams; | ||
float4 _Bloom_Texture_TexelSize; | ||
|
@@ -68,7 +71,12 @@ Shader "Hidden/Universal Render Pipeline/UberPost" | |
#define LensDirtIntensity _LensDirt_Intensity.x | ||
|
||
#define VignetteColor _Vignette_Params1.xyz | ||
#ifdef USING_STEREO_MATRICES | ||
#define VignetteCenterEye0 _Vignette_ParamsXR.xy | ||
#define VignetteCenterEye1 _Vignette_ParamsXR.zw | ||
#else | ||
#define VignetteCenter _Vignette_Params2.xy | ||
#endif | ||
#define VignetteIntensity _Vignette_Params2.z | ||
#define VignetteSmoothness _Vignette_Params2.w | ||
#define VignetteRoundness _Vignette_Params1.w | ||
|
@@ -191,6 +199,12 @@ Shader "Hidden/Universal Render Pipeline/UberPost" | |
UNITY_BRANCH | ||
if (VignetteIntensity > 0) | ||
{ | ||
#ifdef USING_STEREO_MATRICES | ||
// With XR, the views can use asymmetric FOV which will have the center of each | ||
// view be at a different location. | ||
const float2 VignetteCenter = unity_StereoEyeIndex == 0 ? VignetteCenterEye0 : VignetteCenterEye1; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In general, we'd like to be able to support more than 2 views. Can we evaluate moving this code to an array with indexing instead ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since this use case is very specific to eyes, I don't know if we would even need that for "more than two" displays. Also, for more than 2 display scenarios, like domes, super panoramic views or stuff like that we would need to change the whole vignette post-process to have a center in world space to be able to sync all views to work together, a screen-space effect might not work well in that case without being fully custom. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Update: I had a chat with Fabien and I will implement "more than 2 views" for XR as there is some use-cases for it with some specific headsets There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Update 2 : Returning to 2 views to keep the code simple and we'll add more when we need to. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One of our partners is moving away from asymmetric frustums. We should keep this fix as simple as possible. What about extracting the center from the current stereo projection matrix in either vertex or pixel shader directly? Then there's no need to pass in per eye centers or changing script code. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't expect this change to prevent symmetric FOV from being used, it will only allow asymmetric FOV to work correctly. This change will work with both symmetric and asymmetric FOV, the center calculated for symmetric FOV will be (0.5, 0.5) for both eyes since in that case leftFov == rightFov && topFov == bottomFov. Extracting the data from the shader (Vertex or Fragment) will make this change more complicated than it currently is since this is a post process and uses a generic Vertex Shader which does not have information about the projection. Changing that will introduce code duplication and as a side effect, more possible point of failures. I believe that the eye center should be calculated on the CPU since it is something that will likely be used by other post process or shaders that rely on knowing where the center of the view is (any type of radial post-process, some screen space effects or more), it is also something that I expect some games will want to know too (I used these values for a few things in StarWars Squadrons VR). In fact, I was very surprised that the XR view center coordinates was not already available in our XR C# code ! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, the points sound reasonable. |
||
#endif | ||
|
||
color = ApplyVignette(color, uvDistorted, VignetteCenter, VignetteIntensity, VignetteRoundness, VignetteSmoothness, VignetteColor); | ||
} | ||
|
||
|
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.
Quick note : this will create a merge conflict with #3557
Not a huge deal but let's discuss the order of PRs.