Hi, am I the only one having problems with CloudXR 4.0 final release?
First, it keeps hanging and crashing SteamVR 2.0.10. Even after I reboot I can’t get it to connect again, it just shows a black screen then dumps me out. I’ve been using CloudXR 3.2 for nearly two years and this is a major step down in stability. The experimental server is also unreliable. I managed to connect to it, once, but every other time I get errors connecting in the log, or just nothing.
Not only that, but there are still those wavey vertical lines on Quest 2 and 3, that are a show-stopper. If these major defects aren’t fixed, I think I will have to abandon using CloudXR entirely in lieu of a fully open source alternative transport layer, such as GStreamer.
Are these problems being looked at? So far, CloudXR 4.0 hasn’t been worth the wait, at all. To the contrary, it’s be nothing but problems for me so far. It also doesn’t help that the client is still running OVR and I had to downgrade my Android Studio to 2020 version to get it to compile.
I have a fully open source OpenXR-based CloudXR client ready to go and share with the community, but I can’t even get it to run with 4.0 properly. We need a reference implementation that actually works, is reliable, and looks good. In other words, Virtual Desktop is stomping over the image quality here. The only reason I was looking forward to CloudXR 4.0 was the ability to forward non-VR controller data to the PC, such as full body tracking and eye-tracking, but if the image quality sucks and it’s not reliable, why bother?
1 Like
Hello – we recently made available an image of 4.0 on AWS that has been tested and working. Because this is a “vanilla” system it may be worth using it to see if you’re experiencing similar problems. As for image quality, we’ll take a look and see if we can repro situations across various networks that may cause degradation to an unacceptable level. If you are comfortable sharing logs on the forum, please feel free to and we’ll take a look.
I’m on SteamVR 2.0.8 at the moment, have had no ‘hanging and crashing’. It’s not outside the realm of possibility that something in 2.0.9-2.0.10 has destabilized things somehow – though that seems unlikely.
The experimental server has been very reliable here. We did recently find one issue with certain platforms having more aggressive network timeouts. One thing you can try is to replace lucy.obj with a renamed copy of one of the two controller obj’s. Or grab any low-poly .obj, and rename it as lucy.obj. Then start the server, and see if the connecting is more reliable/stable.
As for wavey lines… I can’t say I’ve ever seen something I’d describe as that. Hard to say if it’s source content, content+encoder, content+foveation… etc. Do you see this all the time, regardless of steamvr app, or are there specific apps that show it but not all?
The ovrApi is still in use simply due to resources. We dropped the Wave sample as HTC has been making their own. Pico I believe has an OpenXR client. Plus the unity plugin addresses many customers’ needs. But if you have a full OpenXR client, and are having problems ‘migrating’ to 4.0, we’d certainly be happy to try to help you work through any issues. Can you describe what specific issues you are having running it with 4.0, just to scope/focus where the problems might be?
Regards,
-d
Hi Dave. I wrote the lion’s share of the C++ / client code for PlutoSphere, an OpenXR-based CloudXR app for PC VR streaming over the past two years.
I recently migrated from 3.2 to 4.0 and had a few issues with controllers being jumpy due to the timestamps being off (which I haven’t sorted yet, but this issue doesn’t happen in the OVR client you provided), so it would still be a useful thing to have an official Nvidia OpenXR sample client for CloudXR.
I understand you may not have the resources to allocate to this, but, for ex, for me to even compile the OVR client for Quest to be able to compare the visual quality from 3.2 to 4.0, I had to install a super old Android Studio (after uninstalling the latest). Then, after needing the latest Android Studio for other work, I had to invest time/energy to modify another sample from a third party, just to get the now-ancient / deprecated OVR client compiled and running.
This is all besides the point: the default 4.0 OVR quest client with the default code looks bad, with vavey vertical lines. It makes it not really viable on any Quests (I have Quest 1-2-3-Pro). Have you not seen this issue internally? The image quality is far inferior to both AirLink and Virtual Desktop. It’s really sad for me because I am really a big fan of CloudXR in principle, and want to use it for my path traced VR games to provide a cloud rendered solution, but if the image quality sucks I can’t and won’t use it for my own projects and will look elsewhere for a truly open source transport layer where I can at least diagnose what the server → client libs are sending / receiving in terms of frames to sort out any warping issues.
To repro the issue with the vertical wavey lines, just run any Quest on your OVR sample client and connect to SteamVR. I’ll share a video or picture if you can’t repro but I had many people report it. I would be very surprised if you hadn’t seen this.
1 Like