edmuss

The hands show up as normal but you can't interact with the fingers, you can use the laser pointers but the click emulation is still really flaky for me (in other words I've not practised it enough).

Yes it does work, however that means that if there is any input on the stick or input delta on the throttle the hands get hidden. This makes the option unusable if you have a non-centing stick (cyclic or FFB) or you hold the stick in position with the left hand to operate the right MFD for example. If the option is removed all together and the hands don't get hidden at all that would be a better solution

I spoke to Dan@ultraleap and he suggested a blackout cloth called Duvetyne to provide a good IR absorbing backdrop, whilst testing different materials I had in stock I discovered that closed cell foam rubber tape shows up perfectly black in the visualiser. I now have a rubber coated desk

Good info thanks, I generally only fly by monitor light so it's largely dark. It's possible I'm just going slightly outside the envelope of the sensor. Might still pick a cheap one up to test

I'm interested to see how the IR emitters help the leap, I get a spot low down, on the right side of my chair where it is a bit flaky (think hind electrical panel where you have to reach down) if I can put an IR flood under the desk pointing in the that area it might help

Because I fly mainly rotary wing and have a non-centring cyclic trim mechanism that holds the stick out of centre I have to have the hands use stick option enabled. I've mounted the leap motion on the top of the headset so that the hands will generally naturally occlude themselves when looking up through the HUD so it's not a problem 99% of the time. I generally still toggle the hands off when not using them.

To fix the right hand dissapearing enable the hand use stick option, it's best to make sure that you turn off the hand when not actively using it though; if you leap hands line up with the virtual stick at the same time your physical hand moves your physical stick much hilarity (and flames and death and terra firma) can ensue

That's a nice and simple way of determining rotation, I dare say it's probably a good deal easier to implement than the thumb/index pinch and twist Would presume that the trigger would be the centre point of the rotary?

Try adjusting the vertical position and tilt of the headset, there's a lot of adjustment and it normally takes a little while to nail it all down perfectly. I only see the warping (most apparent in varjo base grid environment) at the very far bottom peripheral corner, it was much worse when I had the headset too high

I keep leaning forwards into the hind periscope, expecting to see the lens rendered. Would be really nice to be able to do so so another +1

Just tested it, with the leap motion hands you can 100% shadow your instruments. Only tested on the A10 syria free flight but if the sun is glaring off the glass you can raise your hand to shade it

There's a thread about fingers specifically, should come up on the search somewhere

Indeed, I noticed the shadows on the cockpit, in theory they might cast onto the instruments and shade it enough?

Well actually.... I noticed the other week that the leap hands are casting shadows, I don't know how effective they might be at shading the MFDs though, I'll have to have a try!

That's a feature bug of openxr currently, you just need to hit the reset VR centre position once loaded into the hangar Check the bindings, I think it might be in the UI layer for recentre VR headset.

Assuming this is the same issue that plagued WMR reprojection then it was fixed by a WMR openxr runtime change that allocated a portion of VRAM solely for reprojection. DCS was being too aggressive with the VRAM allocation and there wasn't enough left over to reproject. @BIGNEWY if the team are looking into VRAM and reprojection performance loss then this might be worth mentioning. I don't think it was specifically to do with VRAM usage per se, rather the allocation.

The hands will appear and track but you wont be able to use them to actuate controls, this is down to razbam to implement. Unfortunately none of the 3rd party devs have done so yet, possibly due to not having the hardware themselves to test with. For the modules that don't support the touch interaction, you could use the fingers app that combines the leap motion with a finger ring to replicate pointctrl functionality.

I'll try to find something that runs 20-120hz and see how the response from the transducer is. Thanks for the response, it may be that 30 year old transducer is simply knackered or not that good to start with edit: @=Andre= using this I can get a response from the transducer from 13Hz upwards so looks like it should be ok edit again: tested the full range of the transducer now that everyone is awake! 13hz to 2000hz is viable, amp set to maximum and soundcard set to 20%. Perfectly clean signal throughout that range. Shakes the house! Definitely a good way to go for a cheap single transducer setup.

@=Andre= Do different effects use different frequencies and does the brand/range of the transducer affect how the effects are felt? I only have a cheap transducer (cannabilised from an old aura interator vest from the '90s as a test) and I don't know what the frequency range is and the effects feel fairly similar barring the relative strength values. Might I feel more fidelity with a better transducer? Power wise it's fine and I rarely have the settings above 65%.

You must have reprojection (ASW for the quest) on somewhere, if it's stepped from 90 to 45 then it's reprojecting. If you were getting a steady <90>50 fps then that would be showing that reprojection is off. I would have anticipated you being able to achieve 90fps all the time with the quest pro and a 4090 unless it is as you say, the CPU pulling it back.

What FPS are you achieving, with what headset, refresh rate and GPU? Note that if you're using reprojection that will also drop the GPU usage because it's only got to achieve half of the refresh rate.

Nominally..... If the FPS is below refresh rate (say 90) and the GPU is running at 100% then you're GPU bound. If the FPS is below refresh rate (say 90) and the GPU is not running at 100% then you're CPU bound. If you have GPU overhead (you're beating refresh rate) then your GPU will be idling so may show <100% load, this is your ideal situation but realistically isn't going to happen much without a 4090. Using the DCS FPS graph, the red CPU bound on main thread generally indicates CPU bound, the yellow CPU bound on render thread generally indicates GPU bound.

The quest pro is easier to run due to the lower resolution, the lenses are also different/better than the aero (from an optical clarity point of view) but the aero is sharper.

It's holding it's own Was just playing pretense and getting 75-80 fps in ka50, A10C gives me 80-90 fps normally. I can't max settings but it's more than playable and far better than the G2.

@recoilfx what actual FPS/appGPU frametimes are you getting? Running 35ppd in the aero and mostly high DCS settings I typically get between 75 and 90 fps. To the best of my knowledge the performance between varjo foveated and QVFR is pretty much the same.