The previous post asked about future changes to avoid wasting time tweaking things that will be removed.
And, are the Front/Rear wheel Options, “(my)Wheel-Roll Moment Scale” safe to use?
currently i’m doing physics r&d which will lead to a big update that will change a lot of things(drivetrain and wheel model). also due to recent performance drop speculations i’m planning changes specific to unreal engine and that means all your existing vehicle blueprints will probably become unusable. it is difficult to tell how long these work will take, i’m not even working on unreal version yet.
if your project has a time constraint just go with the current version. the v1.8.x branch may only get an update with some bug fixes. it won’t be easy to migrate to 1.9 or 2.0.
3 Likes
I was passing the values of tire96 to a new one with mf61 to keep same behaviour and unlock all params and found this:
On mf61, In lateral, PHY3 is missing. Is on the simplified tire96 one, but not in the complex mf61. All values are in mf61 except that one. Missing or in complex that value is deprecated? Corresponds to “Variation of shift Shy with inclination”.
they’re different variations of the pacejka tire model so do not expect every parameter to be the same. mf6.1 is a more recent one so some variables are removed and some are added.
Ok, i did more research and seems it refers to camber which in mf61 seems splited more complex in PKY3, PDY3, PEY3.
I checked the FGear docs and has some dead links related to this params:
https://www.tut.fi/ms/muo/vert/11_tyre_as_car_component/handling_braking_pure.htm
If you have any other site references to download/buy let me know or update links pls.
I found ones like this but they are examples/incomplete:
And other sites like siemens or michelin… but you have to contact the sales team and all that stuff.
Another thing is, there is no way to convert or use an oficial .ini or .tir to be used with FGear as tire model? Having to set one by one, 100 params, to test, well…
the default parameters are from the book “Tire and vehicle dynamics”.
you might find a couple of parameter sets out there but their model version is most likely different.
I had found a couple of sets years ago but I didn’t feel much difference.
it is possible to import/export tire models(json) in the unity version but nobody used that so I didn’t implement sth. similar in unreal.
Please double check mf61 “OverTurningMoment” & “RollingResistance” params, seems they are missconfigured. Overturning cant get working and rollingresistance if i change the first param like 99 positive or 99 negative it body rolls the car left or right which is what OverTurningMomen should do.
“(mx) Over-Turn Scale” in BP affects to rolling resistance values but i think it should affect to “OverTurningMoment” ones. If so, double check all other params just in case.
thanks for the heads up, it’s a coordinate system conversion bug, +Y is up in unity but that’s different in unreal. the correct code should be:
mCombinedTorque.Set(Mx, My, Mz);
Ok thanks!
So in FGearTIreMF61 i have to change the line in 308:
//combine torques
mCombinedTorque.Set(My, Mz, Mx);
By:
mCombinedTorque.Set(Mx, My, Mz);
Correct?
Had tire96 any similar problem?
Also due in UE5.6 they changed the coordinate system to be Y up instead of Z, it means that this will need to change again?
yes, that’s the line.
there is no torque calculation in tire96.
Also due in UE5.6 they changed the coordinate system to be Y up instead of Z, it means that this will need to change again?
where did you read about that, I don’t think unreal could ever change the coordinate system.
Check this:
so it will be optional at first, even though I prefer the y-up system this means we will need to support both systems. this will be painful for a lot of developers…
Another thing, in UFGearWheel::myFixedUpdate there is combined torque:
//torque from tire model + tire reaction torque for x component
torque = mCombinedTorque;
&
//scale torque
torque.Y *= mRollScale;
torque.Z *= -mAlignScale;
torque.X *= -mOverturnScale;
Are they correct? My doubts are about this line:
//add wheel torque feedback, when braking take brake disc radius into account(~%30)
torque.Y += mLongitudinalForce.Size() * -FMath::Sign(mWheelTorque) * (mBraking > 0.0f ? 0.3f : 1.0f) * mRadius;
In tire96, “(My) Wheel Roll-Moment Scale” was the unique one that worked due that line, not (Mx) (overturning) or (Mz) Align.
Now in mf61 all three should work(have to test all again after the bugfix), but maybe due now (My) (i guess rollingResistance) is managed by mf61, if i set 1 to get that params working, now it also multiplies that previous thing, boosting too much the car.
So, i should disable that line, then set (My) to 1, to get the mf61 tire model params working alone as it should? SInce now the rolling resistance/power is full managed there ¿?.
the torque scaling is correct.
these torques are only calculated in mf6.1 and I didn’t see much effect of them since the generated torque is quite small with the default parameters. the equations are translated from the book and the math has no physical meaning, I didn’t try to verify the outputs.
my torque.Y calculation on the other hand is the reaction torque applied back to the vehicle. I wouldn’t remove that but you can try commenting it out and see if the tire generated value generates the expected torque.
About Torque.Y thats the thing, already with 1 that line provides too much torque, making the tire model values not noticiable due are smaller.
To be noticiable i have to set like 4 or higher, but then, due that Torque.Y line, the car behaviour reacts too fast and hard to control.
Atm gonna disable and test with just the mf61 ones to know how changes the car behaviour. Guess i can try scale down that Torque.Y line to fit better with the tire model scale values.
Or even better, maybe in future update, that Torque.Y code can have their own slider better? To not mess with the mf61 tire model values for better config?
Also, after testing all new changes realized the car swing on countersteer was wrong/reduced and after debug found it was due ASR.
Again tried to disable the lngSlipOverride code and again fixed the issue.
I remember you said you gonna change by an older version to avoid it mess with lateral forces, if is an easy change, can i get the code?
it’s not trivial but also not too difficult.
I can send you the older wheel class and tell you where to look, drop a mail.
1 Like
@lazybitgames Hi, Hard Contact Scale seems to have a strange reaction to time dilation.
If I do set the dilation to 0.01 the vehicles are starting to float and slowly raising.
Setting the dilation back to 1 causes the vehicle to get an impulse force up, which causes them to jump while in the air.
If they luckly fall back to the ground with the wheels first they do behave like a loaded spring.
This behviour does not appear if Hard Contact Scale is off. But rarely the vehicle gets a small impulse up if setting dilation back to 1.
Is this some known behaviour or project based issue?
there is definitely a bug with time dilation when it comes to suspensions, added to my list.
as a work around you can try scaling up the update rate of the vehicle, for instance:
if vehicle update rate is 250 then
time dilation 1.0 update rate 250
time dilation 0.1 update rate 2500
time dilation 0.001 update rate 25000
…
you can call Vehicle.setUpdateRate function, there won’t be any performance hit.
when it comes to hard contacts this may or may not solve it, i’ll also check that out.
thanks for the info, I will try it.
Another question we run in an odd issue with the phyiscs asset.
The PhysicsAsset has its collision for the root bone, but an extra box collision on an other bone which is set to Kinematic, to be later drven by animations.
While driving the part of the skeletal mesh, which is weighted to this kinematic bone, is starting to lag behind the vehicle.
With a chaos vehicle setup this does not happen.
Is there any idea/explanation why it would behave this way with FGear?