lemoen

What is your DCS VR shortcut's command? the --force_oculus option doesn't work with MT I think you need --force_enable_VR

Check in Oculus software if your runtime is set to openxr.

I have a similar problem with the Virpil CM3. When the throttle is in cutoff, it "holds" the cut-off button and releases it the moment you move the throttle forward. Seems to be only an issue in the EE, I have to click the throttle in the cockpit to move it to idle then move my throttle to match.

I'm in VR, away from the airfield it goes to 72fps on my quest2 and stays there mostly as I would expect given the graphical settings I have, but when I'm at the airfield or looking at it like when I come to land, it'll drop to 18fps. I think it has something to do with the shadows bug that is in the current version of DCS, those 6 or 7 planes really shouldn't have that big an effect on the performance.

Anyone else have terrible fps at the airfield? I had to remove the non-player stationary Mirage F1's from the mission which fixed the issue. It was drawing 25-50M triangles with those planes in the mission, without them about 4M

Run a repair.

I have the same, but on mine even more is cut off, can only just see the red arrow above the cutoff.

Some of the missions starts the Helo in a state where the left pedal is trimmed some ways, and full right pedal doesn't give you the full right tail rotor. I've now started hitting the trim reset button as I get into a mission. I'm not using rudder trim.

+1 The situation is getting pretty desperate in VR.

Using up more than 8GB of VRAM at low settings is clearly unwanted behaviour. Maybe the video manager isn't aggressive enough in cleaning out unused stuff, or maybe the art assets have components in them that has too high a resolution, we can only guess but we really should plead with ED to look at this and improve it, because along with that will come increased performance for everybody, even people with 24GB cards.

So it looks like Airlink just uses less resources than default Link settings, but this same thing happens on Airlink too. I had to set everything to low, disable MSAA and reduce the render res to 0.9x to get Blue Flag PG to stay inside my 8GB VRAM. My GPU was running at 40% usage at this point, there is clearly a large divide between the amount of rendering that needs to be done and the amount of memory it uses while doing so. ED please please please look at this excessive VRAM usage.

Good practice for Raduga-Sh sight

After some more testing I found out that when using Airlink, DCS still goes over my allotted VRAM, but the 100% GPU usage and subsequent glitching does not happen in the same scenarios as before, even with higher graphical settings that will use more VRAM. So I suggest for those on Quest 2 with this problem to test Airlink.

OK tried HIGHER settings than before, but with Airlink, same rotorheads server, scenario was similar. Still saw high VRAM numbers but the fps stayed stable and no glitching. I suggest to Quest 2 users to try Airlink instead of link.

I see you're using Airlink and don't have this issue. I wonder if there isn't a difference between that and Link system, where maybe the Airlink stream uses a lot less VRAM to be prepared. In every single case I had this, my total system video memory was clearly over 8GB but at least a few 100mb, and I've just been using Link because for the most part its the same but airlink eats the battery much faster. Some things I can try later...

The massive framerate drop, screen tearing and 100% GPU usage is the VRAM being full and data being swapped into your system RAM. It happens on missions where there are too many unique ground units. If you have a high res VR headset like a Quest 2 and only 8GB of VRAM this will happen unless you really really turn the settings down A LOT. There might be somethings ED can look into that might help, see here for one example.

OK I've tracked this problem down I think. I tested various scenarios at differing settings on my Quest 2 and DCS. I'm running 32GB of RAM and a 8GB 3070. It basically boils down to DCS going over the amount of VRAM available in the system. Settings started as follows: Textures Med, Terrain text, low, shadows med, cockpit displays 512, clouds low, view distance med, terrain shadows flat and the rest was off or low, render res in quest to 1.1x. The first scenario was Blue Flag on Persian Gulf, started at Bandar Abbas, fly to Havadarya in a Huey. When I spawn in the VRAM was teetering on 8GB and as soon as I took off and did a zoom it went over to about 8.5GB on the shared GPU memory and the quest 2 started glitching and the GPU usage shot to 100% for a minute or two then it recovered. However, that still left that translucent white box in the lower 25% of the view which happens on link but not on Airlink. I reduced my rendering resolution to 1.0x from 1.1x and redid the test. Flew from Hava to Abbas no issues. Exited. Turned textures to high, MSAA to 2x. Redid test, once spawned into Huey immediately had the 100% GPU and the thrashing (went to 8.6GB odd). Exited. reduced render res to 0.9x, redid the test, worked OK for a few minutes then the thrashing started again and each time the GPU memory went over 8GB the 100% spike happened, before and after the 100% spike GPU was at 42% usage stable with the last settings. I lowered my render res again, now at 3700x1900 res odd, BF worked fine. Exited, logged into Rotorheads, everything seemed fine, started up the ka50 and took off and about 2 minutes later the thrashing happened again, and again almost 9GB of shared video memory used. I think the 100% GPU usage is some kind of buffer flushing operation that shifts things around between ram and vram because there's too much stuff in the VRAM. I think ED really needs to have a good look at the things that uses so much GPU memory, I don't think it is unreasonable to expect an 8GB card to have more than enough vram at pretty low graphical settings, at a resolution that barely rivals a 4k monitor. There's some indications of easy (as in, could be done in a week or two) fixes that could be made to art assets, see here:

bump.

Same problem for me: Quest 2 link, 3070.

rctrl rshift and numkeys 4 6 2 8 / * moves your head around. ralt num0 saves it.

oh its a mod, I didn't see that this morning (coffee hadn't acted yet).

Hmmm, this is strange. I've been playing the Red Flag campaign, the Phantoms show up as "B" and the Tomcats as "4", Tornados as "T". Did it change again?

ASW ghosts for me in flybys and stuff BUT, if I switch it off, when I move my head side to side in the cockpit, everything ghosts (everything makes a double that is one frame behind), with ASW on it does not, plus it looks like 90, not 45, so it is significantly smoother. I'll take the artifacting (that ghosting). They've changed the shortcut to rctrl pause for the frame rate counter.

If you let VR run at a variable framerate, like with the ctrl num1 option, it might look very stuttery. If you force it to something, say 45 fps in my case with ctrl-num2, its smoother, because the same time passes between frames. If you let ASW work on top of that (ctrl num3 or ctrl num4), then it is locked to 45 fps but the software adds in the in between frames, so it looks like 90 fps, even though DCS is only rendering 45 per second.

Don't be fooled by the framerate. In my experience using the ctrl num1 option that disables the vsync and ASW does lead to higher framerates but they're variable and might look very stuttery. In my case that setting is basically unusable on my Rift CV1. I use the ctrl num4 option almost always, this locks mine to 45 and does the ASW so it looks like 90fps.