edmuss

Speaking as someone who uses a warthog throttle inverted as collective.... I think the biggest real advantage over a conventional sim throttle would be the longer lever throw which allows finer control of the axis, remains to be seen whether or not it will it make you a better flier? On the KA50 I have no issues with the WH throttle but the bird is heavily augmented with computer input, in the huey I do notice the lack of granular input and with for a bit more sensitivity. For immersions sake (isn't this what VR is all about?) then absolutely yes, I'm planning on designing and making my own in the near future

Sounds like open composite needs switching back to openxr for DCS. Find where you saved the open composite files and reset the global switcher. Chances are if you've not opened the switcher app in a while it's probably got a whole bunch of updates to do.

You want to set it to always on and leave it unlocked in openxr toolkit. You'll need to beat refresh+reprojection overhearld (1-2ms) if I recall correctly to keep it disengaged. Basically it'll likely need to be around 14.5ms appGPU to breast the 60hz refresh.

Awesome that it was such a simple fix and you've removed the bottleneck It's been a known issue for a long time, about the winwing exports. I have no idea if the issue is with winwing or DCS but it does catch people out.

Just for reference, turbo mode disables all forms of reprojection, even if you drop below the framerate throttle What you're describing is effectively what some people have been using with openxr for about 8 months. Some find that the sweetspot is different, for me 55fps is a touch smoother than 45 but there's not a huge amount in it.

That doesn't sound right, typically at an airfield I'll have around 10-12ms, admittedly not in the F14 though. Have you properly tuned the system as per the guides at VR4DCS? Have you killed the winwing exports as they've been known to eat CPU cycles.

Pretty much, you'll need to use WMR whichever option you choose. Basically: - Steamvr (openvr) doesn't talk directly to WMR so it needs a translation layer in the form of wmr4svr. Effectively what it does is copy the frame buffers from one bit of software to the other, this introduces losses in VRAM and I think there is some image compression in there as well. So for steamvr it's DCS>openvr>wmr4svr>WMR>headset. Openxr works in a similar manner but with a slightly more direct route. Open composite hooks into the openvr runtime and translates it directly to openxr which is supported natively by WMR and the headset. This eliminates the frame buffer copy and is generally more efficient. Openxr also handles the VR compositor differently. So for openxr it's DCS>openvr>open composite>WMR>headset. Openxr can be plug and play but only because of the hundreds (probably thousands) of hours put in to setting it up, testing and reporting by users. I'd still recommend getting to know both systems so that you know what different things do

They're under review to be updated but all still holds true for tuning windows which actually is the most important part of getting the G2 to work well with DCS. For openxr, I wrote a guide that's somewhere in this forum. Covers most of the basics. The openxr toolkit faq will give you the rundown of what each system does.

Go and read Thud's guides at VR4DCS and follow them explicitly. Get your head around steamvr (you will need to use WMR via wmr4svr) and the options to get a smooth setup and gameplay that you're happy with. Then branch out to open composite/openxr so you can see what the differences are and what is better and worse; then you can make an informed decision for yourself as to which suits you best There's a huge amount of tweaking to get the most out of the G2, it's definitely not a plug and play setup with DCS.

Yeah that sounds a bit more logical, double edged sword is turbo but it does lift the FPS to match frametimes

That makes more sense Interesting that you're so CPU bound, wonder if that's a function of the AH64 or the shadows? edit: my appCPU and renderCPU are much lower than my appGPU, typically about half. I guess the 12700 is bottlenecking the 4090 hard?

Odd, the second line (flat terrain shadows only) is the same performance as terrain shadows off? It appears to be the secondary shadows that are mullering your performance Yeah I think the edges may be slightly softer than the 2.7 ones but they're far more defined for me than the default ones

Have you drawn the attention of the issue to the devs on discord? No point whinging about it here

Yeah they're not free at all, but currently they're behaving better for me compared to the initial release of 2.8 which caused flat shadows to be soft edged like default. What he said^

Perhaps it's the LOD's that have been adjusted but I'm seeing better performance with flat shadows over default than I did with previous testing on 2.8.0. However if I'm seeing lower LOD on default wouldn't that typically result in less frametimes not more? The flat shadows also shimmer far less now than they did on 2.8.0 No, still the same selectable options as before, that was just my wishlisting

Default terrain shadows - 17ms with soft edges Flat terrain shadows with hard edges - 16ms

Have you installed todays OB hotfix? In 2.7 default terrain shadows would follow the terrain map and have a soft diffused edge, flat shadows wouldn't follow the terrain map (stick out from the side of steep hills etc.) and would have a hard stencilled edge. Default shadows had a really hefty GPU hit, flat didn't. In 2.8 the flat terrain shadows developed the same soft edges as the 2.7 default but without the terrain map following, they had almost as much GPU hit as the default. I now have flat shadows with hard edges that aren't eating a load of frametime

Hard edged flat terrain shadows are a thing again! We can now fly the lovely new lighting engine with terrain shadows on without the monster GPU hit of the soft edges, thank you so very, very much Regarding terrain shadows moving forwards, would it be possible to have hard edged, terrain map following shadows as an option? Perhaps have two settings for terrain shadows - off/flat/terrain map and soft edge/hard edge. Once again, thanks, a lot of people have missed the terrain shadows in VR!

Check if the route mode switch is engaged, don't rely on the light on the overhead dash as I don't believe that illuminates is there isn't a waypoint selected in the PVI800. I use the warthog speedbrake forward switch for route mode and a number of times it's caught me out with auto Hoover not engaging. Because the switch toggles forwards I sometimes forget to slide it back to centre so it considers it that route mode is engaged.

That's normal operation for a conventional helicopter*. The main rotor imparts torque on the airframe, more collective = more torque which needs to be compensated for by putting in rudder pedal input which increases pitch on the tail rotor to keep it all straight. As I understand it, helicopter rudders pedals are actually anti-torque pedals and aren't sprung to centre, they stay where you leave them; most decent sim rudder pedal setups can have the spring disconnected to simulate this. *Coaxial counter-rotating rotor blade helicopters like the KA50 don't suffer from this issue when applying more collective as the blades torque cancels each other out. edit: to the best of my knowledge, american helicopters rotate clockwise and need left pedal input to keep them straight, soviet helicopters are opposite and require right pedal input.

Will have a play with BS3 later on today, thanks for the quick work

Also to be fair, you didn't pay so that they would stop working, they work perfectly in the software environment that they were designed for. Where you're expecting them to work is in software that costs nothing, written by amateurs (not to cast doubt on their abilities but purely in the sense that they're not getting paid to do it) who are doing this on the side for fun If you wait for the development cycles to fully exhaust themselves (if it ever happens) then they might be fully bindable and all singing, all dancing.

I think the jump up to 12th gen is possibly a better choice as I believe there was quite a bump in performance over 11th. Someone with more knowledge may be along to correct me though

Pfft, it's a red shirt and you know it! I think even at lower levels it causes the waterboarding effect with random parts of the cockpit swimming about like your video.

Not reprojection, it's headset motion smoothing - it smooths out the jitter of your head, helpful for aiming with HMDs; check the input tab in the toolkit. Currently causes exactly what you're getting when reprojection is turned on edit: it's shaking reduction sorry, it used to be called motion smoothing in opentrack I think.