edmuss

I don't think it's your problem exactly but altering the world scale in openxr toolkit before has caused stepped edges (could be described as waves?) on the sides of the kneeboard before when reprojection is enabled. I'm fairly certain that there is a world scale option in steamvr, might be worth checking it's set to default as it might be causing the same issue. Using the DCS IPD (world scale) setting correctly changes the size of the cockpit around you without causing corruption of the kneeboard edges. The numbers tie up between the DCS setting and the openxr setting - I use 44mm for both (IPD is actually about 63.5) as that gives the best scaling based off my hotas size/MFD position.

Quick sanity check, you do have the latest version of toolkit installed? I think it's 1.2.4 off the top of my head. Might be worth while uninstalling and reinstalling it again to make sure that something hasn't been left behind that shouldn't have

Have you actually tried doing what I suggested? As in trigger a complete restore defaults settings from safe mode. There is some oddity in the interaction between toolkit and the two versions of DCS.exe (openvr and openxr) that causes the toolkit to lock up when loading a mission. Quick and easy test is simply to set toolkit to safe mode or disabled it and see if it loads as expected.

Possible long shot.... You say you've run open composite since running native openxr, have you subsequently reset openxr toolkit to default and the set it up again when switching back to native? With the native switches active, try setting toolkit to safe mode, starting DCS and resetting options to default from the in-game menu. Close DCS, disable safe mode and fire up DCS again.

Yeah, much better than my attempt

The definition of CPU bound can be interpreted a number of ways in DCS VR, my take on it (from a VR performance perspective) is if the CPU is taking longer to composite the render than it is the GPU. This will manifest in the CPU frametime being higher then the GPU and the resultant fps being below the indicated GPU frametime. This is of course not taking into account additional CPU load such as AI, mission scripts and simply the current single threaded nature of DCS. I upgraded from a 3600@4.3ghz / 3070 to my current rig of 5800x3D / 3080ti in two stages, first the CPU then the GPU. My experience was that simply changing the CPU resulted in 25% performance across the board, this was from a GPU that was running at 95% load beforehand and in free flight missions. I had never been CPU bound (by my definition above) in a free flight mission, yet the upgrade made a massive difference; this was very suprising as I was only expecting a few % at best. Upgrading the GPU was from a desire to be able to run higher settings with better framerates (and the lad desperately needed a GPU upgrade for his birthday so he got the 3070 and I was wife sanctioned to buy myself a new GPU ). I believe that you will see a significant increase by going to a newer CPU, even if it's a 5800x3D and stick with the 3080ti. With tweaking and setup I can get 8-15ms GPU frametimes on Syria with generally high settings, MSAAx2 and shadows on high/flat. With the release of the DLSS I believe that this performance will improve as it should give a better image then the current NIS upscaling that I'm utilising. Go for the CPU, if you can push budget for ryzen 7xxx and DDR5 then that will future proof you but I suspect (and hope) that the 5800x3D/3080ti combo has some legs left for DCS yet

I'm now achieving much better CPU times thanks to @MoleUK and his suggestion to reduce object draw distance by 20km. Now getting 60+ fps over farp London with fairly high settings

That's correct, one of these lever blades give or take

There are no dampers on the stick, just the friction clamps holding the axis in place. It's purely mechanical friction, no hydraulic component now. The compression springs in the lock keep the friction clamps pushed onto the rod and pulling the lever pulls them off edit: I may have confused you my mentioning the hydraulic brake lever. I've only used the actual lever blade, it's from a magura HS33 from the mid 90s

edit 01/05/2023: Updated this with a new mechanism and a stupid long extension, because, well why not? See post down below [Original Post] In an effort to make the DCS rotary wing experience a little more authentic (within reason) I wanted to make my warthog stick behave more like a cyclic and be able to use the without spring stick option. Thereby when you release the stick it stays where it is. In addition to this I also wanted it to be able to be used as a conventional joystick which returns to centre without having to spend any time reconfiguring it all Having picked up a 3D printer at Christmas I set about solidworks trying to devise a mechanism that would work. Design constraints being that it has to fit my warthog stick with its 75mm extension, be self contained to the stick alone and still fit onto the quick release stick socket that I have on my chair. My initial plan was to attempt to utilise a pair of small motorcycle steering dampers to control the two axis and give a non-centring stick, I prototyped this and whilst it achieved the goal, they proved too stiff to realistically use. Fast stick movements were impossible and the friction force was sufficient to actually lift the warthog stick off its gimbal and give very exciting results whilst flying; in addition there wasn't a quick and neat solution for disengaging the dampers. I had the dampers set up in a parallel system and the differential movement between both controlled the motion in both axis simultaneously. Video Link I then set about designing a friction damper that could then be disengaged with a lever mechanism, I'm a cyclist as well so I have metres of spare brake cables so I figured that a bowden cable actuated cam would work. Using an old magura hydraulic brake lever that I had in a spare parts box I worked out the ergonomics of fitting it to the stick handle. Modelled up the joystick and lever and placed the pivot it in the right approximate place; designed a bracket for it and sent it to the printer. Decided to make it a 2 part clamp that would sit on the narrow shaft of the stick and support the handle (a known weak point on the warthog stick) In addition to being a mechanical axis trimming device I also wanted it to be able to activate the trim systems in DCS, this would mean adding some switches to the lever. So I added 4 extra ones for good measure I had an existing USB controller board with 16 spare inputs so I didn't have to purchase any extra hardware, just connect the wires. With the trim input side of things manifest, I turned to the physical locking of the axes themselves. Initially I prototyped an eccentric cam mechanism that clamped against a steel through rod but I struggled to overcome cable drag whilst providing enough spring tension to give the friction needed to lock the axis in place. I had also designed in the same package format as the damper prototype (two parallel mechanisms) but there simply wasn't enough holding force to keep it steady in the roll axis. I changed tack and redesigned it to be one lock attached to each axis and work on a sprung plunger appling friction to the through rod rather than the eccentric cam. Pulling the lever would pull the plunger off the through rod against the spring, releasing the lever would clamp the through rod up again. Printed a mounting ring to fit the warthog base and a lock mechanism along with a 2-1 cable splitter and it looked a bit like this.... By and large it worked pretty nicely from a mechanical standpoint, still no electronics but proof of concept was good Found that the 3D printed cable splitter wasn't man enough to take the M6 threads for the barrel adjusters so iterated the design to have aluminium blocks at each end to take the threads and loads from the cables. Ammended the lock design to incorporate an over centre cam toggle that can be used to push the plunger off the rod and effectively free the stick up again for fixed wing use - takes about 5-10 seconds to convert which is perfect. Screencap of the model with transparency to show the workings. Wired up the switches with a length of repurposed cat5 ethernet and all buttons work nicely. Final solidworks design looks like this... The final design works a bit like this Video shows the stick unlocked (the stick is already quite well self damped/weighted) and has never returned to centre with a quick action, engage the locks and it's solid; it is still possible to get the locks to slip if you put enough force in. Because the warthog spring is still in the gimbal it still finds it's own centre and it's easy to recentre the trim in operation. The through rods need to be cut down by about 100mm but they currently don't get in the way so it's not a major issue. Flying helos now is so much smoother because there is no cumulative cyclic error if you don't get it back to centre at the right time, simply pull the lever and it smoothly transistions movement as you move the stick. Added bonus, I also have a 4 button box attached to the stick that I can use for map and view functions without having to dual bind other controls Apologies for the slightly long post! TL:DR I stopped my warthog stick returning to centre

Thanks for the response, I think the multi threading update will go a long way to alleviating the CPU issue. As long as it's not something that I'm doing terribly wrong then that's ok! It's perfectly playable, I'm just a sucker for keeping the FPS above 60Hz refresh rate for the ultimate in smooth flying Skipping the missions from the radio menu is no issue, again just making sure I wasn't missing something obvious. A filter based on airframe would be cool but it's by no means a necessity. It was BV59 (in briefing) and CV59 (coords location) that was mixed up. I should have checked one against the other but person learned. If it's only a typo then hopefully it's easy enough to sort

Currently yes, native openxr support hasn't been rolled out to stable branch yet. You can continue to use open composite if you still want to stay on stable

Recently started playing this in SP, got a couple of queries if you will CPU frametimes are typically in the 18-20ms range, this significantly affects VR play because it's dragging the GPU frametimes down. Short of waiting for the multithreading update or running it on a seperate server instance is there anything I can do to alleviate this? I'm shooting for <16ms at all times to keep the headset above refresh rate. I'm primarily flying the KA50 and a lot of the mission targets are 150+km away, is there any way to filter for closer targets for rotary wing? Easy enough to simply discard the mission of course if not. In an instance last night the mission briefing stated grid square BV59 which was nice and close to farp london, pinged the coords into the PVI800 and set route mode to autopilot there, got to the grid searched for an hour or so and found no misison targets. Eventually gave up after eating a bunch of SAMs and went back to check the coords on the F10 map (should have done that beforehand really!). The target grid square should have been CV59 not BV59 Largely user error on my behalf, I'm trying to get more familiar with navigation and flight planning in the shark so not having it written out by the mission forces me to do the legwork. Loving the missions so far

@X_legio Have you started DCS with the toolkit in safemode and reset all of the options to default (from the ingame menu)? If you don't do this it can carry over some settings from the old open composite DCS.exe profile which causes issues. Because the DCS.exe hasn't changed name, the toolkit appears to share settings between the two. In my case it would generally load into the main menu ok but hang whilst loading a mission. The workflow is: - Enable openxr toolkit safe mode in the companion app. Start DCS, you will be greeted with the Ctrl+F menu prompt. Navigate the menus to find the option to Restore Defaults. Close DCS. Disable openxr toolkit safe mode in the companion app. Restart DCS and you should have a clean and fresh profile loaded up that you need to re-input your settings. Try the above and see if you get anywhere

I'm currently getting pretty good performance with my 3080ti, GPU frametimes around 13ms on Syria. Running 60hz on the G2 so really smooth.

Sounds like you have reprojection enabled. In steamvr it will have been disengaged because you're below half refresh rate. In openxr it will reproject to lower fractions of refresh rate. For more reading have a look through the first page of my running guide on this forum. Is the view smooth and the framerate stable at 22fps? Keeping an eye on GPU frametime is a better indication of performance than the FPS counter.

The answer is quite literally on the first page of this forum

You don't need to do anything with open composite, native openxr DCS is seen as a new executable by openxr toolkit so just add the necessary shortcut command line switches and it will pick up from there If it doesn't start up straight away then you might need to start toolkit in safe mode, start up DCS and restore defaults on the ingame menu. Close DCS, turn off safe mode and it should work properly; just got to set up your options again. If you get rid of the command line switches then DCS will open via opencomposite again.

Reprojection is handled by the video encoder, I think this is why nvidia is generally faster than amd because of the stronger performance of NVENC. I would guess that there is some interaction between the two that is not sharing resources nicely?

Basically we need HP to open source the G2 and someone to switch the lenses to pancakes and figure the correct distortions

According to the somnium devs they're looking at Q2 this year for the first releases I had seen the price of the meganex, I think for that much I'd rather get the aero as it's more mature. My hope for the somnium is that it's possible to print the large majority of the components and buy a kit of parts for what you need. For example if you could customise it so there's no hand tracking module (already got a leap) and no eye tracking to reduce costs then that would be a bonus.

I'm intrigued by the somnium VR1 and the meganex, however I suspect that both are going to be a fair chunk more than the G2

Until some reliable testing is done with the 4070ti in DCS VR I would go 3090 or 3080ti over 4070ti unless you're set on utilising DLSS3 which VR doesn't use. I can pull 60-100 fps with my setup with high/medium settings.

Interestingly enough on the back of this thread I had a play around with the field of view, using the simple setting didn't achieve anything, as soon as it dropped below 100% I could see a black border all around. However, it would appear that in my case, DCS was rendering outside of the headset to the right side of the right hand display. Tweaked each of the settings as you described and ended up pulling the right/right in to around 88%. Upshot of this is it has lost a bit of GPU framtime to the tune of about 0.2-0.4ms I think, not signficant but it's all additive and helps Made no noticable difference to clarity or image quality though. FWIW I set world scale in DCS rather than in openxr toolkit as there was a bug in toolkit that caused corruption of openkneeboard. Might be worth tweaking the advanced FOV settings and seeing if you see any GPU frametime delta switching from simple to advanced and back again.

Can't comment on the cockpit shadows, I'll see if I can get any correlation but I think the difference in performance is likely not massive. Tracking issues on the G2 in a particular area is normally due to a lack of things for it to track. Have you got the same physical arrangement of things in the area that it struggles to track? Tidying up is bad Turbo has been around since November, it has situational benefits but no real world downsides that I've seen reported. With it off, keep an eye on you GPU frametime in comparison to your FPS; if you see a disparage between the two (FPS being lower than your frametime says it should be) then turbo would be recovering those lost FPS.