edmuss

Basically: - appCPU = CPU time taken in ms to render the image appGPU = GPU time taken in ms to render the image postCPU = CPU time taken in ms for post processing (sharpening/colours/reprojection/FFR) postGPU = GPU time taken in ms for post processing (sharpening/colours/reprojection/FFR) If appGPU is less than appCPU then you are CPU bound and adjusting graphics options will make little difference to performance. If appGPU is more than appCPU then you are GPU bound and adjusting graphics options will make more difference to performance. When running without reprojection, postGPU is typically <0.5ms, with reprojection this is typically aroun 3-4ms (for my machine). Working on the assumption that you are GPU bound (which is where you want to be) adjust your options to achieve the target frametime that you want, this should give the optimum image quality for the given performance. Everyones VR experience is different so what works for me may not work for you. When running reprojection your fps will always show as whichever refresh target it's running at (1/2, 1/3, 1/4 of refresh rate) but the appGPU frametimes will give a more accurate indication of performance. Calculate you fps by using 1000/frametime, therefore 1000/11ms = 90fps, 1000/16ms = 60 fps, 1000/22ms = 45 fps. When using reprojection you need to, at minimum, achieve the refresh target to keep it enabled, to do so both appGPU and postGPU should be combined and the result compared to the refresh target. For example if you have 17ms appGPU and 3.5ms postGPU your total GPU frametime is 20.5ms; this is less than the 22ms for a 45Hz refresh target so reprojection will stay enabled. With openxr toolkit the reprojection is able to step down to the next fraction of the headset refresh rate, this is 30Hz (and subsequently 22Hz) with a 90Hz headset refresh, this does mean that you can actually tune to achieve the 30Hz refresh target and you can wind the settings up.

The upscaler has given me about 15fps more at 150%, when I've tested it. I don't think you're getting the GPU performance that you should be. Turn off reprojection entirely and see what appgpu frametimes and fps you're getting. Test in a free flight mission so you've not got CPU scripts dragging it down and see what you get. A10C free flight over Caucasus I get around 70 fps with 100% resolution on the G2, high textures, low/flat shadows abs no MSAA. There are reports of AMD drivers since may last year breaking reprojection, could be that's your issue?

I'm not too sure what the target missed means, it might be a dropped frame? Not seen it myself. edit: target frame missed might be because you've locked reprojection to 45hz but you're not achieving it. If you turn on the openxr tools performance overlay, that will tell you appcpu and appgpu frametimes, these are essentially the time taken by your CPU and GPU to render the image. 11ms is 90fps, 16ms is 60fps, 22ms is 45fps (1000/frametime= fps) This will give you a judge of what fps your achieving when MR is locking the fps to 45 (fps counters can't record the fps when reprojection is active but the frametimes will give you an idea). If you have smooth image and adequate performance to keep reprojection running then there's no need to upscale it's purely there for performance reasons. If you have 13ms frametimes for example you have loads of headroom to increase settings

One more reply?

From what I understand, ED have released the tools to integrate leap into the clickable cockpit but I think none of the 3rd part devs have made the leap(!) yet. It's perfectly useable once you've figured out the foibles but the current implementation could be better, I would say it's about 85% there though. I have noticed small improvements over the last few OBs so I think it's still in progress

Nothing noticable There's a pinned thread in the input devices forum, have a read through that before you buy one (unless you find one for 30 quid on eBay like I did) as there are quite a lot of hoops to jump through before it's right.

Leap user here as well, there are some niggles but by and large it works really well once it's setup properly. Push buttons and toggle switches work really well, rotaries work but can be a bit trickier. A lot of it is muscle memory but I'm now generally faster with leap motion than I am grabbing the mouse and getting the cursor onto the control and then clicking. I bind mouse controls to my hotas (warthog pinky paddle switch as a modifier for the CMS switch) so I can still click buttons that don't play nice with the leap.

Honestly don't punish yourself running >100% resolution on the G2 until you finished running and find you have spare GPU capacity. The direction you upscale doesn't actually matter (the render resolution that it upscales from is displayed in brackets), I honestly don't know why the upscaler doesn't work like vrperfkit does whereby above 100% it starts supersampling. MR default use is only to be used with MSFS, it will be disbanded for anything else at the moment. Don't worry too much about the VRAM capacity and resolution thing, with 16gb you should be running at 100% for the G2 (3160 pixels wide). For reference, my 8gb 3070 gives a recommended resolution of 2480 wide, if I use this in DCS I can actually get very close to 90fps. I think a 10gb 3080 defaults to about 3050 wide. Naturally there is nothing stopping you running higher than the default, personally I chose to run a higher resolution and no MSAA because the MSAA performance in DCS is so poor. For information in a simple nutshell, as far as I'm aware a VR image is comprised of the left eye frame buffer, right eye frame buffer and back buffer (for depth perception I think). Think of each of them as a different monitor that you have to display a slightly different image on, the three are then stitched together to give the stereoscopic image we see in the headset. Each image takes a certain amount of VRAM, the higher the resolution the more it takes, adding MSAA on increases the memory usage. Openxr tools calculates that the three back buffers with MSAA x4 applied should be no more than 10% of VRAM, if you have 8gb (8192mb) then openxr will recommend to not use more than 819mb for the frame buffers, the rest of the VRAM can then be used for textures etc.

Start at 100% resolution, to try to push 150 on a G2 is pretty mental The upscaling works by the upscale ratio being greater the further away from 100% you get (in both directions). Confusing I know! By switching from 150 to 75 I think you've actually inadvertantly reduced the upscaling ratio. Have you read through my running guide for open composite? I'm on Thuds discord and happy to answer in there

I would leave the reprojection unlocked, otherwise what you're doing it from dropping down to the 30Hz bracket if required. Similarly I would unlock the framerate, if you lock to 45fps then it may never reproject in the 45Hz bracket because of reprojection overheads, if you're going to lock it then I would suggest a mid to high 50s would be better. Custom render is the same as monitor resolution (except on OXRTK it can be adjusted by the pixel instead of fixed steps), increase the render resolution to improve image quality (to a point) at the cost of performance and vice versa. The G2 has a native 100% render resolution of 3160 pixels wide. Note that custom render can be set via the openxr tools desktop app as a global resolution or in an app by app basis via the OXRTK in-game menu on the system tab - they both do the same thing but the OXRTK option has more granular control. Upscale resolution is a factor of how much the selected upscaler works. For example set it to 50% and it will render the image at half resolution and then by using magic scale it back up to full resolution. This process is more efficient than rendering the image at full resolution so can save a bunch of performance, however it does introduce a fair amount of shimmer in DCS. Personally I prefer to leave it off and make adjustments elsewhere up make up for the performance. OXRTK world scale is effectively an IPD adjustment and simulates the changing width of your eyes. The effect of which is that everything looks smaller as you increase it and vice versa. It has no real effect on performance. With regards to jagged planes, that might be a function of your render resolution. For best clarity run the headset at 100% or above, MSAA will smooth edges out at a massive performance hit but I find makes things a little blurry. Sharpening can be added as part of the upscaler tools but it adds additional shimmer in DCS (as above my preference is not too use it). Personally I tend to be looking at the ground (A10 & KA50) so I couldn't tell you if I get jagged rear aspect planes, it could simply be the pixels trying to render the thin wings. Out of interest, have you set a custom render resolution (in the desktop or in-game)? If you haven't then check the second tab of the desktop openxr tools and that will tell you the current resolution. It calculates the default recommended resolution based upon your VRAM capacity, the three back buffers with MSAA x4 applied should be no more than 10% of available VRAM. If you've left it default then it may be running at less than 100% which could cause a more jaggy image.

I'm not sure on the specifics, it should be a case of run the switcher and then set oculus to use steamvr. I think it's possible to get the openxr toolkit to work with the quest as well. Might be worthwhile having a search of the Openxr thread as there are people who have implemented it on there, alternatively have a search of the discord channel.

I don't think you're wrong, there's too much CPU dependency to keep the GPU running at full refresh rate. I that bigger GPUs at those point are just going to allow for higher settings but no more performance. edit: as a test I reverted back to steamvr again, like for like settings, lost about 5-10 fps, a bunch of clarity and GPU frametimes were no where near as stable. A10C easy instant action - steamvr 50-60 fps with frametimes jumping quite violently from 16 to 18 - open composite 60-70 fps with stable frametimes from 14-16.

I think it's no longer part of the DCS install and it uses the system installed version. Even if you repair it I don't think it will return Everyone should be helpful at least once in their lives

Yeah 60 isn't for everyone. You're very close, have you tweaked resolution and played with FFR and upscaling? It's difficult with DCS because to keep the CPU times below 90Hz is very difficult with any significant load.

Assuming you used the global switcher then it's simply a case of switching it back to steamvr. If not then you'll have to remove the necessary additional files and repair DCS.

Reprojection works by guessing where the headset is going to be relative to the last couple of frames, generates a synthetic frame and inserts it in between the other frames to make it feel like you're achieving refresh rate; the guessed frames are why you get reprojection artifacts and distortion. I think it's proven much harder to get right with openxr because of how the render times the frames being pushed to the headset in relation to the headset position - I'm not intimately familiar with the whole ins and outs but it's not an easy fix to get it as good as steamvr. There is a computational overhead associated with calculating these synthetic frames which needs to be factored in to the equation as to whether or not you've achieved the refresh rate target you're aiming for (1/2 for steamvr - 1/2, 1/3, 1/4 for openxr). For steamvr I roughly equated it as needing 55% of the refresh rate in order to keep reprojection enabled - it's not exactly 50fps. With the openxr toolkit, because it can reproject at the lower fraction brackets of the refresh rate it means that if you drop below the threshold for 45Hz reprojection it will drop down to 30Hz (1/3) and then in turn down to 22Hz (1/4) before finally disabling; obviously the further from refresh you get you need to have more synthetic frames generated which introduces more artifacts. Roughly with steamvr reprojection:- >90fps = smooth and clear <90fps but >50fps = smooth but with some artifacts <50fps = janky but with no artifacts Roughly with openxr reprojection:- >90fps = smooth and clear <90fps but >50fps = smooth but with some artifacts <50fps but >33fps = smooth but with slightly more artifacts <33fps but >22fps = smooth but with far more artifacts <22fps = super janky but with no artifacts The figures are obviously only nominal but having that safety net of the 30Hz bracket means that unless you're watching the frametimes/counters you'll likely not even notice that it's running at 1/3 of the speed it looks like. If for example your CPU is stopping your GPU from achieving the reprojection fraction brackets then no amount of reprojection is going to help you

Give it a try, you may be suprised, after so long relying on repojection as a crutch I was very leary of not using it when I switched to openxr If your framerate is over >50fps in liberation then you should be laughing, also note that in steamvr, as soon as you're below 50ish fps the reprojection turns itself off anyway. Before open composite / openxr was introduced for DCS I was forced to run in 60Hz mode, reprojecting down to 30fps simply because I couldn't hold enough performance overhead to keep steamvr reprojection enabled at 90Hz.

Reprojection in DCS with openxr is blurry and substandard in comparison to steamvr, it's a terrible shame that it's not been straightened out yet! Have you tried turning reprojection off? If you can pull 55-60 fps @90Hz then it's pretty damn smooth (head rotations are synced but translations aren't - as most head movement is rotational I find it a moot point) but you get zero artifacts and no blurriness. Admittedly this works better for slower movements like helos, fast movers low down can be uncomfortable if you're looking sideways 500 foot off the ground - I'd argue that you should be facing forwards in that situation! I think in simplified terms, the way the openxr render handles vsync is that if you haven't achieved refresh rate it will hold the frame from being sent to the headset until the half refresh rate time, essentially if you're not achieving 90fps it will give you 45fps instead and simply wait so that it can sync the frame up with the headset position. I understand that this is in opposition of how steamvr handles vsync and it just throws the frames out to the headset as soon as they're generated - this is why openxr appears much smoother at lower framerates (without reprojection) than steamvr. Note that whilst the render is being displayed at 45Hz it will show a higher fps counter, I think this is because the actual number is averaged out based on the amount of time the renderer is waiting for the 45Hz vsync. Alternatively if you can stomach 60Hz flicker and can keep above 60fps at all times then you will have perfectly synced image with no artifacts or blurring/ghosting. However, as per the above paragraph, if you miss the 60Hz refresh target then it waits for the 30Hz (half refresh) and it gets really quite uncomfortable. 50fps on 90Hz is far nicer than 50fps on 60Hz. If I can guarantee that I'll keep over 60fps (<16ms frametimes) then I'll happily the G2 run at 60Hz, on Foothold Caucasus for example it's been dropping to just below 60 for extended periods and as such it's far more comfortable at 90Hz; I can keep it above 60fps if I nail the resolution right down to 2400ish (and/or enable FSR) but both come at a significant loss of clarity. Essentially as long as my minimum framerate is >45 (<22ms frametime) then I'm good to go, in fact I've put the G2 resolution back up to 100% because I don't need to mollycoddle the 3070 to get the last 10fps out to keep it above 60 - less shimmering, more clarity and 55fps is fine :)

Haha, I know that there is a slight lag of the leap hands moving in DCS when you move the headset quickly but I've never thought to try to flick switches with it I don't think I would have any problems replicating that, I tend to not wave my head around though when I'm pressing buttons so I've not seen it specifically

If ever I forget to enable the leap motion it feels like I'm missing a limb, get so much immersive enjoyment from just clicking a simple toggle switch. If I had any of the 3rd party modules I would be pushing for the implementation with you! I have little enough time to learn the hog and the shark that I've owned for getting on to 9 years, let alone another hi fidelity module edit: if the small niggles of the base implementation of leap motion could be fixed then I think uptake would be so much more and it would become far more widespread, forcing more requests for the 3rd party devs. If I could help I would but unfortunately it's simply not my skill set (I can design you a sewage treatment plant though )

I would utilise the toolkit, mainly because it allows you to tweak colours/levels/saturation/vibrance etc. in addition to providing FFR (if you fancy and extra 0.5-2 ms gain in performance). Of course if you aren't using any of the functionality of it then you may as well disable it

They're terrible when they climb on your lap, stand on your thighs to reach the steering wheel rim that's hanging and to play cars whilst I'm trying to play helicopters! Oh and also 11pm, I'm sure three year olds should be asleep

It doesn't run steamvr, you just have to tell oculus that you're going to use steamvr (the openvr runtimes) and then open composite hijacks it along the way and bypasses steamvr

I don't know the intricasies of it but I would presume it's about setting up a 3D map of where the buttons are and implementing that into the leap motion API that ED have developed. I guess the only way to get the 3rd party modules setup is if enough people ask the devs for it. Ask the question and it might happen

He's on an i7 6700 so not a lot that will slot in and make much meaningful help I don't think