Yes as others have pointed out Pimax headsets do work with openXR and this has nothing to do with the issue raised in this entire thread.
The problem is that the frustum culling FOV calculation within MSFS does not appear to respect cantered displays and instead assumes a shortcut in the it’s internal coding that the projections are parallel when this just isn’t the case with an index or Pimax headset. Both Headsets can render a bigger area then transform the rendered view to be “Compatible with parallel projections” as a workaround for developers not supporting cantered displays but this adds a totally unnecessary 30% rendering overhead in pimaxs case and circa 10-15% for the index.
Asobo @OlieTsubasa443 please read and understand this request. It has nothing to do with OpenXR. There is a whole wealth of information on this all over the internet and various game engines (Unreal Engine is one such example) already fully support cantered display headsets by correctly using projection matracies and the data that is presented by them, whether that be via OpenXR, OpenVR or any other API.
This is a very short request to fix the frustum culling projecton calculation when in VR using any headset with none parallel displays. It is not an OpenXR dependancy; please do not confuse this request!!
Currently when using any VR HMD with none-parallel displays MSFS frustum culling is incorrect causing artifacting at the edges of the display, very likely due to the way the in game code reads and incorrectly processes the projection matracies provided by OpenXR without respecting the cantered panels. This seems like such an easy fix but without it all HMD’s with none parallel displays dont work properly unless using a compatibility mode workaround which uses circa 30% rendering performance overhead.
It is something which was brought up in a previous thread which has well over 70+ votes but which seemed to be misunderstood by the MSFS support team & as such I please request your development team read this again.
Please also take note the VR Development Update never showed that this issue was raised as it only ever noted 2-3 votes when in fact this post had over 70 and there are several other threads around the forum related to the same issue.
Thankyou very much for your time and for considering this,
Just give this a push up. Pimax 8K and Index user here. Please support canted displays with wide fov natively as well as improve the aggressive culling. This totally kills the otherwise fantastic experience in this sim. Nothing to do with OpenXR or SteamVR. Thank you.
Dear,
Asobo and Microsoft please look into this VR FOV issue.
The new VR integration into MSFS is just incredible. VR really brings this already fantastic flightsim experience into a completely new world of realism, but for the wide FOV headset owners this bug is killing us.
Please look into resolving this issue for us VR flight simmers
Many thanks
@legia92
I believe this is a more general VR problem solely due to FS2020.
In effect, with the last few SteamVR version you can limit the FOV and when I reduce it to 50% in SteamVR with the Index, I can see FS2020 is over-culling the objects too early on the sides. In other words: with SteamVR FOV set to 50% trees (for example) are disappearing before reaching the edge of the view when turning the head around.
NB: In my opinion there is a logical possibility the game could be under-culling objects with any VR device with more than 90 deg FOV therefore. If this is the case, the game could actually be delivering lower performance in VR because it would be processing unnecessary objects.
NB: The inverse effect if happening with the selection of object LODs. In short, it displays highest details (lowest LOD) if the object is at 45 deg from center, and the next LOD (lowest details) if the object is at the center.
Well, it runs ok with my 8kx, but only with deactivated parallel projection. So there always is “cullum frustrating” visible in the sim. That is so sad, because it disturbs the immersion badly.
So please, it should not be too difficult, to support wide FOV. The MSFS is, where the 8kx can shine… right now very rough around the edges. So Asobo… this can be done without too much trouble. And never underestimate the number of VR users. The next generation of hedasets will bring bigger FOVs. So this is needed.
Frustum culling creates the issue where the left and right edges of the FOV are “flickering very badly”, I think it is a function of the geometry appearing and disappearing on the edges of the MSFS camera frustum for optimization purposes.
In order to fix it we have to enable the parallel projection inside the PiToll, that would be ok if it did not take a significant toll on the FPS.
Can MSFS fix this issue for VR HMD with large FOVs.
If you experience the same issue, can you please vote.
Thanks
I just got a response from a Zendesk ticket I opened concerning this exact issue I have with my 8KX.
What a disappointing and weak response I got from them.
Basically, not our problem cause Pimax does not support OpenXR (so false), take it up with Pimax not our responsibility
What a way to run away from supporting your customers.
You might want to reopen your Zendesk ticket because what I’m documenting above has nothing to do at all with Pimax.
I’m documenting FS2020 object culling algorithm is wrongly culling objects prior they reach the culling planes to the side when setting SteamVR to 50% FOV with an Index.
I’d suspect the same algorithm isn’t culling objects after they reach the culling planes to the side when using more than SeamVR 90% FOV with an Index, therefore leading to poorer performance processing necessary objects.
PS: Actually other similar problems manifest themselves much closer right in the cockpit. This might have nothing to do with frustum culling itself, but it might be related to more general LOD/culling problems:
TL;DR: object visibility depends also on the viewing angle, it might be visible at 45 deg to the side and disappear when viewed directly at, while being at the same relative distance to the eye in both cases.
My Zendesk ticket is about the Pimax and the frustum culling issue that forces the use of parallel projection.
They keep giving me the same answer every time I reply to their response to the ticket:
“Pimax does not support OpenXR natively therefore not our responsibility, talk to Pimax”.
I have talked to the proper people at Pimax about this issue, they have confirmed it is an issue MSFS has to fix on their side and has nothing to do with OpenXR.
I have found good threads on this forum that are reporting this issue for Pimax.
I’m out, I will patiently wait and hopefully they will resolve this issue someday.
Unfortunately Pimax just posted on their forums they reached out to Asobo and were informed they have no interest in a collaboration with them so it sounds like Asobo has absolutely zero intent in supporting wide fov headsets…
Pimax maintains its Asobo that needs to fix it and Asobo maintains that its Pimax that needs to fix it meanwhile were left with no solution and seemingly nothing being done by either side to remedy this.
@Huggies89
Pimax might have something to do on their end, it doesn’t change the fact FS2020 code is wrongly culling out objects and this shows with the Index for example.
Prior SU5, when using a FOV < 90deg, you could see Trees culled too soon at the outer edge of both eye.
Since SU5, when using a FOV < 90deg, you can see Trees culled too soon at the inner edge of both eyes!