Something makes a very thick double image on the right side of my display where the border from the left side is cutting into the image on right. I know that’s normal, but it’s somehow not visible on the left, because the bias is in the other direction. I can’t find another explanation. It occurs to me I should try another app and see if it’s there too…
Update: It seems like it is. Another game app draws a big black frame only over the right side. I wonder what this could mean?
Edited: It’s not really visible in Microsoft’s Cliff House (screensaver) but to get a good view in my app I have to pause (stop sending xrWaitFrame) and turn my head. It’s most apparent with a black fixed foveated rendering mask, otherwise it’s just the very edge of the eye that can see the edge, since the corners get filled in. I can’t think anything to explain it. I tried swapping eyes to see if my app was somehow mapping the right eye asymmetrically.
Are you sure yours aren’t run through a tan function? For me tan(-0.785398245) is very close to 1, and -0.995 (yours) is very close to 1. Edited: 1 is 45 degrees. But maybe Index is just wider than mine… which is HP Reverb G2. It is troubling, I don’t know if it’s always been like this or not. The tracking seems to have developed a pulsing twitch too. I think I’ve gone through 3 PSVRs and I’m getting the impression VR sets don’t last very long before something or other breaks in them.
I may try Steam VR just for the hell of it, but even the set’s mechanical IPD slider doesn’t change the FOV from what I can see, so I’m thinking this value is either set in the firmware in the factory or is measured internally by a simple device… and I just can’t imagine that the runtime would generate the wrong values since as far as I know OpenXR has no variables that would effect the FOV.
It’s the views as they are returned from xrLocateViews(). The Index has about a 10 degrees larger FOV then the G2, so the magnitudes look about right.
The FOV should be independent from IPD since that should already be included in the view pose. As far as I know, the FOV value is static for the headset type. It sounds like it could be a configuration issue or bug with the WMR runtime. I suggest checking with hello_xr so that you can rule out it being an issue with your app.
Well if it’s actually runtime bug (seems unlikely) then the only fix is to try a different runtime. But it seems like hardware bug. I’m looking into replace it. Unfortunately my warranty just ran out, although I think it should’ve been honored by delivery date. I just wonder if it being so cockeyed is actually acceptable.
The FOV is likely read from an internal configuration value somewhere in the WMR software, so I’d suspect something on the software side more than hardware.
FOV does not need to be symmetrical, and since it goes through distortion and timewarp/reprojection, doesn’t even have to match the physical headset (usually it’s at least somewhat larger to give some overdraw for timewarp). Sometimes this means vendors are kind and give you a symmetric, possibly even square FOV. (There’s actually a tool to test your app in the WinMR OpenXR dev tool thing, that will constantly “jiggle” the FOV to make sure your app is actually correctly retrieving, using, and reporting FOV used - it should be imperceptible to the user if you’re doing your code right.)
In general I wouldn’t expect an IPD slider to affect FOV exposed to the app. It may change what part of the FOV displayed you can actually see, but the optics should make it so that there’s not really any change in the FOV displayed.
(There’s actually a tool to test your app in the WinMR OpenXR dev tool thing, that will constantly “jiggle” the FOV to make sure your app is actually correctly retrieving, using, and reporting FOV used - it should be imperceptible to the user if you’re doing your code right.)
I actually turned that on not very long ago. I wonder if there’s any chance it’s stuck. I know it seems so unlikely, but I never noticed this until recently. (Edited: To be clear, I turned it on, and turned it off. It was as you say, only the borders were affected.)
Do these values not seem strange to you? If the FOV doesn’t actually matter, do you think it’s not in the firmware as a fixed constant? Like calibrated at the factory? I’m going to try SteamVR today. I started installing Steam yesterday. It kind of left a bad taste in my mouth because it’s Captcha system totally malfunctioned and kept making me retake its tests until it was clear it wasn’t going to accept any answer as correct.
I imagine most headsets would still have left-right mirror symmetry between the views.
It’s cool that it’s not a requirement in OpenXR though. It might enable some things on the runtime side, such as predicting how much reprojection overdraw will be needed and dynamically adjust the FOV.
The Jiggle FOV option is not public, the one you’ve tried out is Jiggle Rotation and it does not affect the FOV at all. So that’s not the problem.
AFAICT its very common to not have symmetry left and right, I can tell you that all my WMR headsets advertise different values for L/R FOV. I’m also pretty sure I’ve seen asymmetric values with other vendors. It causes no visual issues for me.
Can you follow these instructions here and send me the resulting trace?
I can tell you where the issue is is on the edge of the frame, since the render-targets aren’t ideally centered, and the points where they overlap is not ideally positioned. This sounds like an interesting topic. I must admit I can’t understand why devices wouldn’t have symmetric parameters here outside small factory tolerances. Is every lens different, like because they’re manufactured on a sheet?
EDITED: I’ve bookmarked this troubleshooting link and will look into it ASAP (probably tomorrow.) Thanks!
I agree that your angleRight values, while I don’t expect them to be exactly the same, look a bit far apart. I hope the trace will show a lead or something.
Your app seems to handle correctly retrieving and submitting frames with the FOV from the runtime. I cannot speak for the correctness of your projection matrices computation (I can’t see that info).
On my Reverb G2, this is what I am getting for FOV values:
They’re also asymmetrical as you can see, but I see no visible issue when looking in the headset. I can’t explain why your values are so strangely asymmetrical, maybe your trace will help.
