Can ALVR ask to render and encode a larger area of FoV?

[fcxfcx]

I have been studying on this project for a while. And I am wondering if ALVR can ask steam VR and the Encoder to render and encode a larger area of the scene (larger than the usual FoV size). I am thinking about this because this can somehow avoid black edge area because when moving the headset, the client can see the area around the FoV area even if the new scene has not been transmitted. This may be helpful especially when the network latency is high and head movement is quick.

I find that the "width" and "height" parameter in ALVR refers to the resolution instead of the size of video. In my understanding, implementation fo this solution may be related with change in both the driver, the encoder/decoder and the OpenGL part. As a beginner in programming I am wondering if this solution can be implemented in ALVR and how. Any advice or idea is appreciated! ：)

[zmerp]

This is actually not hard to implement, just low on priority for now. I'll mark this as a enhancement.

[fcxfcx]

This is actually not hard to implement, just low on priority for now. I'll mark this as a enhancement.

Thanks for reply! I know this may be a small case for experienced developers. As I am still learning about D3D11 and Open VR, I would be even more grateful if you could provide some guidance on the details. Anyway looking forward to the new update of ALVR!

[phobos2077]

I have the exact opposite request. In normal SteamVR, FOV slider introduces black boxes to the sides (thus, actually reducing FOV) at the benefit of much higher performance. With ALVR this doesn't work. instead the actual in-game FOV is reduced, resulting in broken VR immersion (not sure what is the technical term for this). I'd really like to try to use ALVR instead of Oculus service, but this along with lack of FPS settings lower than 60Hz, is the limiting factor.

[Meister1593]

I have the exact opposite request. In normal SteamVR, FOV slider introduces black boxes to the sides (thus, actually reducing FOV) at the benefit of much higher performance. With ALVR this doesn't work. instead the actual in-game FOV is reduced, resulting in broken VR immersion (not sure what is the technical term for this). I'd really like to try to use ALVR instead of Oculus service, but this along with lack of FPS settings lower than 60Hz, is the limiting factor.

Just a note about 60 hz, panels can't work at lower than this physically, so having less than that is basically pointless.

[zmerp]

Just a note about 60 hz, panels can't work at lower than this physically, so having less than that is basically pointless

True, but this is a use-case I plan to support with an upcoming dynamic framerate feature (use a combination of true refresh rates and framerate downsampling to achieve a wider range of framerates, which can by dynamically selected on performance stats).

[phobos2077]

Just a note about 60 hz, panels can't work at lower than this physically, so having less than that is basically pointless.

It's not. Most simmers can't reach stable 60 FPS and instead play at half that with or without Asynchronous Space Warp. That's the best setup I use - force 1/2 FPS relative to VR refresh rate with ASW disabled.

But what about supporting something similar to "FOV tangent multiplier" in Oculus? For me it makes a huge difference in performance (about 30% of pixels that I can't see anyway due to lenses/face position).

[phobos2077]

For context: I have Quest 2 and was using it mainly as PCVR via Oculus Link for a few years. I did experiment a lot with various settings in Oculus Debug Tool/CLI. Recently got into VR flight simming and realized how demanding it is. For my hardware (RTX 2070Super + Ryzen 5600X) achieving FPS anywhere near minimum refresh rate of 72Hz is out of the question. Even so for people with top hardware, without some drastic compromises:

• Obvious one is FPS reduction. On Oculus there is a setting that forces target FPS to 1/2 of selected refresh rate, so it's 36, 40 or 45 FPS. This way you get a bit of the blurriness on fast movements, but for non-combat flight simming this is completely acceptable, so long as the framerate is consistent (you can keep it most of the time). ASW even helps to smooth some movements out, but not reliably.
• Second one is FOV reduction. "FOV Tangent multiplier" is the setting in ODT. It basically reduces what's rendered to a square in your FOV. But because of how your face and lenses set up, you can reduce some rendered FOV without actual visible FOV reduction. This can give 10-15% less pixels to draw, at minimum. I get as low as 67%, so that's much higher possible FPS and very much required for flight simming. Also note that "native" SteamVR FOV slider achieves the same goal (works a little different, and no separate sliders for horizontal/vertical), it definitely works in HL: Alyx using Oculus + SteamVR stack.

So with all that, I was curious to try ALVR in the latest version. It has some benefits to Oculus:

• 60Hz option
• Detailed encoding settings
• Relatively lower VRAM usage when using SteamVR

I thought maybe I could squeeze some better quality/performance with that compared to native Oculus Link. But two vital options mentioned above seem to be missing.

I'm sure other simmers will be interested in ALVR as an alternative to Oculus, as the latter feels like abandonware at this point. I kinda didn't like how ALVR is married to SteamVR now (wasted VRAM, constantly launching steam is annoying), but on the other hand there are benefits to SteamVR like using fpsvr and other plugins. And some games don't support OpenXR, only SteamVR, so for them there's no loss in using ALVR.