edmuss

Just started using this over OVGME due to the sheer time taken to copy Taz's textures from the spindle storage drive to the nvme! So much faster A question with performance, as they're symlinks, I would presume that linking to mods held on the slower spindle drive will impact performance accordingly? Also, is there any way of activating multiple mods as a batch rather than one at a time?

Whilst I was making my electromagnet cyclic trimmer for my warthog, I had the forethought to add a 4 tactswitch button box to my warthog grip. With a couple of modifiers I have a bunch of ancillary controls available, two of which are show/hide hands It might be worth pinging ultraleap an email to see if they know of any software that will allow you to bind guestures to a keystroke.

Uninstall quadviews foveated and install varjo foveated Performance is typically slightly better with varjo foveated anyway. Ensure you disable openxr toolkit! Read @mbucchia's excellent wiki on his GitHub page and it will all be good. If you have 3080/90 I would recommend 39ppd in varjo base, 1.0 focus and 0.6 peripheral in the config file with DLAA to quell the shimmers.

So much better being able to feel what the Kiowa is doing now, thanks for your work @f4l0

All of the effects are named as to what they represent, it's fairly self explanatory. It might take a while to learn which effects are triggered with which flight condition, it might help to turn other effects down in order to isolate a specific one to understand what's happening. Using the effects monitor can help with this as well

The top window is purely fps, doesn't show you much apart from a couple of seconds history so you can see if the performance is trending up or down. I updated my post above to correct the names, had misremembered. I'm presuming that the simulation, present and submit times are all CPU and the frame is the GPU.

I had a closer look at the graph last night, if my memory and assumptions serves me right: - White = frame - GPU Green = simulation - CPU Yellow = present - CPU Blue = submit frame - CPU Yellow and blue lines are pretty much identical and almost zero, they could very feasibly be overlaid and show as a dull green. If your white GPU line was hidden behind your green CPU line then that doesn't bode well for the CPU unfortnately, I think essentially you're borderline hard CPU bound so if you were to run quadviews, your CPU frametime would increase, the GPU frametime would decrease but would then be waiting for the CPU to feed it data. Of course you could install, test and configure quadviews now (you don't need eye tracking) to see if you gain any benefit, I suspect that it may be worse if anything. I think your priority needs to be a faster CPU though edit: corrected the naming of the colours.

Awesome, thank you so much for your work

I don't think so, I'm pretty sure that appCPU is no longer a valid metric for DCS. I think the graphlines should give you a rough indication of where things are though, as mentioned above, I see a white line for GPU at 11ms and a green line for CPU at around 3-4ms (guessing); the graph is 0-100ms to give a judge of scale, although running it at 0-40ms would give more detail.

Weird, I wonder if the line changes from white to green depending on some settings? A wiki for the DCS performance metrics chart would have solved so many questions on this.

Is the focus area really wide? Presuming that is and the peripheral is only narrow because it's fixed foveation. Also the stereo resolution should be higher than the display resolution of 2880x2880. The maths doesn't add up though, as you're not stretching 140 pixels across the width of the display In the aero the foveation is a little differently set up because it's not modifying the stereo resolution like quadviews does but taking it direct from the runtime. At 39ppd I have a 1200x1200 focus area and about 1300x1100 peripheral. Total pixel count is about 5.8mp over both eyes.

Thought you would be running a fair amount of focus multiplier, what are the actual resolutions though, should be listed in the logs? Interesting to see how the resolution factors in with the performance

What's the resolution of the focus and peripheral views? So you're realistically getting 50-70fps from the 4090?

Roughly from memory... AppCPU is the time taken for the CPU to render the frame in milliseconds, however since the advent of MT this is no longer a reliable metric for performance as the CPU part of the render thread is running on multiple cores. On ST it could be read as a hard number to guage if you were CPU limited on the render thread. I think RdrCPU is a better metric but I seem to recall that this still doesn't give a whole and accurate picture. AppGPU is the time taken for the GPU to render the frame in milliseconds. 1000 / 11.7ms = 85 fps so you have 5fps (0.8ms) headroom at 80Hz refresh. VRAM is the actual VRAM in usage, not in allocation. CPU bound in red indicates that your CPU is bottlenecking on the main thread, this is the logic thread which is still (to the best of my knowledge) single threaded and handles stuff like AI and simulation. On ST this was the be all and end that would drag your fps into the dirt, now with MT the threads are seperated so there is less performance impact. I don't think the DCS frametime is as helpful as the toolkit one as as it just shows 1000/FPS, not the actual render time so you can't judge available overhead. Top line (white) is the GPU frametime, bottom line (green) is the CPU frametime, I don't see a dull green line, although it may be hidden in with the brighter green line (assuming there is a dull green for main thread and a bright green for render thread?). Openxr toolkit can log statistics to CSV, have a trawl through the menus and it should be in there, it might be buried in advanced mode. I would say that you may be wanting to upgrade the GPU at least to run a crystal light at 72Hz refresh, if I disable eyetracking in the aero (same resolution) then I get 50-55fps compared to >90fps with the eyetracking. Obviously that is without fixed foveated render, however I think the uplift is only around 10-15fps depending on how much you want to pixellate the periperal vision. I am running quite aggressive foveated settings though and the eye tracking hides this, you won't achieve the same uplift without eyetracking without murdering the visual quality. However a GPU upgrade would probably be bottlenecked by the CPU though, the fact you're running in red CPU bound main thread now is not encouraging, especially as to run quadviews will increase your CPU load due to having to render 4 views instead of the normal 2.

There's not going to be an aero 2

Hopefully the oh58 implementation comes soon

So there is a target on each control (a little yellow wireframe or similar) outlining the bounding box of the activation area. Something to aim for if you like Excuse the terrible pdf annotations scrawled all over chucks guide for the mi24 but something a bit like this: - The data for the bounding box will already be there (assuming it uses a bounding box) or at least a single trigger point so it should be a case of applying a highlight to said data (obviously easier said than done). On push buttons wouldn't be so helpful but for toggle switches and rotaries where there is a described arc of motion of the switch it will show where you have to aim for in each position if that makes sense? edit: Helpful particularly on rotary toggles where the trigger point is not known, it's almost impossible to guarantee which direction the rotary is going to go. I can touch a rotary from it's initial position and it will move clockwise pretty reliably, but there's not indication of where you should touch it to go anticlockwise. Possibly even a direction of motion arrow would be awesome if it could be added?

@BIGNEWY would it be possible to add a feature request? Could an option be added that highlights the control activation triggers? This would give a two fold benefit: - 1) As a training aid to build muscle memory whilst learning a new module. 2) Troubleshooting implementation in new modules or identifying issues with existing control actuation. I reckon this would benefit all, developers because it will simplify the development/bug hunting and users because it will minimise the frustrations of trying to randomly hit a switch in just the right way to trigger it. Upshot is that it would make leap motion (and hand tracking in general) more accessible and ergonomic as a system and get more people on board with it

It works really nicely with the mouse or a trackball, actually far nicer than with leap motion currently. Essentially treat it like any mounted door gun but with a slightly more limited range of movement

This is also very true, I find it easy, but I have 25" between the gimbal and hand on my cyclic with a magnetic force trim setup, similarly the pedals have got 10" throw so fine control changes are easy

Likewise, no really issues throwing the KW around, it's really forgiving and with the SCAS almost as stable as the ka50. Stupendously easy to hover and trim out, take the SCAS away and it's a lot more flighty, more akin to the gazelle but feels lighter than the huey.

KW is awesome so far, even better that it supports leap motion out of the box!!! Push buttons on the MFDs and keypad etc works fine but toggle switches don't respond. I can get the red switch covers to open and close with leap motion but any toggles or rotaries are a no go currently. Not a game breaker by any means but a nicety to have Keep up the great work PC! edit1: had a thought.... I normally run the leap motion hands with offsets to help avoid things like the desk and throttle etc. I reset all to zero and I have managed to actuate some toggles although it's still very hit and miss, particularly when trying to flick toggles upwards. Some of this may well be muscle memory, learning where the touch activation hit boxes are on each switch. @Kinkkujuustovoileipä perhaps the hit boxes could be enlarged if that's a possible option with the implementation? For reference, both the hind and hokum have excellent leap motion implementation, I bet it's not possible to crib off them though is it? edit2: A bit more playing I can quite reliable turn off force trim, hydro and scas channels, cant toggle them back on though with any reliablity Touching the tip of the switch is enough to flick them down, to flick them up you need to put the tip of the index finger almost into the pivot point of the switch and with a vague upwards movement it will eventually trigger. Multi position toggles I can't get any response from, same with rotary knobs (mousewheel actuation normally) or rotary toggles.

I get this all the time as well if I try to use the M4 with leap motion. Unfortunately due to my physical constraints (I have a wall immediately to my left), the M4 is really janky with leap motion, fortunately I just bought a logitech m570 and bolted it to the side of my chair and it works really well for aiming, double click wheel for aiming/cockpit click and mouse 4 for stowing.

The crystal is essentially a copy of the aero specifications wise, the crystal and aero both run foveated rendering in DCS with software written by mbucchia, the mechanism is the same and the resolutions can be compared directly. The only difference would be that the varjo implementation is native to DCS and the pimax/quadviews is emulated. I see no deterioration of visual quality between stereo render and dynamic foveated render, but I do see an 80-100% uplift in performance. For whatever reason (I think it's to do with the DX11 engine) DCS seems to bottleneck really hard when the the pixel count gets high, this is why the G2 can be such a pig to run at 90Hz. Sure you can brute force it with a massive GPU but there are much more elegant solutions such as eye tracking; it allows you to slash the rendered pixels to valve index levels whilst retaining insane clarity edit: just watched the video linked, that's the sort of performance I get with my 3080ti except with simple aircraft like the SU25 I'm locked to >90fps. With a 4090 I would be able to supersample even higher.