RealDCSpilot

If you mean the PD setting in DCS, it's totally different from SS (aka render resolution setting in Steam VR). The PD setting is a multiplicator that takes your standard HMD panel resolution and adds or subtracts the amount of real rendered pixels (going higher or lower than 1.0). At 1.0 your HMD will always receive the "perfect" fit for their specific amount of needed pixels for the panels, because the game is hooked directly into the VR compositor driver of your HMD. It's like the native resolution setting for a monitor display. Going higher on the PD setting will start to waste rendered pixels because the panels aren't able to display them 1:1 anyway. This will also cost valuable CPU frametime. The external render resolution setting in Steam VR for instance acts as a basic supersampling antialiasing filter. https://en.wikipedia.org/wiki/Supersampling It takes the resolution it gets from DCS and starts to oversample or undersample, depends how you set it up. It's a much more effective way to enhance image sharpness, costs only a bit more GPU ressources instead of putting more strain onto your CPU. If you see low GPU usage while running DCS, the Steam VR resolution setting should be the first setting to play with to make use of your GPU's processing headroom. It doesn't work in realtime, you always have to restart the game to see an effect. Always have an eye on VRAM usage when playing with higher SS settings.

Here is some data from real VRAM usage on my system: https://forums.eagle.ru/showpost.php?p=4522981&postcount=53

@Stal2k Okay, found out how to show real VRAM usage per process in Afterburner. As you can see VRAM usage is way too high for 11GB cards at very high VR settings (ingame and SteamVR SS). Switching to F10 map costs more than 1 GB extra. If you want to examine what is happening on your end:

Yep, keep in mind that a big fat GPU also needs a CPU with big shovels to keep up with the GPU's data amount and bandwidth at high resolutions. If the CPU gets overwhelmed, a "simple" GPU upgrade might make things worse.

@Stal2k For science, did you also tried to test Steam VR against the latest Steam VR beta? There maybe differences. (I'm on Steam VR beta since 2016)

It makes the module even worse if it's working randomly different on anyone's pc.

Looks fantastic!

@Stal2k Five pages later and you still misunderstanding what i'm trying to say. I'm not backing up ED and i'm definitely not trying to say it's your fault. You know how they work, we are the last line of beta testers. How about that, please try my suggested steps which may lead to a more precise bug report. Something like "Increased VRAM usage leads to Steam VR fail since the latest patches". Be very conservative with the first step, go pretty low on settings. Watch VRAM usage. Then go higher and try to find the sweetspot. After that, post the settings that worked before and where you are now. I can't do this anymore by myself. I can be totally wrong, it's just my theory from what i've seen on my end. It will help a lot of people to understand whats going on.

There is no extra arcade mode for the Gazelle (other modules support this mode while having separate control sets for it in the control options were you choose for instance "Ka-50" or "Ka-50 real"). The current FM is very arcade mode, yes. What doesn't make sense to me is how "Easier Controls" are much less forgiving. I'm sure you meant the opposite?

There is a high chance for triggering desorientation and motion sickness i guess.

@CobaltUK I'm only pointing at VRAM usage, DCS seems to need to allocate more ressources since the introduction of the syria map and the latest patches seem to add even more VRAM usage on top of it. I also had the same problem before with my old 2080ti. To test this on your end you can simply lower every setting that needs plenty of VRAM (render resolution with PD setting, visibility range, low textures, lower or 100% SS settings). If the problem still persists than the reason is something else. A friend of mine just ran into the same problem yesterday on a 1070, we just tested the unlock all liveries mod on our syria server with all modules available and his VRAM just filled up too much, FPS were going down, F10 map troubles. He had to restart the game without the mod to fix it.

That's because windows uses the pagefile also to cache video memory to RAM and HD. It's called shared GPU memory. The performance impact comes when dedicated VRAM is full and a lot of additional HD activity is needed to constantly load stuff from the cache back to VRAM. If the amount of data is small, you may not notice any impact. If it starts to need bigger chunks of data to swap, the trouble starts.

@FritzTheGerman unfortunately, the ingame PD setting does not work as intended by SteamVR and other VR compositors. It's actually working like the setting for monitor resolution in 2D mode. In a VR game the VR compositor and the connected HMD with it's driver define the standard resolution for both frames that have to be rendered (left and right eye). As an example with a Valve Index, 2016 x 2240 pixels per panel is the minimum needed to display a lens distortion corrected frame pixel perfect on each 1440 × 1600 pixels panel. If you set ingame PD 1.0, the game will deliver a 1:1 frame at 2016x2240 to the VR compositor that will do it's job with handling all the necessary steps to transform the correct distortion for your HMD. If you set a higher PD, the game will render a higher resolution frame. With 1.8 PD you will end up with 3628 x 4032 per eye in the first step, which is crazy high, takes a much bigger screen buffer in VRAM and will also cost CPU performance, because all CPU bound visual passes have to process a much higher amount of information. The next step is downsampling both 3628x4032 frames to 2016x2240 for the VR compositor, which is doing his distortion pass and if you set a higher resolution percentage will do another supersampling pass on top. A huge waste of performance. To get the most out of visuals in VR in DCS, never use the ingame PD, it will kill your frametimes on CPU and GPU instantly. Go for 1.0 and let the VR compositor handle it's SS passes afterwards. This way you can balance the CPU bound scenario, because 99% of the VR compositor workload goes directly to GPU usage. And there is plenty of headroom there with a 3090. In Steam VR you have the advantage of adding a second "per app" setting for supersampling to finetune GPU usage to the max. The formula is DCS PD x SteamVR general SS setting x Steam VR per app SS setting.

Well it's been 4 years, i really hope someone starts to care someday.

Did you read what that video is about? Or is the Gazelle module actually an Rotorway Turbo under the hood? Here is the same guy in the Gazelle, look at his inputs: Look how it looks like when it lifts off, not straight up in the air, like pulled up on a cable. It's unstable like any other helicopter as soon the skids loose ground contact. Why do we not see that in DCS?

@outlawal2 Yes, that's why you have to work on the cyclic in the real Gazelle all the time. Like this: From the outside it will look very stable, that's what some people don't get. @swatstar98 I count 7 seconds without correcting.

@borchi_2b Will it also fix the totally overdone sensitivity of the cyclic? Will it also fix the continous roll behaviour with just a bit of left or right cyclic input that makes it fly like a plane with wings and ailerons? Why didn't that irritate you at all over the years? @swatstar98 Come on, 5 seconds with no hands. And you can see how the airframe is actually working against air resistance. Ridiculous to bring that here...

@f4l0 Hi, thanks for adding the A-10 II so quickly. Any chance that you'll look into the support for the Edge 540 and A-4E? Both community modules frequently crash Simshaker. I don't know how they manage telemetry data, maybe a simple ignore feature would be a quick fix. Edit: just found out that the P-47 also crashes simshaker. ED added some more variants with the latest patches.

You know that you are wrong if you take facts as personal attacks. You show that you are even more wrong if your only way of answering is personal attacks.

Ah, good find. Thanks.

I'm pretty sure most people who come here know exactly what this is about. Statistically we crossed the 10 participants line which did already hold the 60/40 ratio and now we are about reaching 100 participants with the same outcome, which becomes relevant to extrapolate an even more precise overview. A quality product will always show more than 95% happy existing and future customers.

You seem to have missed some lessons in business school, an around 60% vs 40% ratio is a pretty bad outcome for a product survey. This is not a vote where a majority of 51% wins. It simply shows that a product/company has serious issues and drastic steps + huge efforts are needed to fix the situation.

@Stal2k Just to make sure, i already stated that i had the same problem. More VRAM solved the issue for me without changing any other setting (instead i can go higher now). I know this isn't the answer you want to hear. I basically followed the same procedure with setting additional SS to invest more GPU usage because my 2080ti was bored at around 60% usage. But for a long time i didn't mind that this also takes a higher impact on VRAM usage and lead to video memory overflow and VRAM to disk caching (which looks like to be the source of the problem).

Yep, 1000W works fine with raised powerlimits for an overclocked CPU in combo with a hungry 3090.

Edit: Ok, found the time to get deeper into this. VR renders 2 cameras at a given resolution (DCS's integrated openVR or oculus api looks for the installed Headset driver/compositor, sets it's default resolution for each panel), DCS's internal PD value gives the option of a render resolution multiplicator per eye (1.0 recommended for all HMD's except Oculus's api, here the PD value hooks directly into the PD value of it's api). A rendered finished frame per eye is handed over by DCS to the VR compositor (Steam VR for example). The compositor handles another render resolution pass per eye and sends it to each of your display panels in your HMD (Steam VR SS setting). If you have a VR HMD connected to your GPU, it's technically like having 2 additional monitors connected, therefore the GPU needs to allocate extra separate screenbuffers, one for the left eye, one for the right eye. Every pixel needs to be drawn and saved somewhere, this is what screenbuffers are allocated for. The VR mirror on your desktop however, can be just a copy of the left or the right eye, or an extra camera centered between each eyes. I can't tell which way DCS is going here. However, the VR mirror on the desktop needs to draw an additonal window on your desktop, this window is filled with extra pixels that get copied(!) from one of the VR screenbuffers to the screenbuffer of your monitor and adds usage of VRAM for the screenbuffer of your monitor which is displaying the VR mirror (not that much, the mirror is mostly a fraction of HMD panel resolution, but still something). This is basic windows api stuff. The higher the resolution you set per PD value ingame and/or SteamVR SS the more VRAM needs to be allocated to be able to render each eye's frame to the panels in your HMD. Have a nice day.