RealDCSpilot

Uh, that's not good. If the dev build differs too much from the public build. No wonder that crazy problems pop up after every release. However, there are fps improvements in the last couple of beta releases, but you only see them in an empty free flight map. And in VR i need to have "stereo mode use shared parser" enabled, ED should embrace that option much more and iron out it's current weaknesses.

Strange, it's working again. FFB trim implementation is always activated. Must have been a MP issue yesterday.

I used BD 770 DT years ago with my 1st VR-HMD, believe me, you don't want to use headphones anymore after you tried those over-ear BMR speakers of the Index.

Latest 2.5.6 beta here and FFB spring forces aren't enabled anymore on my G940. I only get the rumbles on the runway and vibrations during flight. FFB works as aspected on all other DCS modules.

@memoric https://forums.eagle.ru/showpost.php?p=4289084&postcount=1 sums it up pretty well.

Had the same FPS hit in that mission, in my second attempt i just flew back to the FARP and waited a couple of minutes. In that time the Hinds finish their attack run and FPS come back slightly (but only to 30). I have to watch those trucks more closely next time.

Pretty good summary on the best current gen HMD's. Basically my next headset after the Index should have the same features just with higher FOV and a bit more pixel density.

@BIGNEWY to sum it up, these are the issues i encountered so far: - Frustum Culling FOV seems to be set for 1st gen VR HMD (max 110°) in my Valve Index i can clearly see how objects are switched on and off at the edges of the screens - heatblur post effect renders in one eye only - cockpit lighting, esp. flood lights are rendered in one eye only - cloud shadows (if i'm passing under a cloud) are rendered in one eye only - in some modules, canopy glass internal highlights produce artifacts (z-buffer sorting?)

Yes, it seems to work like an equalizer, those frustum culled hangars don't let the simulation value go crazy anymore. It stays below 20 and seems to be very manageable by the CPU. This shared parser method seems to be ED's version of single pass stereo, a very effective method for VR optimization. Without it, each eye is a separate rendering pass, very costly on CPU/GPU. It should be an option in the VR settings menu and cleaned up by ED. So far i have only troubles with cockpit lighting, heat blur effects and cloud shadows (occasionally).

@Dave317 you will not see any FPS improvement, but the crazy jumps in GPU usage will stop, without it i see drops from 80% to 40%. Enabled it gives me 60% "steady" ...

Tested this for 2 days now and the only stuff that's really annoying is the missing cockpit lighting in one eye (flood lights etc.).

Using "options.graphics.stereo_mode_use_shared_parser = true" in autoexec.cfg has a huge impact on DCS's CPU and GPU usage in VR. It enables View Frustum Culling https://4.bp.blogspot.com/-aEj494GokOg/VvG7kQoY1uI/AAAAAAAAAD8/XF9f7fmXMT0QUoPSKbgab7IIeSLiqgTDQ/s1600/3.jpg I have a very simple test scenario, F/A-18 instant mission "Ready On The Ramp" in the Caucasus map. Start it in VR, just look to the right and then to the left. As soon as the hangars on the left side appear in your fov, CPU and GPU usage drop heavily. The GPU drop is extreme. FPS gets cut in half. Check the graphs in my screenshots (3rd pic is with shared_parser enabled). This goes away completely after enabling shared_parser. However, the culling is very rough and not very well tuned by ED. I can see the objects dropping in and out at the edges of the screens in my HMD, some stuff doesn't get rendered properly in both eyes. And it will not bring back those precious stable 45 fps in 2.5.6 :(

I wonder what those pilots would say if someone cuts their cyclic sticks down to a third of the original length.

Just watched Pavehawker's stream and witnessed his micro movements on the cyclic, not using trim (the Kiowa has a big switch named "Force Trim")... This is Gazelle FM + bad controls all over again...

The 2,5 % means only the CPU usage of the running Lua scripts... Nothing to worry about. The video mem counter is bugged/inoperable.

@HC_Official I just checked real weather info and might have found the problem. On the server it mixes up meter per second with kilometers per hour. This way we always get stuff like 6 meters per second instead of 6 kmh (example sochi: just now). Explains why the wind is always at those high levels. https://en.wikipedia.org/wiki/Beaufort_scale

Question: is the extreme wind setting on purpose? I enjoy training on havoc servers alot, but this always feels a little overkill...

With "simple" i meant the approach of fixing the problem by simply removing assets from the mission. The problem still exists. Just checked the F5E Agressors campaign and the performance gain is only marginal. The initial parking position is changed, but as soon you are facing a couple of the other parked planes, performance starts to drop heavily.

@some1 Just tested this, disabling wake turbulence helps a little, but not that much. As soon the simulation value shoots over 18, frametimes rise extremely and FPS drop hard. Good benchmark scenarios are those WWII bomber formation attack missions.

"Removed unused units and replaced them with static models" I guess that's the simple "fix" for the Aggressors campaign missions. Those parked jets aren't idle AI's anymore.

@Minsky Some issues got fixed yes. The spawning of AI groups in the FPS AI mission doesn't tank performance anymore. But the bomber formation test scenario: https://forums.eagle.ru/showpost.php?p=4243909&postcount=202 still tanks my performance extremely. The simulation value shoots up to over 80 and my frames drop from 45 to 10 or lower.

The game did run very well last year...

Actually it's the other way around, 1 draw call can be one object, a predefined group of objects or just a per pixel color change render pass that adds 33% red on every pixel on the entire screen. Usually a significant number of dynamic objects is used for assembling a interactive 3D world, so the CPU to GPU calls matter especially on objects, because the more are called the more significant their impact will be on performance. Thats why the object count is displayed in the FPS info. About the simulation value, well it's the point of the whole thread that you are missing completely. Again, if you really want to analyze something, check this mission with your fancy graphs: https://forums.eagle.ru/showpost.php?p=4238222&postcount=188 And look for the connection between simulation value and massive increase of frametime.

I recommend reading about particle effects in game engines to understand what you see there. The black smoke uses textures with black pixel clouds at high transparency settings. Currently they seem to use too much particles of it with a costly blending mode to achieve it's visual effect.

@Worrazen If you add DCS's own performance stats with Ctrl+Alt+Pause (twice for full) you might understand what i mean with "number of objects" aka draw calls and "Main: Simulation" etc. it even has a polygon counter. You also may read the whole thread again. If you really want to deeply analyze the problem, check this .miz file: https://forums.eagle.ru/showpost.php?p=4238222&postcount=188 (might be pretty interesting on the graphs!)