Hi, nearly all new HDRP features don’t render correctly in XR; I have tried
As HDRP officially is supposed to work with XR, and HDRP is also being used by active live XR projects, it would be very helpful and necessary if a XR setup would be part of the QA process.
I would also love to see better automated testing coverage for this.
Found another one: TAA Post Sharpen does not work with XR (reported as IN-35230).
Also I reported Water refraction and lens flare issues with IN-35147.
It’s not like I am searching for bugs, just simply trying out the latest beta with XR…
Yes, I have had exactly the same experience. Like I mentioned in Discord a while ago, I think XR support for these features gets added (and looking at the code, it all seems proper at first glance), but does not get properly tested and automated testing coverage is currently lacking in this area.
So right now we have the following list:
These features simply did not work correctly when enabled with default settings. I’m afraid there is even more if we dig into it.
The fact that these seem like they could (and should) have easily been caught before landing in the engine, combined with the current iteration times (2-3 months?), can cost a lot of unnecessary time and frustration.
@chap-unity is there anything that can be discussed internally on how HDRP could start improving in this area?
Thanks a lot.
“High Quality Line Rendering” in XR was accepted by QA, feel free to vote (this is needed e.g. for hair shader):
Water refraction and lens flare bug report has also been accepted by QA:
DLSS (IN-29324, RTX 30 series specific) has been fixed in 2023.2.0a6+
TAA Post Sharpen issue in XR also accepted:
And found another one, which seems a regression: SSGI does not work anymore in XR (the denoiser is doing weird stuff, not updating correctly with camera rotation). This worked in earlier LTS versions of 2021.3, but at least with 2021.3.18 it’s broken. Will do another bug report as soon as I find time.
Edit: Was my fault, I accidentally disabled motion vectors on camera.
@chap-unity Are there any info about if and when these issues will be fixed? So far I only see the issues in the issue tracker, but no activity; and only the High Quality Line Renderer one has an “under consideration” tag.
We are relying on XR / HDRP, and especially the broken High Quality Line Rendering and Water Refraction are highly important for the future of our product, and there are no alternatives (at least in the Unity universe).
Sadly, I don’t have more information than what is already public, it will get looked at but it’s just that there’s most probably other bugs in the list first 
Thanks for your patience !
Thanks for the info, and we’ll try to be patient for a while 
Just tried the fix for High Quality Lines in VR (Unity Issue Tracker - GameObject is rendered incorrectly when the “High Quality Line Rendering” is enabled). While in principal it works, the fix completely misses the point: It falls back to multi pass, which of course has severe impact on performance (see this commit comment: Internal/master by UnityAljosha · Pull Request #7926 · Unity-Technologies/Graphics · GitHub which basically says to do single instance rendering is too much work…)
It runs way too slow to be usable in VR, which was the whole point of the issue. It even runs slower compared to run everything in multi-pass.
That’s very disappointing.
While this was a beta, I also noticed that VR rendering in general has some regressions I’ll do a new bug report about.
I can provide something of an update on the above issues @Qleenie
With regards to several of the outstanding issues mentioned above, I have been testing and investigating - these are not fixed but should be soonish. I am going to push to see the dev status on these and see if I can get a more definitive timeframe.
Secondly, I spoke with the feature dev on HQ lines in VR last night. HQ lines is a software rasterizer written entirely in compute, concepts like GPU instancing in a sw rasterizer simply dont exist without a lot of work to emulate the instancing concept in the compute kernels that compose HQ lines. We are also fairly doubtful that emulating single-pass in sw will be all that much faster than multi-pass. This is feature-sized work, the stop-gap solution until we address this problem more robustly is of course going to be the much simpler multi-pass approach.
The feature dev recently got a Quest 2 and plans to take a deep dive on hair VR perf - again, I will keep this on my radar and monitor the progress here
Hope this helps
@chap-unity @CarlHarr
Seems that there was not much progress on establishing VR as part of some really basic brief test before a feature ships;