hughlb

We tried this method, and in fact tried using a technique to activate exclusive fullscreen in the single threaded open beta. There was a time before 2.8 where alt+entering was possible, and improved the smoothness of the image. Sadly, this didn't affect the TrackIR issue.

You are not correct. It did work, in fact it worked well prior to 2.7 as well, for several years. I first reported on this issue in DCS back in 2016. It was a problem then, and then at some point ceased being one. I can only speak from my own experience, it may have remained an issue for others. As for MSFS and IL-2. I can jump into either of those right now, and it is a night and day difference. The issue simply doesn't exist. With MSFS, I need to enable both vsync and gsync, and with both I cap my framerate at 100 FPS. But I don't need 60 or 120 FPS to get it smooth, it is smooth at variable framerates. This nullifies the idea it is a poling problem, or hardware issue, per se. If it was, shouldn't I have this problem in all applications that use TrackIR? I don't, therefore a more probable cause is how the game engine interprets TrackIR data. To quote NaturalPoint themselves from the other week "TrackIR does attempt some smoothing, but again, only reports that same data 120 times a second. If the game is out of sync, you will see periods of time where the game and TrackIR line up, and periods of time where it does not. This results in multiple frames in a row receiving the same data, and some frames even being lost. The jumping/acceleration the user observes is likely the game engine not polling at the right rate with his configuration. This is especially a problem if the game is depending on the framerate to poll TrackIR information. It should be its own process independent of framerate. I also see games often do their own smoothing for other input sources so that this is less noticeable if anything goes out of sync." https://forums.naturalpoint.com/viewtopic.php?t=25141&sid=937eb55a2ec8cea58a870dd11272d602&start=10 Not to repeat myself from my original post - but I have tested this across different systems, seven years apart in terms of hardware, different OS, and even a different TrackIR units. The issue is identical on both systems. I have even moved house several times. Everything susggests this is game engine related, and perhaps more broadly, including interaction with GPU drivers, and how they work with TrackIR position data. It is a solvable problem, at least in as much as it can be minimized or controlled to the point of it not being noticeable. And I think, based on the feedback from NatrualPoint, that this needs to be mitigated by the game developer. TrackIR spits out its data, the game engine uses that to address camera position.

It is really pronounced. The easiest way to describe it is this - it looks like the frame rate is 20-30 FPS. For example, if my frame rate and monitor is set at 100 FPS and 100 Hz, respectively, but I look around with TrackIR, then the frame rate resembles 20-30 FPS. Keep in mind, the frame rate is not 20-30 FPS, it is 100 FPS. If I hold my head still, and instead use the mouse to pan the camera around, it looks like 100 FPS. My original video demonstrates that every five frames or thereabouts, we essentially get an anomalous position update for TrackIR. In that there is a 'jump' or 'spike' in in-game head position. It is subtle. There are more or less 25 of these erroneous frames every second, if the frame rate is 100 FPS. This presents as a rhythmic judder. I think people often misdiagnose the issue because they look for a stutter. The terminology isn't great at defining the appearance of the problem. A stutter can be rythmic, but the intervals can be seconds or more, or a stutter might not be rythmic at all, and instead be a hitch or pause, or sequence of pauses. This is a predictable, repeatable problem that occurs all the time, 25 times a second, when using TrackIR in DCS. For anyone following - below is a collection of different forum threads, over several years, detailing this specific problem, and how locking frame rate to 60 or 120 FPS resolves the issue. The question however, is why did TrackIR in DCS once work perfectly (2.7) at variable high frame rates, and why don't I currently have this issue in MSFS or IL2? It is possible to resolve this problem, and it appears to be game engine related, and how TrackIR input data is resolved by the engine. Also, notice how many threads relate to DCS. I rarely see this mentioned in MSFS, for example. 2016 - https://forums.naturalpoint.com/viewtopic.php?t=13991 2018 - https://forum.dcs.world/topic/186271-track-ir-stutter-fix-petition-at-natural-points-forum/ 2018 - https://forums.blurbusters.com/viewtopic.php?t=4242 2018 - https://forum.dcs.world/topic/172576-25-trackir-stuttering/ 2018 - https://forum.il2sturmovik.com/topic/40171-stuttering-while-turning-my-head-in-the-cockpit-solved-to-95/ 2021 - https://forum.dcs.world/topic/293359-does-ir-tracking-have-issues-stuttering-above-60fps/ 2021 - https://forum.dcs.world/topic/288806-stutters-flickery-motion-with-new-144hz-freesync-monitor-and-track-ir-running/ 2021 - https://www.reddit.com/r/hoggit/comments/smlqdj/alot_of_people_say_they_have_to_disable_gsync/ 2022 - https://forum.dcs.world/topic/293359-does-ir-tracking-have-issues-stuttering-above-60fps/ 2022 - https://www.avsim.com/forums/topic/619132-track-ir-stutters-with-msfs/

We have established that 'mouse look' or panning the camera using the mouse is smooth, whilst looking around with TrackIR is juddering. However, when I change my mouse poling rate from 500 to 125 Hz, I notice the mouse panning also starts to begins to stutter, not as badly but noticeably less smooth than 500 Hz or 1000 Hz. I haven't noticed this in other games.

FYI - Whilst I don't have a solution, after a lengthy troubleshooting period with the team at NaturalPoint, they have acknowledged and expanded on how the interaction between the game engine and polling rate of TrackIR can be a cause for this problem. But it also helps explain why some titles (MSFS, IL2 GB) don't present the same problem, under the same conditions. I feel there is hope that ED can solve or minimize the effect. As I have pointed out, prior to 2.8/2.9, for a long period with 2.7 and prior, this wasn't an issue for DCS, it appeared to be resolved. So it is possible to get TrackIR communicating smoothly with DCS, at variable refresh rates outside of 60 and 120 Hz. I have attached the post provided by Jillian from NaturalPoint, with good information from a NaturalPoint software engineer. I have also pasted my response below, and you can also read the forum thread here - https://forums.naturalpoint.com/viewtopic.php?t=25141&start=10 "Hi Jillian, thanks again for your response and investigation. This is really critical information, and something I feel developers, such as Eagle Dynamics, should be better alerted to by NaturalPoint. FYI, I have a lengthy troubleshooting thread on both the Eagle Dynamics forum, and through an open support ticket. Almost everything has been suggested with the exception of recognition that this may be an in-engine issue in how the tracking data is retrieved and, consequently, smoothed. Again, really critical information for developers. They may be implementing TrackIR support without fully understanding how to manage its data, and circumvent this stuttering issue. Again, no change after looking into these suggestions. I think we can, at this point, assume the issue is a TrackIR polling rate, frame rate interaction, and how that is handled by the game engine. The only "fix" to this issue we have come across, is switching game engines. MSFS can have a variable framerate, as can IL2 Great Battles, without causing this stuttering problem, or at least minimizes it significantly. However, DCS is severely hampered by stuttering at framerates outside of a fixed 120 or 60 fps. The fact also, that for several years, and prior to their current 2.8/2.9 versions, they had resolved this issue (perhaps inadvertently), again support that this isn't a user issue with hardware or software conflicts and settings. I will update my ticket with Eagle Dynamics and make these suggestions, but it would be useful if NaturalPoint could reach out and alert ED to the fact this issue can be both triggered, but also resolved by the developer. They might then look at how they can smooth TrackIR input data, perhaps even review previous versions where the issue wasn't apparent."

I thought you might be onto something there 5ephir0th. But no change. I tried both the global and program setting for Background Application Max Frame Rate, with combinations of 60 and 100 FPS, but no effect on stuttering and the TrackIR software itself still indicates 30 FPS.

As boerdi shows, use FPS Monitor or Fraps, and open the TrackIR software. It should have a counter in the top right or left corner of the screen. I believe they run the app at 30 FPS to minimize pressure on the CPU, as the software is just a monitor to ensure its tracking properly. The sensor itself would still be running at 120 Hz, I would have thought.

I have responded to their post, but it hasn't cleared moderation yet. Essentially though, minimizing didn't make any difference (or any of the other suggestions). The only strange thing was the 30 FPS of the TrackIR software, but it may be a red herring.

A very good point indeed boerdi. I do run two powered hubs for peripherals, but have been running my TrackIR directly into the rear IO. I will test your suggestion. Another point worth raising for people reading this thread - over on the Natural Point forum, I was asked to check what my TrackIR framerate is running at. It is 30 FPS in the Track IR window. When I move my mouse around in the window it jumps up to 100 FPS to match my monitor output. Odd... perhaps nothing, I mean the Track IR window may be running at 30 FPS displayed, but the sensor running at 120 Hz, but worth noting. I will see what Natural Point say in response.

No unfortunately. I have posted a response there, but it takes a while to clear moderation. The smoothing options in the TrackIR, which were a good idea to test, made no difference.

Again good data. I have had this issue occur with a 100 Hz and 144 Hz monitor, but never had a monitor that could go any higher. I recall with the 144 Hz monitor, I found dropping it to 120 Hz fixed the issue, but I never went into that 150-175 Hz range. One thing for people to know, if you try to look for this issue with a 60Hz monitor or with a framerate below 60 FPS, don't bother. Any stutter gets lost in the trailing/ghosting and inherently less smooth image at that framerate. There weren't many people running 144Hz monitors back in 2016, which is maybe why I didn't find much help back then.

Possibly Hiob, but I really doubt it. If it were, you would see it in all applications equally I would have thought. I can go play IL2 GB right now and its smooth, MSFS is somewhere in between, and DCS is just horrible for whatever reason. Also I have my USB devices connected via two powered hubs for everything except keyboard and mouse, and I have turned those hubs off for testing to remove an possible conflicts. I even have a new mouse and keyboard in my latest PC of different brand, so that rules out those causing an issue. Windows 10 and 11 same problem. I think it is something to do with the polling rate of the TrackIR, that's the only suspect presently, because of that 120Hz polling rate. But as others have pointed out, it shouldn't really matter, it's just spitting out position data at pretty high rate. Such a strange issue. Vsync seems to have an impact on it, not in DCS, but in other titles, so perhaps we are seeing something akin to screen tearing, but in this instance motion induced stutter.

That's great data Loukuins, it'll be interesting to see if someone more knowledgeable than me can shed light on why that is occurring, maybe as you say, DCS needs a specific ratio of refresh rate to camera input. Thanks.

Yes, part of the reason I have looked into this issue again is - A) It has returned to DCS since the release of 2.8 for me, and is too jarring to unlock my frame rate above 60 fps. The image resembles 20-30 apparent FPS when looking around, despite a locked 100 FPS. B) NaturalPoint are answering forum threads, and troubleshooting issues, and so are Eagle Dynamics. Both communities are in a better state than they were in 2016 when I first raised this issue, and seem very receptive to helping. I have had at least three ED employees try to assist in this problem thus far. What we don't have yet, is a clear explanation for what is happening. We know the issue exists, I just provided a video analysis of it, many users have arrived at the same conclusion independently that for whatever reason 60Hz (or 120Hz if you can maintain it), provide a 'fix' to this issue. I am optimistic that a software solution is viable, be it the TrackIR itself, or how the game interfaces with TrackIR (or possibly 6DoF in general). This is because the experience is different game to game. I just fired up IL2 GB and its butter smooth at a locked 100 FPS when looking around with TrackIR, go figure.

If you have a 120Hz monitor, and are gaming at 120 FPS, then you are perfectly matched with TrackIR's native 120Hz polling rate. 60fps will seem "worse" because it is low enough that you will see some ghosting or trailing of the image as you look around, but it will look smoother than 61-119 FPS, because it is a perfect division of 120 (2x 60 = 120). There is absolutely no performance trouble in DCS. You can see I am running a 100Hz monitor, and can easily maintain 100 FPS or greater with a 4090 and 7800X3D. I have also tested with a completely different machine running a 1080TI and 4790K, on a different OS, and the issue is the same. I have tested with different TrackIR's also.

The issue: At framerates other than 60 or 120 fps, there is rhythmic stuttering when looking around with TrackIR in DCS World 2.8. When not looking around using TrackIR, and instead looking around with hat switches, or mouse look, the image is perfectly smooth. The cause: Unknown. TrackIR has a polling rate of 120hz, which is a likely contributor to this issue, but does not explain why some titles are affected and others are not, or to varying degrees. For instance, Enabling vsync in Microsoft Flight Simulator or IL2 Great Battles, resolves this issue, or minimizes its effect to a point where it is unnoticeable. In DCS, prior to version 2.8, there was no need to enable vsync, or limit framerate, but the user could Alt+Enter to enter apparent "Exclusive Fullscreen", resolving this issue. I can confirm (using the AutoExec) Alt+Enter does not fix the issue anymore, it is prevalent in in both exclusive fullscreen and fullscreen in the ST Open Beta. This is a camera position issue as far as I can tell, in that the position of the camera is not updating linearly on each frame, there is a jump on certain frames and those certain frames appear to be in sequence - e.g. frame 5, 10, 15, 20. I have a video later in this post displaying this. I could deduce that some games are using a form of smoothing to predict the camera position, and bypass any erroneous position data, but I am speculating. Research: I first reported on this issue in 2016, in the following thread on the NaturalPoint forum: https://forums.naturalpoint.com/viewtopic.php?t=13991 There have been many more forum discussions since then, here are two recent ones: https://forum.dcs.world/topic/267346-tr ... tc-solved/ https://forum.dcs.world/topic/325383-tr ... servation/ This is a difficult issue to reproduce - it requires testers run a monitor at a refresh rate greater than 60hz (more common today), and of course, capturing a video will not show the issue clearly, more often than not because the clip has been recorded at less than the in-game framerate, or framerate has been restricted by the upload platform. The only way to see it is frame-by-frame. Below is a video I have captured showing the issue, frame-by-frame. https://youtu.be/AWHxhHa4ejI What is noticeable, is the fact there are no real hitches or pauses in the game, but rather every five frames there is a jump or acceleration in the camera position, evident in the relative motion of the P-51 when moving from frames 4-5, 9-10, 14-15, and 19-20, respectively. Then, the very next frame (6, 11, 16, 21) shows less acceleration than all other frames. So the result is quite interesting. If we focus on one instance of stutter (frame 5), we see accelerated movement on frame 5, reduced movement on frame 6, and by frame 7 we see the expected position of the camera, which is to say, the acceleration on frame 5 and deceleration on frame 6 nullifies any gain in camera movement. This makes sense, because if the camera position simply accelerated every 5 frames, we would see a divergence of the input (head tracking) and output (camera movement), so the two must cancel out. But why is there a 'spike' in camera position every five frames?! That is the question, as removing the acceleration and deceleration between frame 5 and 6 would create linearity of movement through the frames, and stutter would be resolved. Troubleshooting: There is no apparent hardware issue, all indicator lights are working on the device, and there is nothing to suggest an IR issue. I have also been fortunate to borrow a friend's TrackIR5 and reproduce the issue with their device, and in multiple environments / lighting conditions. I have lodged a ticket with Eagle Dynamics who provide the following analysis: Your problem is not related to the fact that enter exclusive full screen was removed from DCS, since other users and our testers do not experience problems with TrackIR stuttering.This may be due to some third party software or TrackIR settings. They expanded on troublshooting, asking me to cull a considerable number of background processes, as well as establish a new admin account on Windows. Neither of those provided any change to the issue, which isn't surprising, because I don't believe this is a 'stuttering' issue in the traditional sense. The game itself is not stuttering, it is the camera movement, or the camera movement is inducing stuttering. Their assistance is ongoing, and I will update this post if troubleshooting resolves the issue. I have been fortunate to build a new computer, and have been able to reproduce this issue on both old and new systems indicated below: System 1: 4790k, 1080Ti, 16GB DDR3 1600, Windows 10 19045.3086, Nvidia Driver Version 536.23 System 2: 7800X3D, 4090, 32GB DDR5 6000, Windows 11 22621.2134, Nvidia Driver Version 536.23 I would love a solution to this. I don't wish to be dramatic, but it is preventing me from playing DCS at framerates greater than 60. The experience is very jarring to my eyes, looking something akin to 30fps, irrespective of the high framerate.

I have raised a ticket with support regarding this issue. There doesn't appear to be a suitable workaround, leaving TrackIR usage in the sim a jarring and unpleasant experience. Given how integral TrackIR is to systems management and situational awareness, I feel this is something that needs more attention. Eagle Dynamics did resolve TrackIR related stutter back in 2016/17, providing us with several years of beautiful fluid TrackIR inclusion in the sim. It is a shame the same, or a similar apparent issue has returned in 2023.

What is the latest on this situation? Can we enter true full-screen in the multithreaded beta?

So image sharpening has worked all along for me, but the Framerate limiter doesn't. I have a gsync screen, but I have disabled gsync, tried vsync/fastsync, no vsync, reinstalled the driver and only enabled the framerate limiter, still nothing. It's odd because V2 has been working fine, just thought I would try V3. I have also tried the limiter with both ProfileInspector and without ProfileInspector. I have tried disabling Asus Tweak II and Process Lasso, neither of which make a difference to the problem.

I cannot for the life of me get the new V3 Nvidia framerate limiter to work in DCS. Can anyone verify? V2 works fine, and V1, but the latest version does nothing.

The intent of this thread is starting to get fuzzy at this point. Consider this OP - it is better for all involved, including the consumer, if two ‘big ticket’ modules are available, rather than not. If we are happy to buy, then making the product available to sell is a good thing. We then get the ultimate choice of investment. To the subject of this thread – this is being blown way out of proportion. There is the presumption that this temporary resource reallocation to the Viper is only detrimental, without considering the advantages of shared development pathways over the course of early access. Which I can only imagine is because the OP feels one or several systems have been compromised in the immediate future. If that is the case, then it comes back to the decision made to take part in early access, a period where the order and rate of development is understood to be dynamic. Did you buy in too soon, OP? If it is not one or several specific features, and simply the principal of timely delivery and adequate early access product support, then consider the benefits of parallel development and don’t focus on periodic compromises, which will happen. Also use a metric of comparison - the only fair comparison would be third party developers, as they are developing the same products within the same ecosystem. They too have multi year early access periods, and manage development in parallel, especially on complex fourth gen aircraft. Would it also be reasonable to assume that this is the only instance of resource reallocation during development of a module? I honestly don’t believe so, but I also don’t see a problem with that. I see the only issue here being the expectation placed by some on early access. Make no mistake, we all want completed modules, and if it is missing key features when it is released out of early access, I would be asking questions too. Sent from my iPhone using Tapatalk

Such a shame when a post like this appears. It serves to casually disregard all the ongoing work since the Hornet entered early access, the near fortnightly effort to update the module, and the depth of systems already available. It’s disappointing for the team working on the Hornet to read. Sent from my iPhone using Tapatalk

I think that might help Harli. Anything that clarifies both the purpose and scale of early access is a good thing. If it weren’t a Steam product, getting away from calling it “early access” would also be a good idea, because yes, people equate it to other games. That’s why an “insiders program” really makes it clear that this is a public phase of development, and not a released product. Sent from my iPhone using Tapatalk

You don’t get incomplete planes unless you opt into early access. The Hornet and Viper are still being developed. The systems we have now is actually fantastic, because it doesn’t discriminate. It gives all of us the option to buy the product and use the product when we wish. I could buy the Viper with the prerelease discount, then not use it for a year if I wanted to. Or I could buy the module when it exits early access. This is brilliant because no one in this thread is prevented from doing what they want to do. Personally, I was able to buy the Viper at a discount then start flying it last month, which is exactly what I was hoping to do. I didn’t have to wait for it to have TWS or other random features, I could just fly early on. The problem is, for whatever reason, people don’t want to wait. So I don’t think a different model is needed, they just need to help people understand the compromise of early access, probably through an application process for alpha testing that people sign up to. Sent from my iPhone using Tapatalk

Here’s a solution, and I quite believe we would need to do something like this. But anyway - Have an early access period split into two stages. An Insiders Program that customers can apply for, that doesn’t discriminate based on circumstance or hardware, and doesn’t have a number cap for participants. But it does have essentially an agreement that serves the purpose of testing the product whilst it is in mid development, with the standard fluidity of development, and everything subject to change. Those of us who aren’t worried about the state of early access modules like the Hornet and Viper can gladly sign up and test a basic product, with all its bugs and missing features, and be happy. Later on, once the product reaches a high level of completion it can progress into public alpha, in a state where most of its features are implemented and most of its bugs are squashed. Those that are concerned about missing key features have far less to be concerned about. In a perfect world we would all just buy into the product on our own accord, because you know, we’re adults right, and we invest into things when we have weighed up what we are getting. But for whatever reason some people need ED to call the shots on when they spend their money. So this way, those that are concerned have the public alpha as their purchase window, and those that aren’t concerned, can enter into the Insiders Program. We can then all be generally confident we invested at the right time. Sent from my iPhone using Tapatalk