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