Search Issue Tracker
Found in [Package]
[Shadergraph] ScreenPosition node does not work when XR is active
1. Open the attached project ("1358229R.zip")
2. Open the "PortalVR" scene
3. Open the XR Plug-in Management settings (Edit -> Project Settings)
4. Disable Initialize XR on Startup and enter Play mode
5. Observe the Image in the Game Window
6. Enable Initialize XR on Startup and enter Play mode
Expected result: The portal looks similar/identical as with without VR
Actual result: The portal view is corrupted (see "Zovp0CSc9q.mp4" video)
Reproducible with: Shader Graph 7.7.1, 10.6.0, 11.0.0, 12.0.0 (2019.4.29f1, 2020.3.16f1, 2021.1.18f1, 2021.2.0b9)
Not reproducible with: 2022.1.0a5 (firstname.lastname@example.org namespace errors)
Nov 24, 2021 13:16
Also following the status of this. Did not expect shader functionality to be the issue when implementing VR portals.
Nov 15, 2021 10:50
It's been 3 months since you acknowledged this issue now. However and despite of the number of votes there isn't any news about any advancement regarding this problem.
May we be updated soon ? This bug prevent me to implement a critical feature for my game and is delaying it.
Thank you !
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
- Input Field ignores first keyboard input when calling Focus() from code
- GC Alloc when using Graphics.RenderMeshInstanced
- [VFX Graph][URP] VFX crashes on URP when dragging VFX asset to the Hierarchy window
- InvalidOperationException when using AsyncGPUReadback.RequestIntoNativeArray
- Generated Entities look different when Depth Priming Mode is changed
"The ShaderGraph they are using is set up assuming their "alternate world" camera has the same aspect ratio and FOV as the main rendering camera, which is the requirement to be able to just do a "blit" between the cameras for the portal effect.
However, when XR is enabled in their project, the alternate world camera does not render as an XR camera; it is still rendering at the original non-XR resolution and aspect ratio (and not multi eye I believe). So the blit ShaderGraph ends up stretching the result inappropriately.
What they are trying to do is definitely going to require much more manual intervention on their part to handle the multiple eyes and the resolution differences. The blit approach could still work as long as their alternate world camera uses the exact same layout (i.e. XR split eye with same aspect ratio and FOV), but I think their shadergraph would have to take care to sample from the correct eye from the alternate world camera."
The XR Team is evaluating XR specific Shadergraph nodes as a future feature that should handle cases like this.