edmuss

It's far more stable and less liable to upset these days, but back when this thread was created it was easy to make it fall over with a simple thing being out of place. You've been lucky in that it worked first time, however if it hadn't and then you go and ask the devs why it's not working they then stop developing and troubleshoot it for you. Imagine that 10,000 times over (this is used for MSFS, DCS, AC, AMS2, DR2 and a whole bunch of other sims) and you can see what's going to happen. The cleaning and resetting of DCS was to give a known stable foundation on which to run open composite

It's an actual reading of the amount of VRAM used, 6gb is all you're using. @wjuYou will likely see a significant uplift going to a 5800x3D, I saw 25-30% with my 3070 and 3600@4.3ghz; it will really unlock your GPU. Whether it's worth the cost Vs 7xxx Ryzen is up to you, there's no future proofing or real upgrade path going to an AM4 build now.

Roughly the same end result (synthetic frames to give a false framerate with the potential of associated artifacts from guessed frames being injected) but a different mechanism to achieve it

Isn't the DLSS 3 basically reprojection for non-VR?

Ah yes, had read about the issue in discord, thinking about it! Thanks for the clarification

Fixed foveated rendering has been working almost since the inception of using openxr toolkit with open composite in DCS, however this topic is about true foveated rendering which is only available with an eye tracking headset. Now I know that the fixed foveated doesn't work on AMD cards unless it's in DX12 (so not in DCS then) but I don't think this proposed code change would specifically allow AMD cards to use the functionality. You can achieve some good performance increases but at the cost of visual clarity, I typically see 1-1.5ms reduction in appGPU with it on quality/wide preset with almost imperceptible loss of image quality; I don't care for any more than that as I find the constant aliasing on the periphery distracting.

Don't forget that this is primarily to enable eye tracked foveated rendering to work in DCS*, not to enable specifically integration of openxr into DCS. Now I don't know how many pilots here have an eye tracking headset (aero/G2 omnicept/pimax would be most common I guess?) but I would hazard a guess that most of us don't have the capacity for eye tracking. That's not to say that other functionality in openxr couldn't potentially be leveraged from the changes outlined in this thread. For me it's going to make zero difference with regards to the foveated render, if it gives improvements in reprojection artifacting for example then it's a far more positive benefit for a wider range of users. Frustrating that a theoretically relatively simple code change hasn't been implemented yet? Yes, but it also isn't the end of the world given the small demographic that it will help directly; I would rather time is focused on the move to better multithreading and away from the DX11 limitations of the engine - this will help us all edit: *if there are other wider implications on openxr performance improvements in DCS then perhaps yes it should have more time.

I think it's moreso that a new modern engine will not only be able to leverage more CPU cores (to allow the simulation to do more work before saturating the CPU) but alleviate the DX11 draw call limitation which is what I understand to be the major GPU bottleneck of the current engine.

I suspect that this one would be best answered by @mbucchia

@Baldrick33 pointed me at joy2key to do almost this exact thing, it took a bit of jiggling but I can now slew my mouse cursor around using the warthog throttle slew + modifier. The cursor is slaved to the headset but I can alter its resting position using the slew+modifier; mouse button controls are bound to the warthog CMS switch + modifier. I needed to bind the slew axis + modifier in DCS to be a redundant axis (zoom commands I think I used) to stop it slewing the TGP/shkval when I moved the mouse.

K6-2 333 with 16mb ram and a PCI* Nvidia Riva TNT here, saw me through many sleepless nights at uni playing Colin McRae, Thief and rainbow six *No AGP slot on the motherboard!

My understanding is that if WMR isn't the current openxr runtime then open composite won't be able to hook into it because openvr (steamvr) will be the current runtime and it will effectively simply default to running in steamvr. You're using pimaxXR though but I think it all works in the same manner?

Well openxr isn't your active runtime, that would be a starting point

I think there are always small tweaks being done in the background. Nothing is ever documented in the patch notes but it's gradually getting better all the time. With my stick dampers fitted I need to have the option for the right hand to control the virtual stick. My previous experience of using this setting has been terrible because as soon as the glove got near the grip it would snap on and then any further hand movement would move the virtual stick and apply input as such (whilst also taking control input from the physical stick). It generally resulted in a complete loss of control. During my brief testing last night I couldn't get the gloves to grab the virtual stick at all so I guess the functionality has been tweaked. It's quite possible that the gloves interacting with the virtual hotas has actually been disabled all together and now it's a case of hide the hands with control input; just the options haven't been relabelled as such. In a way this is a better setup because whilst it's cool using just your hands on a virtual hotas you have no ability to press any of the hotas buttons which sort of defeats the objective of having a hotas in the first place

That was what I figured as well, it's a whole different animal to fly with the dampers on. Still got to tweak a few bits and pieces as the damping is possibly a little heavy right now, also when pitching down because the dampers are so stiff it tends to lift the gimbal ball on the warthog which gives some rather interesting inputs Simple enough to counter, just need to apply a little downward force on the stick as well as forward.

Perfect! I would make the assumption that the shark would follow the hind control philosophy. I'll obviously not get the return to trim centre action with a FFB base but my 20 quid damper rig up is a lot cheaper In other words I should keep pressing the trim button as per before but now there's no requirement to return the stick to centre.

I've just added dampers to my stick so it behaves as a cyclic and doesn't centre itself, the only problem with that is the right hand is almost constantly hidden because the stick is never centralised. As a test I turned in hand to use control stick (which keeps the hands visible all the time) and it doesn't seem to be grabbing the virtual stick like it used to. Perhaps something to try?

I've just added some axis dampers to my warthog stick so that it behaves correctly as a cyclic, the stick holds wherever you leave it. I've set the options to be a spring less non FFB stick and it behaves as expected in the sim. The stick is now really quite heavy (guessing about 3-4 kg force) but with the dampers it makes the shark really easy to keep stable, even with all autopilot channels off. You just need to preempt any full deflection stick movements and allow an extra fraction of a second to force the dampers through (or put much more force into the stick). My question is, does the trim/trim reset button in the real KA50 exist or is it a workaround by ED to account for centring joysticks? Should I still be pressing and holding the trim button whilst manoeuvring with the cyclic?

I think it's more to alleviate the reprojection artifacts associated with openxr and helo rotors, could be wrong though

@BIGNEWYdo you know if it's possible to edit the configuration of the leap motion via lua or similar? I want to know if it's possible to disable the leap hands being turned off when stick input is applied. Reason for asking is that I've just added a set of dampers to my warthog so that it acts as a non-centring stick for better use in the ka50, however I've a feeling that this will essentially break the leap motion for the right hand

I'm using a G2 and separate leap motion. You might be surprised about the monitor, I don't think they reflect that much IR. The big one for me was wooden surfaces of my desk and the wall. Generally it will be close surfaces that reflect the light.

The leap hands will turn off if you put in a stick or throttle input, typically the right hand will be hidden more though. Try setting a dead zone for the stick, quite often the centre point still registers enough of an input to hide the hands. For erratic tracking you need to have a clearly defined hand outline for it to keep track. If surfaces behind your hands are reflecting too much of the IR light then it will prevent ultraleap from tracking. I used self adhesive closed cell foam sheet to absorb the IR light and it tracks perfectly. Look in the visualiser and look for white surfaces, these are what you want to get rid of.

I guess a lot of people have realised that it still pulls it's weight even against the top end 7xxx CPUs so make sense to upgrade only the CPU on their AM4 system rather than splash out on all new. Will probably change when the 7x3D come out.

I used heaven benchmark to do exactly that, it's DX11 so a pretty good analogue for DCS but more repeatable and easy to record/tweak/set. Over a couple of hours of benching I got the sweet spot of 875mv with a core offset enough to hold 1860ish boost clocks and +1200 on the VRAM. Even if I ramped the voltage right up it still couldn't hold the boost much higher so save the heat, energy and noise and it's a nice consistent high clock.

Because it can't inject into the vr compositor probably. What is it you're wanting to check?