Image shake when Foveated Rendering other that 0.50 and Eye Tracking enabled on Pimax Crystal OG (wrong resolution division when Fov. Ren. Scale slider introduced in SU4?)

Sim Update 4 Beta | MSFS 2024 Virtual Reality
, , ,
1

ISSUE DESCRIPTION

Description of the issue:

There is high frequency image shake (vibration/instability) when Fovated Rendering (with FoveatedRenderignScale at any value other than 0.50) is enabled in the sim (Pimax Crystal OG) and the Eye Tracking is enabled in PimaxPlay. Tested in the menus, and with A2A Comanche on the ground. The shake even triggers a slight nausea for me, it is quite unpleasant, forced me to opt out from the beta.

The shake is immediattely visible in the menu when changing Foveated Renderign Scale for 0.50 to any other value.
I suspect some disturbance in processing the Eye Tracking information or more general issue with Foveated Rendering or generating one-eye-only image on the monitor.

FREQUENCY OF ISSUE

Always when Fovated Rendering and Eye Tracking is enabled.

REPRODUCTION STEPS

Please list clear steps you took in order to help our test team reproduce the same issue:

  1. Enable Foveated Rendering in the sim.

  2. Set Foveated Rendering Scale for any value other than the default 0.50.

  3. Enable Eye Tracking in PimaxPlay.

  4. Enable VR in the sim.

  5. Look at the shaking image in the VR googles.

YOUR SETTINGS

If the issue still occurs with no mods and add-ons, please continue to report your issue. If not, please move this post to the User Support Hub.

What VR headset and peripherals are you using: Pimax Crystal OG, locked to and achieving 45 FPS (headset set to 90Hz), using Pimax embedded OpenXR Runtime, PimaxClient v.1.42.1.

[PC Only] Are you using Developer Mode or have you made any changes to it? No

[PC Only] What GPU (Graphics Card) do you use? 4090

[PC Only] What other relevant PC specs can you share? 9800x3D, 64GB RAM

I believe that introducting Foveated Rendering Scale slider changed some math formula for calculating the resulting resolutions, and the formula no longer returns values which are clean (no carry) integer divisions on the Pimax Crystal OG resolution, even with the OpenXR Toolkit resolution scaling applied like in the workaround listed below which worked in SU3 but no longer works in SU4. Reviewing this formula should result in an easy fix.

With FoveatedRenderingScale 0.300000 and the workaround applied (base resolution 4320 x 5100) the resulting resolutions are:

  • SU3: 1296 x 1530 - integer division without carry, as expeted

  • SU4 beta: 1295 x 1529 - the divison in no longer fully integer, there is some carry/rounding with negates the applicability of the workaround

1 Like
2

I’m glad someone else noticed this, my experience has been very slightly different. When I set the foveate region to the default value of 50 the shake disappears. Any value below that (even 49) it instantly starts again.

1 Like
3

I have the same issue with Pimax Super. 5800X3D, 4090, 64 GB RAM, Win 11.

4

Felt the same way, using a Varjo Aero.

Thought maybe it was related to my motion rig, but it sounds like other people are having the same issue!

I ran with motion and without motion, and both were a little jittery, with no clear cause since it wasn’t like that before.

5

I just tried it with my Crystal OG and didn’t notice any really obvious shake with FR on. Changing render scale from, 0.5 to 0.25 also made no difference.

In the Super it’s harder to tell, as I still have an issue with oversensitivity to head shake, which gives me jitter no matter what I do in regards to FR with eye tracking.

Though I have just realised that I didn’t turn eye tracking off in either the OG or Super. Back to more testing…

6

I tested a bit more - the shake appears only when Foveated Rendering Scale is set to any value other then the default 0.50. I updated the issue descritpion in the original post

7

I confirm your finding.

8

I’m not able to reproduce and I think we have similar hardware.

Running 0.20 with TAA.

9

It seems to be inconsistent, which is weird. Sometimes it works lowering render scale, other times it’s a mess.

In the Pimax OG Crystal I have successfully used render scales of 0.5, 0.25 and 0.20 in SU3 without introducing image shake, gaining impressive increases in FPS.

Tonight however, when I went back to that headset on SU$ beta, I definitely noticed an unacceptable jitter in the scenery when lowering the render scale below 0.5. It was intolerable in fact.

It’s much more difficult to test in the Pimax Super, as despite all efforts, my copy is itself super sensitive (no pun intended) to minute head movements. But even so, I did notice the added shake using FR below 0.5 render scale.

I have read here, on Discord and Reddit that the lower render scales needs to be a integer number divisor. So 0.3 is a problem. But 0.20 or 0.25 should be OK.

Here’s a thread on these forms discussing the same problem.

10

Some more tests done:

  • running with or without OpenXR Toolkit - issue still there
  • completely emptying the Community folder - issue still there
  • deleting UserCfg and allowing the sime to recreate it - issue still there
  • changing Pimax embedded OpenXR runtine to PimaxXR OpenXR runtime - issue still there
  • downgrading PimaxPlay from PimaxPlaySetup_Release_ToC_V1.42.1.177_202509031956 to PimaxPlaySetup_Release_ToC_V1.40.1.114_202506171545 - issue still there
  • solution listed in the post below which was working in SU3, not working in SU4 beta 1.6.5.0 - issue still there
    Quad Views with FoveatedRenderingScale < 0.5 causes jitter - #3 by W1CKL0S

I visually verified that the jitter observed in SU4 is of the same type as in SU3 without the workaround above applied.

There is a notable difference however, when applying the “integer workaround” in the link above:

Setting TAA mode allows reading the resolution directly in the sim VR Graphics settings menu.

With FoveatedRenderingScale 0.300000 and the workaround applied (base resolution 4320 x 5100) the resulting resolutions are:

  • SU3: 1296 x 1530 - integer division without carry, as expeted
  • SU4 beta: 1295 x 1529 - the divide is no longer fully integer, there is some carry/rounding which negates the applicability of the workaround

I tried setting FoveatedRenderingScale like 0.300232 to force the resolution back to 1296 x 1530, but seems like sim only accepts two non-zero digits after the dot, so it overwritten the value back to 0.30, which resulted in the resolution 1295 x 1529.

I believe that introducting Foveated Rendering Scale slider changed some math formula for calculating the resulting resolutions, and the formula no longer returns values which are clean (no carry) integer divisions of the Pimax Crystal OG resolution, even with the OpenXR Toolkit resolution scaling applied. Reviewing this formula should result in an easy fix.

A workaround could be finding some combination of the Foveated Rendering Scale values and Pimax display resolutions declared in the OpenXR Toolkit, which would result in clean integer division, but I was unable to find such combination.

2 Likes
11

Could you try without supersampling? The problem might lay in the integer division of the resolution.

Where exatly you apply supersampling?

12

Not had much time with SU4 to test QV right now but here’s a calc tip I have used with SU3 and this issue. But if things have changed internally may be little use.

To get render sizes to force with OXRTK I used AI to do the calc (I used GROK for this). Just plug the vars into this prompt for the X and Y res and scale and then into OXRTK (OhneSpeed Mod version).

AI: nearest number to [render res] that when multiplied by [scale] gives whole number that is even

13

Last flight in the latest SU4 was a bit wonky for me today. I was getting random headset movements, not the shakes. Where you jump forward a virtual inch or two and then back.

I’ve seen this before and it’s usually related to the sim launch.

14

I have the same exact problem. Had it with MSFS 2020 and 2024 with Pimax crystal OG and super. As long as I leave it a .50 the image is smooth and stable but when I tried going down to .30 it’s has that micro shake that is unplayable.

15

Same problem with my Pimax Super + 5090

16

You can’t have the same problem with MSFS2020, as there is no Foveated Rendering in MSFS2020.

17

Looks like I managed to find a combination which works without jitter on Crystal OG in SU4 beta:

Foveated Rendering Scale 0.25 (neat division by 4)

Override resolution in OXRT to 4312 x 5100 (small step down from the original 4312 x 5102).

The resulting resolution should be 1078 x 1275, and this is exactly the resolution shown in sim VR Graphics settings with TAA mode.

For the experimenting with resolutions I use TAA mode at 100% as it shows the resolution in the VR Graphics settings immediattely. For the actual flying I’m using DLSS-DLAA or DLSS-Quality to achieve 45 FPS in most scenarios on Pimax Crystal OG on 4090, with 9800x3D.

3 Likes
18

I received a new slam file for my Pimax Super to see if it improved tracking jitter (which it did) so had two long flights just now to test it out.

I found that using either DLAA or DLSS Quality at “native resolution”, with no resolution override in the Toolkit that 0.25 gave a smooth flight, whereas 0.2 introduced jitters, despite the higher FPS.

Haven’t tried TAA mode to ensure an exact match, as you suggest, but will next time I fly.

Btw, the Super looks amazing when there’s little to no jitter. :smiley:

19

The native resolution in Super differs from Crystal, so probably at 0.25 you can achieve clear integer division without a reminder.

Normally I fly DLAA, I use TAA only for the experimenting with the resolutions as it shows in the VR Graphics menu the resolution after applying the Foveated Rendering Scale. After setting the resolution in TAA100 which eliminates the jitter also the DLSS/DLAA is jitter-free

20

I just want to point out that OpenXR Toolkit is third party software that has been unsupported for years and the author himself has stated here many times it’s a mistake to be using it.

MSFS has its own Quad views internal implementation to start with (which OXRTK doesn’t provide) but additionally throwing OXRTK into the mix just muddies the waters when you’re trying to add data points for developers to debug.

If I’m reading through this bug report I’ve just discarded your info because you’ve added a variable in that I shouldn’t have to try and replicate. (I don’t work on this product to be clear).

The best thing you could do here is to attempt to replicate these results with OpenXR Toolkit completely removed (which again is basically redundant and unsupported).

Also also to be clear this is not an attack of any sort, your data is important and useful as a developer on a similarly large code base I feel the frustration when I read these.