iRacing and Simucube 2

yep, same feeling clunk only with high load or fast direction changes. and I detected the problem by holding my wheel still with one hand and moving the steering column and the QR was moving.

1 Like

Hello everyone.
Is there something I can do in the truedrive software that does what IRFFB does by upsampling the 60hz ffb to 360 hz?

The best iRacing+Simucube 2 ffb settings. If you need more detail, just lower the “Max Force” from 27 to 22, but this settings is for real world ffb feeling or close to this. https://members.iracing.com/jforum/posts/downloadAttach/2613948.page https://members.iracing.com/jforum/posts/list/75/3751615.page

Um lowering Max force from 27 to 22 doesn’t add detail it will possibly take it away depending on the car being used as max for controls the clipping point. Lowering the number WILL increase at the wheel strength though.

The recon filter does this but does so up to something around 2500hz (I can’t remember the exact number) to the drive system of the wheel…

“Lowering the number WILL increase at the wheel strength though” - exactly this moment give more feeling in low angle wheel rotation near 0-10% Yes

Would you say recon 5 us about right then?

Thats it, you need to find your sweet spot, being desired forces at centerwheel/cornering versus feeling the singnal clipped in hi load turns&kerbs

I f you can live with iRacing 60hz signal (like all of us did on past years) try Recon at 2 or 3.
Recon at 5 or above, i can feel that the signal is smooth but some kerbs and hi spikes of ffb signal can overdone the forces and fake some bumps, feeling bigger/harder than they are

Hi Stefan,

There is nothing you can do that will match without irffb currently.
This is because irffb actually reads out 360hz information from ice, although at a slight lag.

Just sucks that ice normal output is at 60hz, hopefully they fix that at some point this millenia, but it seems like we should not count on it…

Good observation and valid advice to help at the center.

I think you prob. would like and benefit from having access to the gamma filter just like myself… Cmon Granite.

Thinking of this, maybe it’s trivial to add the gamma and other filters to irffb, if granite will not set it free I will try my luck there instead. That would benefit me no matter switching to another DD as well.

1 Like

So what exactly does the recon filter do in a ELI5 fashion?
Iv looked online but it isn’t clicking with me what it actually does :pensive:

From SC2 User guide:

This filter smooths out low update rate torque signal from the simulator to the maximum possible rate while making the changes between simulator torque updates smooth.
The filter predicts torque behavior.
Low filters values are reactive also when torque rate or direction changes quickly, but some of the original notchyness from the low frequency remains in the signal. Higher values are smoother, but the torque peaks might overshoot compared to the signal that the simulator produces. This due to the predictive algorithm.
Typically, in constant torque modes or in typical driving conditions, there is no apparent lag, and the filter just makes the wheel feel more rubbery towards the higher values.

Yes but it is not due to added detail being provided it is due to addition strength raising the amplitude of the detail allowing you to feel it which is different. Instead of Lowering Max Force it would be Better to Raise the power in TrueDrive so you don’t actually lose any detail through clipping.

1 Like

5 was the original recon filter number that was most closely related to the iRacing 60Hz FFB recreation… I have found that I tend to run 7 but 5 and 7 are very similar in feel.

Unfortunately, from talking with them it will take a COMPLETE re-write of the Physics Engine to raise the Hz… Who knows what they are actually working on but if they are working on it they will not announce until they are ready to release most likely as they will not get people’s hopes up if there are delays or it takes years to do.

Damn…
Unf that points to more issues for several years, since a rewrite usually lacks a huge amount of tweaking that has been added over time for many reasons. Many times the effort to do a rewrite is way underestimated because of that. Also just all the time passing right now with feedback on the current physics system is then completely wasted.

So really bad news… Hopefully the devs find a way around it instead of going the rewrite route…

Edit after some thinking: It seems to me they are mistaken, actually. The ffb system by itself can def. be both worked on separately as well as improved in both frequency and quality without depending on a better or changed physics system. There would be no need to change the ffb system much if having to switch physics tech underneath and so it would even provide a kind of bridge to help the change from one system to another to not be felt too radically by us gamers…
Of course the underpinning physics system can set certain limits for how good the ffb can get, but that should not cause a no-improve policy on the ffb system itself.

I know I’m being clever on behalf of others here and I could be wrong, if course. It is just how I would personally deal with it, transitioning to another physics implementation or not.

But good intel, thanks bsohn!

Not really as the Physics engine has to be timed with everything through out the entire system. This is also why currently it only runs as a single thread… While the models don’t really have to be changed or anything the code would all have to be rewritten so that EVERYTHING throughout the entire system was timed to 360Hz or Hopefully if they do do a rewrite something even higher than that… Even the irFFB 360Hz Telemetry feed is actually NOT true 360Hz from iRacing as it if I remember correctly it is a repetitive entry system where it takes the last information from the physics and repeats it 6 times…

The FFB system itself is DirectX so they wouldn’t be changing that but it does require a complete rewrite of the physics system as well as the sound, display, and networking systems to keep all the timing in place, all of which they also have to take into account the level of processor that would be required for this… The timings are part of what makes iRacing so good for networked racing and unfortunately some of the prowess there is due to that 60Hz update rate.

It is apparent that they are doing something with the underlying system as they are starting to work out how to multi thread the sound and graphics system to open up processing power elsewhere. so it is possible they are working on it and we just don’t know… It is just about impossible to split up a physics thread (due to the timings required) which is why most physics model based games are best on a FAST single core.

iRacing doesn’t use a commercial Physics engine, it is their own basis so that is an issue as well since they can’t just take advantage of say the Unreal engine as others have done.

It’s a complex problem, and one that is essentially done in secret and there will definitely be a point where iRacing will need to update this aspect or possibly be left behind as far as technology goes which is why I have a feeling they are working on it quietly and have been and slowly testing aspects, such as the newer multi-threaded aspects… It is possible that even the new “beta/alpha” interface is part of this transition.

Basically I racing does have a HUGE advantage over others in the way their model system works, the methodology of their strength delivery, and the networked aspects… BUT they are lacking in the refresh rate and most likely haven’t just reprogrammed to a commercial engine because (only speculation here) that there are limitations with the way those engines work with regard to what they need for the above mentioned items.

2 Likes

Fully agree on many of your points.

I’ve myself been working directly with proprietary physics engines earlier, both hands on myself, management and discussions for years, it’s why I was blunt and dotted down that there are ways to iterate through the change from one system to the next. Even when going from single to multi threads and when timing is important to the whole system including networking.

It was just my angle and I’m sure they are attacking the problem from a much more informed angle than mine 8)
I really truly have never seen big, complex structured system be better off by a rewrite all at once VS breaking down the issues/components and attacking items finer grained.
I have witnessed such rewrite decisions been taken by more junior people and ending up delaying productions by many years and costing additionally $xx mm for a single game title iteration.
So I do have a strong opinion and it feels to me like ice might be getting their feet in that mud, potentially already being vaist deep in it.
Again, just my fears of such an approach.
There could be reasons why it would be a right approach and also its not doom to go that route if you have a stable, subscription based business model to support you all the way.
In that case it comes down to only which route is cheapest/fastest and provides timely update iterations on those systems, based on testing and user feedback. If the long route is picked you lose this opportunity of iterative ping pong based dev as well.

It seems to me we are not getting those on ice in the ffb department, but there could even be completely different reasons for that, like priorities.

I think they should consider themselves lucky that nobody did a msft job on them yet, as they would feel the pressure on the business by now.

Reg. the ffb system development I was not meaning to necessarily change the technical way it is delivered, there is always some amount of ffb post processing happening(post the physics output) that can make the ffb both smoother and better in other ways too.

Reg. 360hz from ice I don’t think it’s just repeating. It def. feels much more detailed and most cars I cannot bear to race without.

Thanks for reflecting on this and offering your insights, it’s highly interesting and hopefully we will actually have a ffb signal worthy of our DD wheel bases at some point from ice, directly!

I think it was something that David Tucker wrote about the way it worked that indicated it has a repetitive (unless he was talking about where the down scale to 60Hz took place. I honestly can’t remember fully on that one It does make more sense being the down scaling. In anywise I think there is alot that iRacing has to do to get it right and from what I understand it is a complex task especially given their development team is not HUGE.

Personally though I would like a higher FFB Update rate in the future I also think that the wheel manufactures have done a pretty good job of getting things to be closer to analog (of course we will never get there).