Support for Wide FOV VR headsets (removing Frustum Culling issue)-

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.


I really want Asobo to fix the terrible object culling.


Pimax 8kx owner here. Havent even tried the headset with MSFS yet. Voted. Hopefully they can properly support openvr wide FOV headsets some time soon.

1 Like

Hi. Also a vote from my side. Pimax 8K user

1 Like

Hi Asobo,

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.

All information is available on the previous thread here, please take time to read this, particularly towards the end of the thread: Support for Wide FOV VR headsets (removing Frustum Culling issue)-

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.

1 Like

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


Pimax please fix this… 8KX user…

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.

Here are more details about this (with screenshots):
LOD Problems - Distances revisited - #38 by CptLucky8

I don’t know whether this has anything to do with the many other LOD problems, but it seems these are still prevalent and still not fixed.

For what it’s worth, here is a compilation of topics I’ve already posted:

[08OCT2020] Trees draw distance is different per-species AND per-Trees LOD setting
[16OCT2020] Some trees are disappearing then reappearing
[25OCT2020] LOD Problems - Distances revisited

In Zendek:

More posts on the subject matter:

LOD is shorter near the poles:

Object selection based on LOD/size is erratic:

Tree objects are wrongly scaled (with pictures):

LOD problems - Trees & Water - #1026 by CptLucky8

Distance based Object LOD selection wrong by 45 degrees (pictures):

LOD Problems - Distances revisited - #32 by CptLucky8

Distance based Lights visibility wrong by 45 degrees (pictures):

LOD Problems - Distances revisited - #38 by CptLucky8

MP aircraft lights in VR aren’t showing past 5nm:

Increase distance threshold to see other aircraft navigation and strobe lights at night

My compilation of LOD UI settings suggestions

LOD: settings and suggestions


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.

Thanks for your hard work in advance!

1 Like

Moderator Edit: Merged from another topic.

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.

1 Like

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 :-1:
What a way to run away from supporting your customers.

1 Like

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:

LOD Problems - Distances revisited - #38 by CptLucky8

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.

1 Like

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.

1 Like

Any further news on this, have they mention it at all in blogs or interviews etc?

With SU5, there is still the culling problem but this time it has shifted sides!

With SteamVR FOV 50% and the Index:

Before: it culls the objects too soon at the outer edge of the views (left on left view, right on right view).

After: it culls the objects too soon at the inner edge of the views (right on left view, left on right view) :scream:

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…

1 Like

and a few months later:

so what’s next?

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.

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!

There is definitely something wrong here, and I wouldn’t be surprised there is a link with this FS2020 bug and another one: [BUG] Shader code ‘viewdir’ and shadow/light rendering are inconsistent on right eye