VR experiences IL-2 Korea

[Husar]

7 hours ago, Panzerlang said:

Tried it. It does significantly improve smoothness low over Seoul but it crashed my OG Crystal within a couple of minutes.
Its own FPS counter showed a solid 90 but for some reason makes the game's and Cheeky's counters show 45.

It should show 45,  those are "real" frames . It's new project so might crashing, I think it will mature and be more stable.

Edited October 2 by Husar

[Husar]

10 hours ago, YoYo said:

Right, but as I understand it, that requires enabling DLSS, which I don't like for a number of reasons.

I’ve never really liked DLSS, especially in DCS, where distant contacts are harder to spot. But in Korea, that’s not really an issue. DLSS/DLAA with preset M significantly reduces smearing, and softens the image  can easily sharpen it again using the additional sharpening options available in-game and in VD. Foveated DLSS give me stable fps where before it was dipping below headset Hz.

 

Edited October 2 by Husar

[robzerg]

3 hours ago, AndreiTomescu said:

I'm a monitor guy, but I hear and suffer along with Sandmarken's pain, and also suffer because of his future campaign getting delayed due to this issues.

What I'm wondering is:

- is it ok for a game designed for VR to require sooooo much headache for the users, and such much search for third party solutions?

- shouldn't the game provide propper settings from the beginning, without dozens of variables and variants and endless attempts?

- is VR actually a Star Trek territory? Something experimental?

Well, this really keeps me away from VR from now.

All of these are valid concerns, and I agree completely with your points. However VR is also a revelation; actually sitting IN the cockpit with the instruments, dials and environment around you is literally so immersive that, despite the massive hassle setting things up and fiddling with things to get the optimal framerate to detail level trade-off the overall experience is totally worth it!

Also if Korea is a bit of a hassle then GB is comparatively straightforward (due to less demanding graphics). I've recently had fun going back to the 109 over Odessa (my favourite map) - that cockpit is so cool!

 

 

 

[GiftGruen]

3 hours ago, AndreiTomescu said:

I'm a monitor guy, but I hear and suffer along with Sandmarken's pain, and also suffer because of his future campaign getting delayed due to this issues.

What I'm wondering is:

- is it ok for a game designed for VR to require sooooo much headache for the users, and such much search for third party solutions?

- shouldn't the game provide propper settings from the beginning, without dozens of variables and variants and endless attempts?

- is VR actually a Star Trek territory? Something experimental?

Well, this really keeps me away from VR from now.

Well. You should take into account that Korea is still really new - and also the VR world is far away from beeing standardized like a 2D-monitor.

This causes some 'friction' and indeed you should invest some time and have joy in tinkering with hardware and settings. If you are more the plug-and-play person, VR can indeed be frustrating. I'd also say that VR is still more expensive than 2D ... but it's also true that good VR headsets like Quest3 or CrystalLight are not that expensive any more, it's  maybe rather the high GPU costs and for VR you simply need a rather highend / expensive GPU, especially in Korea.

On the other hand, the feeling and immersion is so phenomenal ...  you are sitting in a plane and the world is around you.

Simply another level of gaming, for me personally, at least.

 

Edited October 2 by GiftGruen

[Panzerlang]

5 hours ago, YoYo said:

And what about artifacts? For example, during a dogfight with another fighter?

In the two minutes it worked I saw nothing unpleasant. 🙂

Cheeky's given me a new version of his API to try, I'll be on it shortly. Plus I'm back on the DPort monitor, so fingers crossed on all fronts. 😄

[AndreiTomescu]

I would try and take this road with my new 9070xt, however, since i still have stuttering on a 9700x cpu, i wonder how that stutter might feel in VR. like getting motion sickness and such. 

[GiftGruen]

Your 9700x should be quite on par with my i5-14600KF, even faster in single threads and your 9070xt with 16GB VRAM is at 4080/5070ti level. 

This should be a more than solid base for visiting the VR rabbit hole 😉

I am not sure if VR support by AMD is on the level NVidia offers ( I heart years ago that there are several driver troubles but this may be old info ) so some AMD guy should maybe answer this.

You will anyway have some motion sickness in the beginning. Start slowly with short sessions to get used to, it goes away then. At least this was my experience.

Edited October 2 by GiftGruen

[sandmarken]

3 minutes ago, GiftGruen said:

Your 9700x should be quite on par with my i5-14600KF, even faster in single threads and your 9070xt with 16GB VRAM is at 4080/5070ti level. 

This should be a more than solid base for visiting the VR rabbit hole 😉

I am not sure if VR support by AMD is on the level NVidia offers ( I heart years ago that there are several driver troubles but this may be old info ) so some AMD guy should maybe answer this.

 

I have a similar setup to Andrei but with a 7800X3D, and il2GB is flawlessly at all settings maxed. After tinkering, I had a good experience in Korea as well. I am only fielding a Quest 3S, but it is more than enough for a good experience, especially coming from an old Rift S. I guess the devs will solve this and it will work again.

AMD seems to do fine with VR. I have no issues, at least except the planes disappearing in front of clouds sometimes.

[robzerg]

55 minutes ago, AndreiTomescu said:

I would try and take this road with my new 9070xt, however, since i still have stuttering on a 9700x cpu, i wonder how that stutter might feel in VR. like getting motion sickness and such. 

Stuttering is jarring when it occurs, but doesn't (for me) cause motion sickness. I also now have Korea to an acceptable level, and GB is buttery smooth!

When I first tried VR I certainly did get motion sickness, and could only play for 15 minutes before needing a break!  However that went away and I don't get motion sickness at all now - I think it's something that you get used to.  

I've a Pico 4 headset, which is similar in spec to a Quest 3, but much cheaper second-hand as it's not as well known. Works perfectly 

 

 

 

Edited October 2 by robzerg

[Panzerlang]

So, things have improved with Cheeky's API but still no working eye tracking. Here's the report Aevum generated for me (that's what I call GPT, lol).

"

Pimax Crystal — Eye Tracking Input Now Working, but Stereo Mapping/Calibration Still Fails

Hardware / software

• Headset: Pimax Crystal (original Crystal)
• Runtime: Pimax OpenXR
• Eye tracking calibration in Pimax software: working correctly
• Eye tracking with Quad Views in DCS using the same headset/runtime: working correctly
• OpenXR Explorer reports XR_EXT_eye_gaze_interaction
• Using DLSS-SR, not DLSS-NR / neural rendering

Update from my previous report

The new version of Cheeky has clearly fixed the initial eye-tracking input problem.

The current diagnostics now show:

• System supports eye tracking: YES
• Session focused: YES
• Gaze input active: YES
• Tracking valid: YES
• Submission mapping ready: YES
• Runtime: Pimax OpenXR
• Runtime adapter loaded: YES
• Compatible gaze ABI: YES
• Mapping ambiguity: NO
• Active stereo views: 2
• Sample age: 0 ms

So Cheeky is now successfully receiving valid gaze data from the Pimax Crystal through Pimax OpenXR.

Remaining problem — stereo eye mapping

Despite valid gaze input, Cheeky still cannot establish the mapping between the gaze data and the two stereo views.

The diagnostics still show:

• Left eye mapped: NO
• Right eye mapped: NO
• Stable matches: 0
• Alignment: manual fallback
• Aligned center: 0.5000, 0.5000
• Crop delta: 0, 0 px

The main Stereo Gaze status says:

"Automatic stereo alignment has no usable projection or eye mapping using manual fallback placement."

The shared gaze/render fields also remain inactive:

• Shared gaze mode: NO
• Shared gaze fresh: NO
• Shared render projection: NO
• Latest shared DLSS view: 0
• Shared gaze evaluations: 0

Recalibration test

I enabled Automatic eye calibration for this session and changed the calibration method from Auto to Standard Corners.

The UI then showed:

• Active method: standard corners
• Learned starting method: not learned yet

I pressed Recalibrate Now.

However, nothing visibly happened.

There was no calibration sequence, no visible calibration targets, no apparent progress, and none of the diagnostic mapping values changed.

In particular:

• Left eye mapped remained NO
• Right eye mapped remained NO
• Stable matches remained 0
• Stereo alignment remained manual fallback

I am not sure whether this is the expected behaviour of the new calibration system. If pressing Recalibrate Now is supposed to initiate a visible calibration sequence or otherwise change the diagnostic state, that does not appear to be happening here.

Current status

So the situation has changed significantly compared with my original report:

Pimax Crystal eye tracking → Pimax OpenXR → Cheeky gaze input: WORKING

Cheeky gaze input → stereo eye/view mapping → NOT WORKING

The headset is providing valid gaze data and Cheeky is receiving it, but Cheeky is still unable to establish usable left/right eye mappings for the two stereo views.

This appears to leave the problem specifically in the stereo projection / eye mapping / calibration stage, rather than basic Pimax eye-tracking compatibility.

For comparison, Pimax's own eye-tracking calibration works correctly, and Quad Views in DCS successfully uses the same Pimax Crystal eye tracking through the same OpenXR setup.

Could you please confirm whether Recalibrate Now is expected to produce any visible calibration activity in this version, and whether the diagnostic state described above indicates that the stereo mapping process is failing before or during calibration?

I can provide another diagnostic ZIP from this current version if that would help."

[Husar]

2 hours ago, robzerg said:

Also if Korea is a bit of a hassle then GB is comparatively straightforward (due to less demanding graphics)

The performance drops and stutters aren’t caused by the pixel count. I get them whether I set the resolution to Potato or Godlike. They’re mainly caused by ground objects and their interactions, such as explosions and AI, which can hog the CPU thread to the point where the GPU is waiting for new frames. When that happens, GPU utilization drops below 40% and the frame rate can fall below 40 FPS and for VR we need at least 72.

[JG14_Jagr]

I'm a 2D player on TrackIR but several friends are suffering through the troubles that many are having.  Might I Make a suggestion?  Have Players post their system specs, graphics card driver version, and which VR device and how they have it setup plus their in game/ in device settings.  Then give the performance results, anything you've changed that made a difference.  There are so many possible variations of hardware and devices that there's no "one fix for all" solution but there needs to be some better organized information sharing.

[Clyde1]

3 hours ago, Panzerlang said:

So, things have improved with Cheeky's API but still no working eye tracking. Here's the report Aevum generated for me (that's what I call GPT, lol).

"

Pimax Crystal — Eye Tracking Input Now Working, but Stereo Mapping/Calibration Still Fails

Hardware / software

• Headset: Pimax Crystal (original Crystal)
• Runtime: Pimax OpenXR
• Eye tracking calibration in Pimax software: working correctly
• Eye tracking with Quad Views in DCS using the same headset/runtime: working correctly
• OpenXR Explorer reports XR_EXT_eye_gaze_interaction
• Using DLSS-SR, not DLSS-NR / neural rendering

Update from my previous report

The new version of Cheeky has clearly fixed the initial eye-tracking input problem.

The current diagnostics now show:

• System supports eye tracking: YES
• Session focused: YES
• Gaze input active: YES
• Tracking valid: YES
• Submission mapping ready: YES
• Runtime: Pimax OpenXR
• Runtime adapter loaded: YES
• Compatible gaze ABI: YES
• Mapping ambiguity: NO
• Active stereo views: 2
• Sample age: 0 ms

So Cheeky is now successfully receiving valid gaze data from the Pimax Crystal through Pimax OpenXR.

Remaining problem — stereo eye mapping

Despite valid gaze input, Cheeky still cannot establish the mapping between the gaze data and the two stereo views.

The diagnostics still show:

• Left eye mapped: NO
• Right eye mapped: NO
• Stable matches: 0
• Alignment: manual fallback
• Aligned center: 0.5000, 0.5000
• Crop delta: 0, 0 px

The main Stereo Gaze status says:

"Automatic stereo alignment has no usable projection or eye mapping using manual fallback placement."

The shared gaze/render fields also remain inactive:

• Shared gaze mode: NO
• Shared gaze fresh: NO
• Shared render projection: NO
• Latest shared DLSS view: 0
• Shared gaze evaluations: 0

Recalibration test

I enabled Automatic eye calibration for this session and changed the calibration method from Auto to Standard Corners.

The UI then showed:

• Active method: standard corners
• Learned starting method: not learned yet

I pressed Recalibrate Now.

However, nothing visibly happened.

There was no calibration sequence, no visible calibration targets, no apparent progress, and none of the diagnostic mapping values changed.

In particular:

• Left eye mapped remained NO
• Right eye mapped remained NO
• Stable matches remained 0
• Stereo alignment remained manual fallback

I am not sure whether this is the expected behaviour of the new calibration system. If pressing Recalibrate Now is supposed to initiate a visible calibration sequence or otherwise change the diagnostic state, that does not appear to be happening here.

Current status

So the situation has changed significantly compared with my original report:

Pimax Crystal eye tracking → Pimax OpenXR → Cheeky gaze input: WORKING

Cheeky gaze input → stereo eye/view mapping → NOT WORKING

The headset is providing valid gaze data and Cheeky is receiving it, but Cheeky is still unable to establish usable left/right eye mappings for the two stereo views.

This appears to leave the problem specifically in the stereo projection / eye mapping / calibration stage, rather than basic Pimax eye-tracking compatibility.

For comparison, Pimax's own eye-tracking calibration works correctly, and Quad Views in DCS successfully uses the same Pimax Crystal eye tracking through the same OpenXR setup.

Could you please confirm whether Recalibrate Now is expected to produce any visible calibration activity in this version, and whether the diagnostic state described above indicates that the stereo mapping process is failing before or during calibration?

I can provide another diagnostic ZIP from this current version if that would help."

Mine seems to be working fine.

 

[YoYo]

9 hours ago, AndreiTomescu said:

I'm a monitor guy, but I hear and suffer along with Sandmarken's pain, and also suffer because of his future campaign getting delayed due to this issues.

What I'm wondering is:

- is it ok for a game designed for VR to require sooooo much headache for the users, and such much search for third party solutions?

- shouldn't the game provide propper settings from the beginning, without dozens of variables and variants and endless attempts?

- is VR actually a Star Trek territory? Something experimental?

Well, this really keeps me away from VR from now.

The point is that, ideally, the game itself should offer mechanics and gameplay smooth enough that you don't have to turn to third-party solutions or engage in drastic modding, something not everyone knows how to do, let's be honest. The game should be playable right out of the box, without requiring elaborate tweaks.

I also don't know to what extent these "tweaks" affect, say, career mode gameplay, where I sometimes have a high frame rate that drops instantly after dropping a few bombs or using napalm, or depending on the number of units. In such situations, it’s not even a GPU issue but a CPU one in IL-2 Korea; the processor gets overwhelmed by the computational load, and there is still a bottleneck there. All these tweaks improve FPS but do not reduce the load imposed by the simulator itself. I haven't had time to test this, and I'm not sure to what extent it's even worth doing, since the problem lies not in the users' hardware, but in the game code itself and optimization for VR of all processes.

1 hour ago, JG14_Jagr said:

I'm a 2D player on TrackIR but several friends are suffering through the troubles that many are having.  Might I Make a suggestion?  Have Players post their system specs, graphics card driver version, and which VR device and how they have it setup plus their in game/ in device settings.  Then give the performance results, anything you've changed that made a difference.  There are so many possible variations of hardware and devices that there's no "one fix for all" solution but there needs to be some better organized information sharing.

Quite a few people have that in their signatures. Do have it "on"?

[AndreiTomescu]

18 minutes ago, YoYo said:

The point is that, ideally, the game itself should offer mechanics and gameplay smooth enough that you don't have to turn to third-party solutions or engage in drastic modding, something not everyone knows how to do, let's be honest. The game should be playable right out of the box, without requiring elaborate tweaks.

yes, thank you. that i was saying, you just said it better.

[AndreiTomescu]

after testing several variants, overclocking, undervolting, testing again, retesting, tweaking, praying, and so on, i fell like i'm kind of an developer/tester/frontier man.

I ain't saying it shoud go like in a PS5 game, but sometimes i fell it's too much time in tweaking taken from gaming time.

and all this for less stutter in 2D, on a high end 2k euros computer.

from a limited time available, since i'm a middle aged man.

[GiftGruen]

1 hour ago, JG14_Jagr said:

I'm a 2D player on TrackIR but several friends are suffering through the troubles that many are having.  Might I Make a suggestion?  Have Players post their system specs, graphics card driver version, and which VR device and how they have it setup plus their in game/ in device settings.  Then give the performance results, anything you've changed that made a difference.  There are so many possible variations of hardware and devices that there's no "one fix for all" solution but there needs to be some better organized information sharing.

Difficult, probably to create and update such a ‚catalog‘ since things change so rapidly.  Will be outdated quite fast.

Maybe rather suggest your friends to come in here with their specs and/or problems to get some ideas/tips ?

4 minutes ago, AndreiTomescu said:

….from a limited time available, since i'm a middle aged man.

Well, Andrei, that‘s quite a good way to become an old one 😉

[ekoksk]

I had the chance to jump into the game today. Stuttering again, and VR enthusiasts forced to play with even worse graphics. An update, perhaps?

[GiftGruen]

3 minutes ago, ekoksk said:

I had the chance to jump into the game today. Stuttering again, and VR enthusiasts forced to play with even worse graphics. An update, perhaps?

Got an NVidia Card? Try Cheeky stuff. See above.

[Panzerlang]

7 hours ago, Clyde1 said:

Mine seems to be working fine.

 

Thanks Clyde. Do you see anything happen when you hit Recalibrate Now?

Anyway, Aevum has checked the diagnostic files I sent her and seems to have found the problem...it's an image-grab file-size limit. Her report that I've posted on Cheeky's board:

"

Hi. I have a new diagnostic result after trying to work around the suspected D3D12 readback memory limit by lowering the Pimax Crystal render/image quality from native 1.0 to 0.5.

Cheeky Foveated DLSS Standalone 0.5.5 + IL-2 Korea

Hardware/software

• Pimax Crystal
• IL-2 Korea / IL2Series.exe
• DX12 renderer
• DLSS-SR active
• Cheeky Foveated DLSS Standalone 0.5.5
• OpenXR eye tracking
• NVIDIA GPU

Test performed

I initially ran the game at native Crystal render quality. Cheeky's diagnostics showed the following problem:

• D3D12 DLSS source textures: 4312 × 5104
• Both source textures reported: readback_memory_limit
• D3D12 readback failures: 2591
• Eye calibration repeatedly rejected samples with no_consistent_eye_pair
• Left eye mapped: NO
• Right eye mapped: NO
• No usable stereo projection / eye mapping

I then deliberately reduced the Pimax render/image quality all the way down to 0.5, specifically to see whether reducing the headset render resolution would bring the source textures below whatever readback-memory threshold Cheeky is enforcing.

Result: absolutely no change to the relevant source texture dimensions.

At Pimax 0.5, Cheeky is still receiving:

• DLSS source textures: 4312 × 5104
• Source format: DXGI format 10
• Both source textures still report readback_memory_limit
• Eye mapping still fails
• Left eye mapped: NO
• Right eye mapped: NO
• Calibration still reports no_consistent_eye_pair

There is also an interesting distinction in the diagnostic: Cheeky is able to successfully capture a submitted stereo texture at 4312 × 5104, while the two DLSS source textures at the same dimensions are rejected with readback_memory_limit.

So lowering Pimax's render/image quality does not appear to affect the texture dimensions Cheeky is attempting to read from the DLSS source path.

I also explicitly used Cheeky's Reset learned calibration method / Recalibrate now function after lowering the Pimax setting. The recalibration command was accepted, but after waiting it still failed to produce either eye mapping. The diagnostics continued to report no_consistent_eye_pair.

Current conclusion

The strongest evidence at this point is that the failure is specifically associated with Cheeky's D3D12 DLSS source-texture readback path.

The important question is therefore:

What exactly is readback_memory_limit in Cheeky 0.5.5, and can that limit be increased, disabled, or changed for these 4312 × 5104 DLSS source textures?

Since changing Pimax's render/image quality from native 1.0 to 0.5 does not change the 4312 × 5104 source textures, lowering headset resolution does not appear to provide a workaround.

If there is a configurable or hard-coded allocation/readback threshold in the standalone build, I'd like to know where it is and whether it can be increased. If the limit is intentional for stability, is there an alternative D3D12 readback method that can handle these source textures?

I can provide the complete support ZIP/logs if useful."

[Panzerlang]

I tried OFXR Bridge again, it worked this time, but I didn't see enough benefit from it, plus there was a bit of ghosting on a Sabre going across my nose at distance.

[Clyde1]

3 hours ago, Panzerlang said:

Thanks Clyde. Do you see anything happen when you hit Recalibrate Now?

Anyway, Aevum has checked the diagnostic files I sent her and seems to have found the problem...it's an image-grab file-size limit. Her report that I've posted on Cheeky's board:

"

Hi. I have a new diagnostic result after trying to work around the suspected D3D12 readback memory limit by lowering the Pimax Crystal render/image quality from native 1.0 to 0.5.

Cheeky Foveated DLSS Standalone 0.5.5 + IL-2 Korea

Hardware/software

• Pimax Crystal
• IL-2 Korea / IL2Series.exe
• DX12 renderer
• DLSS-SR active
• Cheeky Foveated DLSS Standalone 0.5.5
• OpenXR eye tracking
• NVIDIA GPU

Test performed

I initially ran the game at native Crystal render quality. Cheeky's diagnostics showed the following problem:

• D3D12 DLSS source textures: 4312 × 5104
• Both source textures reported: readback_memory_limit
• D3D12 readback failures: 2591
• Eye calibration repeatedly rejected samples with no_consistent_eye_pair
• Left eye mapped: NO
• Right eye mapped: NO
• No usable stereo projection / eye mapping

I then deliberately reduced the Pimax render/image quality all the way down to 0.5, specifically to see whether reducing the headset render resolution would bring the source textures below whatever readback-memory threshold Cheeky is enforcing.

Result: absolutely no change to the relevant source texture dimensions.

At Pimax 0.5, Cheeky is still receiving:

• DLSS source textures: 4312 × 5104
• Source format: DXGI format 10
• Both source textures still report readback_memory_limit
• Eye mapping still fails
• Left eye mapped: NO
• Right eye mapped: NO
• Calibration still reports no_consistent_eye_pair

There is also an interesting distinction in the diagnostic: Cheeky is able to successfully capture a submitted stereo texture at 4312 × 5104, while the two DLSS source textures at the same dimensions are rejected with readback_memory_limit.

So lowering Pimax's render/image quality does not appear to affect the texture dimensions Cheeky is attempting to read from the DLSS source path.

I also explicitly used Cheeky's Reset learned calibration method / Recalibrate now function after lowering the Pimax setting. The recalibration command was accepted, but after waiting it still failed to produce either eye mapping. The diagnostics continued to report no_consistent_eye_pair.

Current conclusion

The strongest evidence at this point is that the failure is specifically associated with Cheeky's D3D12 DLSS source-texture readback path.

The important question is therefore:

What exactly is readback_memory_limit in Cheeky 0.5.5, and can that limit be increased, disabled, or changed for these 4312 × 5104 DLSS source textures?

Since changing Pimax's render/image quality from native 1.0 to 0.5 does not change the 4312 × 5104 source textures, lowering headset resolution does not appear to provide a workaround.

If there is a configurable or hard-coded allocation/readback threshold in the standalone build, I'd like to know where it is and whether it can be increased. If the limit is intentional for stability, is there an alternative D3D12 readback method that can handle these source textures?

I can provide the complete support ZIP/logs if useful."

Recalibrate didnt do anything. Eye tracking only works for me with openvr checked in game and using steamvr. I can only use fix foveated rendering with openxr on its own. attached is the error I get trying to use eye tracking with openxr.

 

[YoYo]

5 hours ago, Panzerlang said:

I tried OFXR Bridge again, it worked this time, but I didn't see enough benefit from it, plus there was a bit of ghosting on a Sabre going across my nose at distance.

That’s exactly what I was worried about with this "frame generator", that there would be artifacts or ghosting, even though the concept is interesting and promising. Thanks for the test.

[T24_Martin]

I very much appreciate the work of everybody trying to make VR more reliable and improve performance in games!

But I am not a big fan of tinkering with settings and third party tools. It often feels like breaking the user experience and adding a layer of unnecessary complexity.

This is something that needs to be provided by the game itself. Releasing a VR flight sim in 2026, it must be capable of providing a solid experience for all VR users and not just for certain headset resolutions or GPUs. 

Headsets with 4k to 8k resolution is the normal today and not everybody is lucky enough to buy a RTX. So please Devs use every tool available to reduce GPU and CPU workload.

Edited October 3 by T24_Martin

[YoYo]

41 minutes ago, T24_Martin said:

I very much appreciate the work of everybody trying to make VR more reliable and improve performance in games!

But I am not a big fan of tinkering with settings and third party tools. It often feels like breaking the user experience and adding a layer of unnecessary complexity.

This is something that needs to be provided by the game itself. Releasing a VR flight sim in 2026, it must be capable of providing a solid experience for all VR users and not just for certain headset resolutions or GPUs. 

Headsets with 4k to 8k resolution is the normal today and not everybody is lucky enough to buy a RTX. So please Devs use every tool available to reduce GPU and CPU workload.

Of course. I’ve already written about this. There’s nothing to get excited about, because it’s just a workaround and with workarounds, you always face difficulties, compatibility issues, server compliance problems, and sometimes the role of a guinea pig; ultimately, modding can even cause the simulator to fail to launch or malfunction. It all carries risk. The game should be fully playable right out of the box at full scope on, say, medium settings and mid-range hardware, plain and simple. It remains nothing more than a temporary workaround for the problem.