Another FFB thread. But might be interesting (and helpful) to some…

aaron0288

Well-known member
I wasn’t sure where to post this initially, but feel it needs some discussion first from those who know far more than I do about the subject before it goes to the bugs section.

I came across this post on Reddit yesterday, just take a read first before going any further - https://www.reddit.com/r/LeMansUltimateWEC/s/9P7qk8cKqQ

I have commented on it but not heard from the OP since. But I swear I have lost some detail in the FFB. I don’t run VR, but do limit my FPS as the user does in the reddit post. This is where he is finding a loss in detail in comparison to having no frame rate cap. He has cold, hard Motec data to back up what he’s feeling. I can’t say for sure my thoughts yet as haven’t had the time to get on and test this, but it would just be a “feeling” test as I have no idea how to use motec.

I wonder if anyone else out there with motec could try and see if there’s anything in this that’s worth reporting to the devs.
 
Gosh, I’m almost reluctant to post. I’m not a dev, and even when devs say stuff people don’t believe them if they’ve already made up their minds, so… well here goes anyway.

First, in case you ever do want to check motec logs, DAMPlugin is all you need. The sharedmemorymap plugin isn’t used at all, which the reddit OP seems unaware of. Take that as you will.

Comparing telemetry traces by eye, especially something noisy like FFB or suspension movement, is actually pretty tricky. Add in the fact that the underlying source may be at a higher rate and really your only half sensible approach is FFT analysis - but across a higher number of runs to at least reduce variation in driving line etc. In this case the FFB output is shown at 100Hz, but the game sends FFB at 400Hz. The plugin can be configured to log it at that rate. If you imagine having two noisy sources, then you just take every 4th value from each one... it's not much good for comparison.

The game runs its internal physics loop at 2400Hz, without fail. There is no link to graphics framerate. (tiny history: rF1 output its telemetry at 90Hz or the current frame rate, whichever was lower. I assumed that reflected the internal physics running slower (4 loops per frame, 360Hz internal). rF2 always outputs telemetry at 100Hz, and will go into slow motion if the CPU can't keep up (unfortunately for online play). LMU is the same) So every 6 physics loops the FFB is output, hence the 400Hz output. Physics doesn't skip, therefore FFB doesn't skip.


I've said it elsewhere, and people tend to take this the wrong way, but placebo is powerful. Thing is you talk about placebo and people get all defensive, "oh, so you think it's all in my head huh? Well I can feel it!" .. and, well, yeah, that's the concept, but it's a known phenomenon (it's literally the most consistently effective drug known to science; people get positive benefits from placebo even when they know it's placebo! It's nuts!). Nothing to be ashamed of, just have to be aware of it and try to do everything possible to account for it when testing stuff. Changing a setting and then testing: well guess what, you know what setting you just changed, and you will naturally be biased toward anything that suggests the expected effect of that setting. (sim racers adjusting car setups should be well aware of this potential; anyone who's made the mistake of thinking they assigned a setup and realising after 15 minutes they've been running on default, knows about it)

And unfortunately: good luck trying to blind test if you're comparing VR to screens. If you don't know which you're using, you're not in a fit state to test anything :D

You can pretty much lump framerates into the same group, because chances are you can see the difference. Maybe if you have someone change the settings and you're wearing goggles smeared with oil so you can't spot framerate/sync differences but can drive around a track well enough to feel the FFB, and you're out of the room when they "randomly" make the settings change, and preferably a third person is leading you in and out of the room so the settings-changer can't accidentally give anything away, and you run tens of tests and check your accuracy... then yeah, maybe.


Finally: there's a tendency for people to show motec graphs as proof of things, without always understanding the limitations of what they're showing (either what the data itself shows, what it means in the context of a game, the limitations of the data format (game or Motec), or simply how much is relevant to what a person can discern). And people who haven't used Motec see a graph, see something they're supposed to see, and start to wonder. And I get it, but it really shouldn't be used to draw any conclusions until a lot more investigating is done. Surprisingly (ironic) when you start drilling for details very few people are willing to do the work.


Anyway, I digress. Suffice to say I think it's very unlikely FFB changes with framerate. Can probably get a dev here to say the same, based on the code they can literally see, but... I'd refer you to the first lines of this post. The reddit OP will likely be unconvinced.
 
Thanks for that Lazza. I’m not even going to pretend I’m able to understand everything in your post, but I get your overarching point.

That’s certainly my experience anyway and I try not to let the placebo effect come into play, but totally get it’s difficult to get around with things like this. I just found this post particularly interesting with the motec data and wondered if anyone on here with more knowledge than me could glean anything from it. I think I’m overall still not too happy with the change in FFB since the December update and am maybe just stretching here trying to get that detail/snappiness back in the FFB.
 
"FFB doesn't skip". I can say it skips at my hands.
And i'm not the only one. It happens a lot when people connect/disconnect.
Also, i'm pretty sure it wasn't there on very first versions. Something added (CPU intensive, imo), later on, induced that, for sure.

How do you explain that ?

When i see those quite high frequencies like 2400 Hz, i'm pretty sure that most of users PCs can't run that on "hard" real time.
Others things need to run on the PC, like USB controlers or other ressources, network, sound, display.

And Windows is NOT a real time OS. How devs can guaranty that signal emitted to the controler is the same as calculation and with proper frequency/latency ?
On reddit page, we can clearly see that details are lost from signal sent to the telemetry at least.

VR and even more on locked framerate causes conccurency between the game and the VR management which is also "real time" intended for sure.
At some point, one or another will loose its "priority" and cause framerate loss on VR or other effects in Game, like loss of FBB or network data.
 
"FFB doesn't skip". I can say it skips at my hands.
And i'm not the only one. It happens a lot when people connect/disconnect.
Also, i'm pretty sure it wasn't there on very first versions. Something added (CPU intensive, imo), later on, induced that, for sure.

How do you explain that ?

When i see those quite high frequencies like 2400 Hz, i'm pretty sure that most of users PCs can't run that on "hard" real time.
Others things need to run on the PC, like USB controlers or other ressources, network, sound, display.

And Windows is NOT a real time OS. How devs can guaranty that signal emitted to the controler is the same as calculation and with proper frequency/latency ?
On reddit page, we can clearly see that details are lost from signal sent to the telemetry at least.

VR and even more on locked framerate causes conccurency between the game and the VR management which is also "real time" intended for sure.
At some point, one or another will loose its "priority" and cause framerate loss on VR or other effects in Game, like loss of FBB or network data.
Completely different topic, as that dip or break in FFB is what the game does when someone joins (or any other event that increases CPU use). It won’t be reflected in telemetry, because it happens after that in the process.

Oh, and: physics is calculated at 2400Hz, but the FFB output is 400Hz. So that 400Hz is the requirement, will jitter (not that you’d notice). Not the full 2400Hz.
 
Different topic, sure, but that shows how "real time" tasks can be disturbed by other things.

By design devs seem to assure that FFB is always calculated and "sent" to controler.
There is at least one case where they are wrong.
 
Different topic, sure, but that shows how "real time" tasks can be disturbed by other things.

By design devs seem to assure that FFB is always calculated and "sent" to controler.
There is at least one case where they are wrong.
Why are you turning a thread into apparent variance in logged FFB output into an examination of the nature of the game's output as a whole?

Are you referring to the join/exit lag and FFB drop? The game didn't do that originally. Instead there was a huge FFB jolt as it paused, and then resumed after the interruption, causing a sometimes dangerous reaction in DD wheels. So they introduced code to mute FFB when the game detected there was a delay getting updates. I'm going to roughly say that happened within several months after the initial release, and it hasn't changed since.


Again: the thread is based on a post about apparent discrepancy of logged FFB output - which won't show that muted FFB, because all these calculations are not skipped and happen before any slow down is detected and any muting can happen.

There are multiple threads about that muting/interruption already. I'd nearly bet you've already posted in them yourself.
 
Sorry, it's hard to not link those phenomenon to the "real time" processing and possible loss of signal.
 
Back
Top