Unity 6 regressions for XR in HDRP are rejected with "won't fix" by QA

Hi, as title says:
We are really getting upset with Customer Support at this point. We reported several bugs related to Unity 6 XR with HDRP, some of them clear regressions vs. 2023.2.x, where these things worked fine. Now these bugs are being closed as “won’t fix” with generic or wrong reasoning, which will leave us and many others relying on XR / HDRP in their products in a really bad situation. We cannot upgrade to Unity 6 and are now sitting on a deprecated version of Unity with no support.
We are pro customers since 3 years, and if support stays like this, we will unfortunately be forced to switch engines, as it seems that high quality XR with HDRP does not seem to be really supported anymore, in contrast to what the documentation says.
Biggest issues we see in Unity 6 are DLSS breaking XR sometimes (regression), SSR not working correctly (regression), APV different on left vs right eye (probably regression, have not really noticed before).

4 Likes

I agree, VR+HDRP need more love in Unity 6

Thank you for bringing this up. I will follow up internally. Could you link some specific issues as an example? Thank you!

sure,
for DLSS: IN-85345; reasoning here was that DLSS does not support VR. We use DLSS with VR in HDRP since two years in production already, so this is wrong information, and in Unity 6 DLSS works with VR, it’s just if you activate the headset screen turns black (until you disable and enable DLSS again), which obviously is not an incompatibility between VR and DLSS, but a Unity issue. It also works if you have your headset activated (on head), and start Unity.

for SSR: IN-85348
here it was stated that raytracing with XR is not a priority; I mentioned that issue is already present in SSR without ray tracing, no reaction to this.

for APV: IN-85628 this is not closed yet, but I have the bad feeling that this will happen soon…

1 Like

So my third bug report about APV mismatch between left and right eye was also rejected, with wrong reasons again. This is getting ridiculous.

What to do? I even found more bugs with mismatch between left and right eye which I have not reported yet (SSAO non raytraced and SSGI raytraced and non raytraced). If everything gets rejected, I see no purpose in reporting anymore.

We are dependent on XR on HDRP and really want to continue using Unity (Pro) as our engine for our current and coming products.

Firstly I have to say that overall, I’ve had mostly good experiences with reporting bugs and them eventually getting fixed.

But I have seen in the past that critical details / conditions in how I originally reported the bug, is changed or ignored in the final public bug ticket. This can cause confusion for the dev who is supposed to analyse the bug. Basically I’m saying that there appears to be too many steps and processing between how the unity user is reporting the bug, vs. what ends up in front of a developer (or not).

I wish that a bug had more active discussion, like the moment a dev looks at a bug report to analyse it and it appears as if the bug might be Won’t Fix, first reach out to the original unity user that reported the bug, to spend just a few minutes double checking the details.

1 Like

I had good experience, too, but this drastically changed the last few months… From QA not able to build a project, to now this mess, which is I guess more like product mgmt rather than QA. I understand priorities, but you cannot forget about existing customers, even if they might not be the main focus (which seems to be mobile and multiplayer).

But let’s stay on the topic here, which is XR in HDRP is in a bad situation in Unity 6 with lots of regressions.

2 Likes

@oliverschnabel any update on this? It’s really important for us that XR on HDRP at least continues to work as in version 2023.2.x and that all regressions are being fixed.

So the APV ticket has been opened again after I explained repeatedly that I am not reporting APV artifacts, but a mismatch between left and right eye (unfortunately the title of my report was changed to a misleading name by QA).

On the DLSS one QA said that it will be “discussed internally” whether dynamic resolution should be supported on XR. This is not the point. It already works. There is just a bad regression that screen turns black if you activate XR during runtime if DLSS is switched on. If XR is activated on start, it works. If DLSS is turned off and on again, it works. There is just one bug, which is a clear regression. Not sure why QA does not understand this.

So please, please, even if HDRP will “vanish” in Unity 7, please fix regressions and bugs in Unity 6.

@oliverschnabel any update on this? We need to make decisions for the future, so we need at least some info. Will Unity continue to support XR on HDRP, or do we need to look for alternatives (which clearly is not URP for our use case, and we know several other studios which are in same situation)?

VR with Unity6 hdrp is not worth the trouble.
First off it doesn’t work well, if at all?
Secondly the effort and pain are not worth the gain. Resolution and detail wise, there are very few to none VR goggles could take any advantage of the so-called “benefits” of this latest hdrp or whatever they now call it?
Don’t bother with it. It will only slow you right down and cause nothing but despair and rage!!!
Stick with what you know that works.

We are using XR with HDRP since 4 years and build a successful and highly profitable company around it, so do others we know, and we are paying lots of money to Unity. That’s the reason why we need answers here about the future. Only alternative is UE.
What is your level of experience with it so you can say it’s not worth it?

Easy answer: Reading the posts. And doing much work with demos/adds and using the damn thing.; What’s yours? Just moaning about it and waiting? Be polite and don’t fret so much. :slight_smile: Other render engines will suffice for VR…
Give your customers a look at the outcomes of all Unity renderers. You’ll be surprised at the results.

We are selling an URP version for standalone XR next to our HDRP for higher PCVR, so I guess we know what’s possible with each rendering pipeline well enough. We even did bring some stuff to URP which plainly does not exist, like screen space SSS. There’s still a huge gap in rendering fidelity, and the customers of our PCVR version would be very unhappy about degradation in graphical fidelity because of missing features like

  • better shadows
  • Better lighting in general
  • Better SSS (HDRP SSS still better than our version for URP)
  • complex shaders like stacklit and layered lit, special shader for hair, eye, skin
  • SSR
  • specular occlusion
  • SSGI
  • realistic looking water
  • Physically based sky
    Just to name a few.
    So there’s no alternative for us on Unity platform, besides heavily modding URP, which is out of scope. I’d rather give up on it and go with Unreal for next project before doing so. This is a serious business decision for us

Build a workaround for the DLSS bug (which clearly shows that this is a nasty and probably easy to fix Unity bug and not some incompatibility of current DLSS version with VR as QA is stating):

using System.Collections;
using UnityEngine;
using UnityEngine.Rendering.HighDefinition;
using UnityEngine.XR;

public class DLSSHack : MonoBehaviour
{

    HDAdditionalCameraData hDCamera;
    bool hackApplied = false;
    void Start()
    {
        hDCamera = GetComponent<HDAdditionalCameraData>();
    }

    // Update is called once per frame
    void Update()
    {
        if (XRSettings.stereoRenderingMode == XRSettings.StereoRenderingMode.SinglePassInstanced && hackApplied == false)
        {
            hackApplied = true;
            Debug.Log("Applying bad hack for nasty Unity bug.");
            StartCoroutine(HackCoRoutine());
        }
    }

    IEnumerator HackCoRoutine()
    {
        hDCamera.allowDeepLearningSuperSampling = false;
        yield return new WaitForEndOfFrame();
        hDCamera.allowDeepLearningSuperSampling = true;
    }
}

Can probably be done in a nicer way with OpenXR events, but I still have hope that this thing will get fixed…

1 Like

Not related to XR in my case, but I’ve just checked my upscaling management code and I’m actively delaying the upscale factor by 1 frame at the start (keeping it at 1.0), because if I recall correctly, I had all sorts of issues when jumping into play mode with active upscaling.

1 Like

Upscaling in general is very buggy and leading to all sorts of issues, especially in 2022.x versions of Unity. Became a bit better in 2023.2.x, but there are still unresolved bugs, even outside of XR.
In Unity 6 is mostly works good, probably because they integrated STP, only bug encountered so far is the XR bug. And STP seems to not look that good in HDRP, but the dev of STP left or was let go before he finished his work…

But still here with Unity? Great to see Pro-Customers still going for it! Must be nice to have that sort of dough :slight_smile:
Bugs that won’t be fixed, things closed. VR useless…
How long does one wait before the “threat” of switching engines achieves something or do we just continue to moan and wait?
For what it’s worth I still believe that for Gamers, the other rendering methods can achieve great results and “in the game” the differences would be so slight.
But all the very best in your quest. Hate to be in that position. Best of luck…you’ll need it.

It takes time to switch engine if you have build a complete product already, so now that Unity unofficially seems to drop support for XR on HDRP we have the following options:

  • fix it ourselves (should be relatively easy, but is no long term solution)
  • switch to Unreal engine (lots of work apparently)
  • switch to URP and build all the stuff by ourselves which URP currently does not have (lots of work apparently, not sure if stuff like high quality shadows are even possible without modifying URP itself)

We are actually tending to second option, as the way Unity is acting right now does not make me confident for the future; if all resources are put on Unity 7, which by my estimate probably will be production ready in like 3-4 years earliest, and is not able to support existing customers of Unity 6, there won’t be many paying customers left in 1-2 years, which will result in further reducing of dev teams, hence even later release of Unity 7.

We have found the issue causing IN-85628 a fix is en route.

1 Like