can not reproduce VR: HMD / HIADSS Symbology too high

[BIGNEWY]

I will ask QA members with the quest to check again. 

thanks

[Draken35]

10 minutes ago, actually_fred said:

Yeah, this sounds like DCS is incorrectly assuming a vertically symmetrical FOV and incorrectly drawing in the center of the image it submits to the headset, when it should be putting it in the center of the field of view.

It should be expected that this issue can not be reproduced with a Pimax Crystal, because Pimax Play reports vertically symmetrical FOV.

DCS is provided with the information it needs to do this correctly when it calls `XrLocateViews()`  -the `XrView` array members have a `fov` member, which in turn has separate `angleUp` and `angleDown` members.These are not required to be identical, but for a Pimax Crystal, they are, so you can't reproduce the bug on a Crystal.

Pimax Crystal: angleUp is 0.90541315 (radians), angleDown is -0.90541315 - ~ 52 degrees both directions
Quest Pro: 42 degrees angleUp, -53 degrees angleDown, so a crosshair that is put in the center of the render target without paying attention to the FOV angleUp/angleDown will be quite substantially off. 

These are the values that the runtime reports to DCS and that DCS should be using, not a personal subjective measurement.

You must use a real Quest headset to test this issue; the Meta XR Simulator always reports symmetrical FOV.

It is also likely that this ties into the reports about 'mirror window too high' - though that isn't a bug if it's accurately showing what's sent to the panel.

Awesome post! Thank you!

[actually_fred]

1 hour ago, BIGNEWY said:

I will ask QA members with the quest to check again. 

thanks

Thanks; another way to test this would be for your software engineers to intentionally modify the angleUp/angleDown values significantly and incorrectly, to make sure that that moves the HUD to the 'wrong' place, by the amount and direction matching the changes. Of course would need to be careful not to actually ship that change - just for testing

[bak3dp0t4to]

On 9/25/2025 at 8:27 AM, BIGNEWY said:

I will ask QA members with the quest to check again. 

thanks

And? Did they actually try it with a real headset this time? How can you have so many users telling you this is an issue and just repeatedly ignore them with a useless response of how "it works on your Pimax Crystal". You've said that so many times I hear it in my sleep. We get it. Good for you. It doesn't work for us.

Would you like to come to my house and put my headset on? I feel like this is the only way you're ever going to acknowledge it. 

 

On 9/25/2025 at 8:19 AM, actually_fred said:

Yeah, this sounds like DCS is incorrectly assuming a vertically symmetrical FOV and incorrectly drawing in the center of the image it submits to the headset, when it should be putting it in the center of the field of view.

It should be expected that this issue can not be reproduced with a Pimax Crystal, because Pimax Play reports vertically symmetrical FOV.

DCS is provided with the information it needs to do this correctly when it calls `XrLocateViews()`  -the `XrView` array members have a `fov` member, which in turn has separate `angleUp` and `angleDown` members.These are not required to be identical, but for a Pimax Crystal, they are, so you can't reproduce the bug on a Crystal.

Pimax Crystal: angleUp is 0.90541315 (radians), angleDown is -0.90541315 - ~ 52 degrees both directions
Quest Pro: 42 degrees angleUp, -53 degrees angleDown, so a crosshair that is put in the center of the render target without paying attention to the FOV angleUp/angleDown will be quite substantially off. 

These are the values that the runtime reports to DCS and that DCS should be using, not a personal subjective measurement.

You must use a real Quest headset to test this issue; the Meta XR Simulator always reports symmetrical FOV.

It is also likely that this ties into the reports about 'mirror window too high' - though that isn't a bug if it's accurately showing what's sent to the panel.

@actually_fred, seriously, thank you for spelling this out for them. It's unfortunate that they'll probably still just respond with how it works fine for them.

[MRTX]

I once again would like to remind everyone that this issue would go away over night if the IHADSS position would be made adjustable. 

Edited Friday at 11:51 PM by MRTX

[bak3dp0t4to]

On 10/17/2025 at 7:51 PM, MRTX said:

I once again would like to remind everyone that this issue would go away over night if the IHADSS position would be made adjustable. 

This is what I don't understand. Rather than just make it adjustable, for whatever reason it seems to be more important to argue that it doesn't happen on the Pimax Crystal. The only possible reason for that I can think of is someone is getting paid to promote Pimax Crystals. Feel free to correct me if I'm wrong though, I'd absolutely love to know.

[Phantom711]

@bak3dp0t4to

I would not interpret too much into it. 
I would also argue that „just making it adjustable“ is not that easy. You really only want some of the HMD symbology to be adjustable. All the symbols that need to by on top of the outside world objects (i.e. flight members, target designation boxes etc) should remain where they are now. And all of a sudden it‘s not „just“ a matter if sliding all HMD symbology up or down.

The problem seems to be very specific to the Quest3 and maybe even among all Q3 users specific to how one wears the Q3. 
 

EDIT: BTW I am using a Quest Pro and it has never occurred to me, that the HMD symbology would be too high. 

Edited 6 hours ago by Phantom711

[bak3dp0t4to]

4 hours ago, Phantom711 said:

@bak3dp0t4to

I would not interpret too much into it. 
I would also argue that „just making it adjustable“ is not that easy. You really only want some of the HMD symbology to be adjustable. All the symbols that need to by on top of the outside world objects (i.e. flight members, target designation boxes etc) should remain where they are now. And all of a sudden it‘s not „just“ a matter if sliding all HMD symbology up or down.

The problem seems to be very specific to the Quest3 and maybe even among all Q3 users specific to how one wears the Q3. 
 

EDIT: BTW I am using a Quest Pro and it has never occurred to me, that the HMD symbology would be too high. 

@Phantom711 If it made a difference I'd extend you the same offer I extended BigNewy; If it would prove to you that I and the dozens of other people in this thread are not full of dung, you can literally come to my house, put my headset on, and see it for yourself. Putting on a physical Quest 3 headset is the only way you are going to see this issue. 20 minutes of flying around in the Apache with your torque gauge at the very top edge of the headset screen and flying around everywhere staring through the slip indicator instead of the flight path vector and you'll be ready to pull your hair out. I'm literally getting neck pain after a 2 hour session from having to keep my chin buried in my chest and looking out the top of my eyes the whole time. 

In case you skipped over what @actually_fred wrote: 

"Yeah, this sounds like DCS is incorrectly assuming a vertically symmetrical FOV and incorrectly drawing in the center of the image it submits to the headset, when it should be putting it in the center of the field of view.

It should be expected that this issue can not be reproduced with a Pimax Crystal, because Pimax Play reports vertically symmetrical FOV.

DCS is provided with the information it needs to do this correctly when it calls `XrLocateViews()`  -the `XrView` array members have a `fov` member, which in turn has separate `angleUp` and `angleDown` members.These are not required to be identical, but for a Pimax Crystal, they are, so you can't reproduce the bug on a Crystal.

Pimax Crystal: angleUp is 0.90541315 (radians), angleDown is -0.90541315 - ~ 52 degrees both directions
Quest Pro: 42 degrees angleUp, -53 degrees angleDown, so a crosshair that is put in the center of the render target without paying attention to the FOV angleUp/angleDown will be quite substantially off. 

These are the values that the runtime reports to DCS and that DCS should be using, not a personal subjective measurement.

You must use a real Quest headset to test this issue; the Meta XR Simulator always reports symmetrical FOV.

It is also likely that this ties into the reports about 'mirror window too high' - though that isn't a bug if it's accurately showing what's sent to the panel."

As I explained to BN in a previous post, for it to line up properly I have to pull my headset so far down on my face that the forehead pad is literally sitting on my eyelids. The picture is completely blurry and I'm basically looking through the top 1/4 of the lens to see straight ahead. The alternative is to try to angle it downward/forward, but a: the headset doesn't angle that far, and b: if you slide the strap up high enough it's no longer contacting the back of your head and theres about a 1-inch gap between the top pad and your forehead. Would either one of you care to explain to me how that is a proper fitment? 

Also, surprise surprise, this is an issue with other games when played on the quest 3.

Check it out: 

https://www.reddit.com/r/oculus/comments/187e2uj/huds_too_high_on_quest_3/

https://www.reddit.com/r/OculusQuest/comments/177bac3/huds_appear_off_center_too_high_on_quest_3/

And just like with bignewy's pimax crystal, your quest pro is not a quest 3, which I can't believe I actually have to explain to the both of you is a different piece of equipment that works differently than your quest pro or his pimax crystal. I didn't have this problem on my CV1 either. But I DO have it on my Quest 3. 

What you two are basically saying is if you said your chevy has an engine knock I'd tell you you were wrong because my ford doesnt do that. Do you see how... (I cant really think of a nice way to say it)... that sounds now?