July

You say I don't need reprojection in OXR, but when I play with it disabled and have +70 FPS it doesn't look great with my display refresh rate set to 90Hz because of the tearing, jittering, ghosting, whatever I should call it. No, VSync is disabled in DCS (Nvidia Control Panel is set to 3D Application controlled at the moment, but I have in the past had it disabled in control panel). You misunderstood my comment. When doing the comparison, I used OpenXR without SteamVR, and when using SteamVR, WMR OXR is set as the OXR runtime within SteamVR. One inplementation of motion smoothing is better than the other, and I am noticing negligible performance difference between the two. I have edited for more clarity.

Maybe I shouldn't exactly call it jittering. It's the effect you get that looks like ghosting when maneuvering and looking at another object and your FPS dips or reprojection turns off for a split second. So yes, tearing, but not stuttering caused by some kind of lag. It's based on what I see, not what the game engine is putting out in FPS.

No, I have been watching the DCS in-game FPS counter and frametime overlay with the OpenXR Tools app without SteamVR, and advanced frame timings dev option in SteamVR. Neither show significant spiking during SP flight. Either way, I'm not going to play without reprojection/smoothing off in DCS because it struggles to reach 90 FPS with the engine limitations, and OpenXR's implementation of reprojection in my opinion is much worse than SteamVR's.

Yes, I have been benchmarking my results in Caucasus F-16 Free Flight and Syria F-16 Free Flight. CPU frametimes are sitting 7-9 on average.

With OXR Reprojection disabled and custom resolution at 100%, I am maintaining 60-80 FPS in most scenarios, but I still consider it worse than SteamVR's OXR or WMR set as OXR in SteamVR with motion smoothing due to significant tearing and jitter. When I run OXR at 100% custom resolution, yes the displays are clear but the tearing doesn't justify me using just OXR instead (not that significantly clearer than my previous setup with VRPerfKit anyway)

So I thought I'd give this a go since people were praising the reduced frametimes and overall better image quality. After cleaning/repairing DCS and removing my previous VR mods I placed the files in my bin folder, as well as installing OpenXR Tools for Windows Mixed Reality. I tried it, and did not notice a difference compared to my previous setup with VRPerfKit running AMD CAS at 1.0 resolution (Everything actually became blurrier at the same % custom resolution compared to my % SteamVR SS because of no sharpening/upscaling with VRPerfKit which the OP confirmed does not work with OpenXR https://www.reddit.com/r/hoggit/comments/tknziz/update_233_v06_openxr_for_wmr_headsets_others_g2/). So far, I'm seeing very close performance in frametimings at 60%, 80%, and 100% resolutions for both SteamVR and OpenXR. I have a G2, and playing DCS without motion smoothing (since it's difficult to hit 90 FPS) looks terrible so I typically play with motion smoothing on/forced on. OpenXR's Reprojection does allow 30/45/60Hz refresh rate compared to SteamVR's minimum of 45Hz with the headset set to 90Hz, while OpenXR also allows seamless switching between the lockout refresh rates. However, OpenXR Reprojection seems to cause noticable tearing effects at the edge of the displays as it hits 30/45Hz. I much prefer SteamVR's motion smoothing over OpenXR due to the tearing because I am able to maintain good enough frametimes for 90Hz motion smoothing 95% of the time. I have also had consistent issues with DCS crashing on startup, similar to what some others have been experiencing in this thread with the same errors. DCS will only open on average 1/3 tries without crashing which is incredibly annoying. In my personal opinion, it's not worth using OpenXR with a G2 at the moment because of the crashing and until the smoothing is improved unless if you play without motion smoothing. I am running a 3080, 12600k @ 4.9GHz all core. 32GB RAM @ 3000MHz, DCS on an NVME. Edit: I should clarify, comparison with is done with SteamVR + WMR set as OpenXR runtime in SteamVR. OpenXR comparison was done as OP stated, with no SteamVR passthrough.

Huh, you're right. I didn't think much of it since I thought the regular boost clock went all the way up to 1950 but that clearly doesn't sound right. Maybe all this time I've been using my card with some kind of factory OC. To be clear, I have not tried to OC the card myself, and didn't realize that the regular core clock is supposed to be much lower than it shows. To be honest, I thought this was normal but maybe it has been being pushed to the point of instability. How would I disable the OC without manually clocking it down through something like afterburner? Through my Bios? Could this also be a product of Nvidia GPU boost without me having touched anything? https://www.nvidia.com/en-us/geforce/technologies/gpu-boost/technology/ Edit: A friend has asked me to try and lower the power and temp limits to try and lower the unstable boost clock as a result of the built in GPU boost, will report back when I have results Edit 2: So far, so good, no significant crashes after downclocking my core to ~1650mhz and my memory clock to ~5000mhz and forcing my voltage lower, looks like GPU boost was causing instability. Running furmark for several minutes (~10 minutes) produced no noticable artifacting.

Any specific ones you can recommend or would something like running furmark for some time be good enough?

Here is a screenshot of conditions just before crashing, sometimes DCS will crash with a log, other times my entire PC will simply lock up and even waiting for 30 minutes does nothing. I end up having to reset. I have begun to experience this in other games as I stated before, similar conditions of +80% GPU usage into a lock-up. In these screenshots, I have underclocked my GPU core by 100mhz and memory clock by 300.

I will attempt to. I will add another thing though, these past several days my system has been going completely unresponsive and requiring a reset instead of only DCS crashing and producing a log. I may not be able to produce a screenshot when I crash that way, but I will try.

1. Yes 2. Yes, but it takes quite a long time compared to crashes in multiplayer. Unless if the map is Syria, then it's fair game how long it takes to crash. 3. Yes

I have been having the same exact issue, 1080 Ti and I think my card is failing. I've run memory diagnostics (like memtest86) I've tried downclocking/unclocking/undervolting everything just to try and rule out certain things like problems with my RAM or CPU (all diagnostics say they are OK/functional btw). I've done a factory reset of my PC and got a new NVME drive just trying to try and find a solution to this problem without actually buying a new GPU (which currently, is last resort for me) but lately I've been crashing with more frequency than ever and now it's not just limited to DCS, even Tarkov and Squad. Blue/Green/Pink flashes in the middle or corners of my screen, or crashes during GPU intensive events is probably a telling sign. Log is attached below just in case if someone asks. dcs.log

How can this not be a missile issue when the missile is launched maddog (VISUAL)? What targeting information is passed to the missile in this way for initial INS guidance from the launching aircraft?

Bump, I've been getting a few more crashes lately, less frequent but similar in the way the crash happens. Logs below, help appreciated dcs.log-20211105-015320.zip dcs.log-20211104-151459.zip dcs.20211031-160824.log

So far, so good. Lowering both the power limit and the core clock by -10%/-100Mhz has seemed to work. My GPU max temps get to around 76C so I think I can leave the power limit at 100%. The card was boosting itself to 2000Mhz under high loads which could've been the source of the instability so underclocking it seems to work. If I have another crash, then I will post the log here once again.

The display driver is up to date, NVIDIA driver 472.12 (9/20/2021). The card as far as I know, is not overclocked and is only running on its default boost clock as shown in MSi afterburner.

Attached below are the logs, crashes all seem similar in circumstance. Edit: I am currently running NVIDIA driver 472.12 with a 1080 Ti. My Windows 10 is also up to date. My CPU/GPU are not running custom overclocks, only boost clocks from the default. dcs.20211003-130841.log dcs.20211003-135509.log dcs.20211005-121002.log dxdiag.txt

Updating my drivers has seemed to work, thanks!

As the title implies, I'm having problems with DCS crashing lately. I have no clue what's causing it and would like some help troubleshooting. Crash dump logs are attached dcs.log-20210822-065717.zip dcs.log-20210822-061611.zip dcs.log-20210816-002807.zip dcs.log-20210816-004303.zip

I wasn't aware of the tracks working this way because in the past, I've observed sudden changes to missile trajectory (instantaneous Gs) as the seekers turn on within range after breaking "lock" in TWS ~16 seconds to active with the datum set to 32 seconds. I just thought that was attributed to inaccurate tracks being built by target aircraft maneuvers before they get missile warnings. I guess I stand corrected, provided it works the way you say it does. Maybe I've been seeing server desync.

In the current implementation of the way the Hornet builds tracks, it can extrapolate radar tracks even without scans, up to 32 seconds. This is based on the last scanned heading, speed, and altitude of the target. If the target maneuvers while not having been swept by the Hornet radar, the track becomes inaccurate. It's not "magic", even though it seems like it is. Is this the correct implementation of track building? I have no idea.

Ah ok, I'm seeing now that I missed it in the patch notes. I didn't know that the previous behaviour was actually incorrect. Thanks for clarifying.

As of patch 2.7.0.4625, TWS MAN no longer slews the radar scanline with the TDC. Interestingly enough, the new RWS SPOT mode now works in TWS, not sure if intended. Track attached below. TWS MAN.trk

Bumping this thread for visibility because there is now a trackfile to reference showcasing the AGM-154C drag profile. A reply and potential change to the thread tag is in order.

So far, several hours of flying and no weird thing with the volume. If it occurs again, I'll reply again in this thread.