Stereoconvergence issue with CXR 3.2 and the Vive Focus 3

[sylvain.chague]

Hi there,

We have noticed issues with stereo convergence with CloudXR 3.2 on the Vive Focus 3.
We compared the following methods:

• 3.2 official CXR sample from Nvidia
• 3.2 official CXR sample from HTC - Release Wave CloudXR Sample Client v1.2 · ViveSoftware/Wave-CloudXR-Sample · GitHub
• 3.0 CXR sample from HTC - Release Wave CloudXR Sample Client v1.0 · ViveSoftware/Wave-CloudXR-Sample · GitHub
• Vive Business Streaming solution (HTC’s own streaming solution)

Unanimously for all the testers (n=5), the convergence was much harder with both 3.2 CXR samples than with Vive Business Streaming. It felt lime the 3.0 CXR version was more comfortable / easier to converge than the 3.2 version but still less comfortable / easier to converge than the Vive Business Streaming solution.

Is that something you’ve encountered as well? If so, any idea how to improve this?

Thanks,

Sylvain

[sylvain.chague]

In particular, this is very visible when adjusting physically the IPD on the Focus 3. HTC’s native IPD adjustment UI and the streamed content are not at the same convergence plane (i.e. the eyes must adapt to converge on one or the other).

[avartanian]

Convergence is hard as there is a vertical gap between the two images.

have a look here (unfortunately the name of the thread is not helpful)

Focus 3 - Version 3.1

Hello To summarize HTC-customized sample OK CloudXR 3.1 WaveVR SDK sample KO CloudXR 3.1 WaveVR SDK sample + sign check/flip OK However, best would be that you reproduce the issue on your side. Best regards, Alexis

There is a strange thing with the way WaveVR returns FOV information.
CloudXR sample from HTC has it right

An additional observation is that the issue varies with Focus 3 batches

Let me know if that resolves the issue. If so, we’ll ask Nvidia to add the fix to the next release sample.

Best regards,
Alexis

[sylvain.chague]

Thanks Alexis but our problem is different.

I believe we have found what the actual root cause is. We were using a single CloudXRClientDescriptor.txt to pre-configure all our CloudXR servers. In that file, there is a “proj” value which is device specific and which doesn’t seem to be updated when an actual HMD connects for the first time to the CloudXR server, i.e. only the “proj” values in the descriptor file are being used.

Our use case prevents us from having a 1 to 1 static mapping between HMDs and CXR servers so we unfortunately rely on the HMD specific “proj” values sent by the HMD to be actually used by the CloudXR server… which is unfortunately not working in CXR3.2