FGear Vehicle Physics (v1.4)

Distribution UE Marketplace
,
1863

your assumption might be correct, I have already re-implemented the drivetrain inertia code in my other branch where a lot of refactor happens. the square of gear ratios is a bit of a problem since we do not simulate each part of the drivetrain but assume it’s a single part to simplify things. i’ll look into it a bit more to check if it would cause any meaningful inaccuracy.

for the current branch though the engine inertia is only used for the braking case so the problem is not that important. the negative transmission ratio is no problem since we take the abs value in the next line.

this is great feedback, thank you.

1864

Well, cant wait to the big update then, it looks lot of new things already there.

Then just in case, in the big update, this artificial force still will be a thing?
If so, same or improved? At UFGearWheel::updateWheelFriction :

if (mSpeedOverflow > 0.0f)
currentForce = FMath::Sign(-mLocalVelocity.X) * absLngFriction * mSpeedOverflow;

/

Using the improvement you sent me time ago, which basically smooths that limit with lerp.

Trying to reduce my core changes via MF61 tweaks, but that impro works very good to smooth countersteer & 360º.

So, before invest time on it wonder if also on big update is improved/deprecated/reimplemented?

1865

it’s still there but I would prefer to remove it. there is no such thing in real vehicles but it could look like a bug if you over rev the engine going down a hill. i’m testing alternative solutions for that.

2 Likes
1866

Yep, better without, if you’re testing alternatives will let for now then.

I know the plugin aims to simcade, but any push to accuracy/realism is welcomed.

Another thing, playing with MF61 there are coefs that using speed, load, camber… depends on SlipRatio.

SlipAngle clamp(-+0.475) feels good, covers a wide range (1.4923 rad, 85°) and useful, 5º of safe margin.

But seems SlipRatio gets clamped too soon?, -1+ is the K range ok, my doubt is how fast and at which conditions reaches 1.

Because reaching 1.0 too soon and fast makes that coefs useless due multiplies by 1.0 in 4 wheels missing accurate behaviour.

Wonder if maybe mLngSlipOverride and/or “GRIP Combine Mode” may amplify the result at UFGearWheel::updateSlipValues() or some unit/velocity missmatch.

Is this also revised/improved in big update?

Edit: May found something is not right but need to confirm. For testing, if i want to increase the “effective range” and avoid saturate slipRatio too fast, what should be the proper way?

1867

tire modelling is purely based on pacejka’s model and the slip calculations are the classic approach.
getting inaccurate or snappy slip values could be due to the wheel rotation code not due to the way slips are calculated.
you’re welcome to experiment of different ways to calculate slip values, I don’t have much info about that.
slip override is a controversial feature and will probably be removed.
combine mode is only used for simple tire, other tire models have their own combination logic.

1868

Then to be clear, inside UFGearWheel::updateSlipValues() :

To confirm, that “//s - a - p” is only used on simple tire model, which is Tire96, not MF61?

So, the way to calculate the SlipRatio there, in case there is any problem have to be at:

//longitudinal slip
float wheelSpeed = mRealSpeed * mRadius;
mLongitudinalSlip = mHasContact ? wheelSpeed -mLocalVelocity.X : 0.0f;
+
//slip ratio
float absForwardVelocity = FMath::Abs(mLocalVelocity.X);
mSlipRatio = mLongitudinalSlip / (absForwardVelocity + FGearUtility::epsilon);
+
//limit slip ratio/angle
mSlipRatio = FMath::Clamp(mSlipRatio, -1.0f, 1.0f);

Is correct or im missing something?

-

EDIt: Ok SAP is only for tiresimple, not for tire96 or mf61 right just debugged.

1869

Still testing, but new SlipRatio calculations are getting interesting and may explain some problems.

By default, in tire models, Combined Longitudinal(his work is decrease LngFrictionForce) is zeroed and works well because compensate with short range / fast increase of SlipRatio which decreases friction.

Then to decrease friction: Comb.Lng contributes:0 + SlipRatio:1 = 1.0 (at certain point, LngForce behaviour gets lost due slipratio goes to 1.0 in all wheels too soon.)

If with actual SlipRatio behaviour we fill Combined Longitudinal, we get that stucks and fast lose of LngForce on high angles we talked in previous posts.

Comb.Lng contributes:1 + SlipRatio:1 = 2.0 . Too much, double.
This may explains why on RCX1 had to use 0.1-0.2 instead of 1.0, and why i thought RCX1 was overpowered and asked to double check for an unit missmatch.

/

So, accurate behaviour seems should use that filled combined Longitudinal + Proper SlipRatio behaviour (bigger range with slowdown increase after peak).

Then, friction decrease contribution will be:
Combined Longitudinal:0.5 + SlipRatio:0.5 = 1.0. To get an accurate behaviour.

Then we get a realistic lose of lng friction based on tire model(via Comb.Lng) + wider effective range SlipRatio that can process all changes in car behaviour that now are lost due fast saturation at 1.0 in all wheels.

/

First tests:

Before, doing donuts or drift around i get 1.0 slipRatio in 4 wheels, now SlipRatio is:
Front Inner:0.83, Outer:0.54
Rear Inner:0.77, Outer:0.47

Still not 100% accurate but seems going in the good direction, now each wheel can process better the longitudinal friction lose variations in all scenarios.

1870

Heya, I’m trying to get the state of each of the wheels to tell if any of them are losing grip/skidding. This is for the purpose of setting up tyre skid marks, tyre screech sounds and tyre smoke. But it seems this isn’t possible? At least, not easily lol without doing some calculations.

Ideally, I want to have an accurate value similar to what’s possible in ChaosVehicles, where you can get a boolean value off of each wheel that says if it’s skidding or not.

1871

an accelerating/decelerating tire is always slipping, this is true for both real life and fgear.

you need to utilize raw slip and/or slip ratio/angle values to tell when it’s time to trigger skidding effects.

if chaos or any other vehicle system is providing a boolean value then they’re definitely doing a similar math to set that value.

you can go very simple like slip > 0.2 or make it more complicated, it’s up to the developer.

1 Like
1872

@lazybitgames Ok, so after testing and research:

Found there is a standard formula to calculate slipratio, well, 3 with variants:
1º Symmetric, 2º Asymmetric & 3º Combined (With SlipAngle).

Using 2º for full realism, and not 3º due our tire model already handle the combined longitudinal.

// === 4. SLIP RATIO CALCULATION | ASYMMETRIC | SAE J670 STANDARD ===
// Ternary version with V_MIN (For +stable values)
float V_MIN = 0.05f; // Def:0.05 (~0.18 km/h)
float denom = (absWheelSpeed > absForwardVelocity)
? FMath::Max(absWheelSpeed, V_MIN) // accel
: FMath::Max(absForwardVelocity, V_MIN); // brake
mSlipRatio = mLongitudinalSlip / denom;

IMPROVEMENTS:

  1. Standard SlipRatio calculation (SAE J670)
  2. Asymmetric (Accel & Brake)
  3. *V_MIN, due at small speeds pacejka become unstable

*NOTE: Physical floor (~0.05–0.1 m/s) to avoid numerical blow-up in slip calculations at near-zero speeds, where tire models become unstable without it. (Used in iRacing, rFactor2, Assetto Corsa & BeamNG).

Here a pasteBin with the updated block + Info + Wips:

CONS:

  1. People will need to tweak their car setup to fit the new version
  2. Fill Combined Longitudinal + tweak coefs to match previous setup

PROS:

  1. Smoother feeling / transitions at brake/accel and cornering.
  2. More realistic/accurate, able to replicate even small details missing with previous slipRatio calculation.

What’s left:

  1. Condition to avoid sign fight
    Why?: If netTorque on Full Throttle & Brake is around 0 = Car move/stop/move…
    i> Brake always wins conflicts |>| Real cars prioritize braking. From iRacing/rF2 (brake overrides drive).
    i> In Dirt Rally 2 if speed is around 20, it decel until 0 and throttle/rev is cut = no oscilations.

/

About “mLngSlipOverride”:

Seems it should be removed, is a hack, not physics based.
Ignores real wheel spin & force slipRatio to peak grip value when ASR/ABS is active.
Posible bugs causing: Due overrides real slip > jitter, lockup…

Still testing but i will say better without.

/

1 Like
1873

Since I didn’t get a response, what would be the best AI racer for fgear on the marketplace?

1874

Try Nav Mesh Vehicle AI Nav Mesh Vehicle AI | Fab

It works with FGear though there’s some setup and tinkering involved. I use it in my game, though that’s open world, not racing.

1875

@lazybitgames would you happen to know why my character’s movement has such extreme forces on the vehicle when I walk across it? I don’t think this is related to the character movement component as I tried with Physics Interaction disabled and it still affected the tank. As you can see, the physics-based bucket does not move but the tank still does.

image
image347×369 6.71 KB

1876

actually it is related to the character movement because this doesn’t happen in unreal5 and I don’t remember a fix to this behavior at this time.

1877

It happens in Ue5 even with physics interaction turned off in the CMC.

1878

which version, I couldn’t recreate it in 5.6

1879

awesome thanks! I’ve now set it so I’m checking if the Slip Ratio is greater than 0.2, and it works pretty well!

1880

About mLngSlipOverride it gets the job done to get a good peak slipRatio, reducing understeer on braking.

If removed, ABS or a new system like EBD (Electronic Brake Distribution) should replicate in some way.

Investigated, but actual ABS and ASR use deltaV which is also not accurate, seems they should use BrakeTorque & Enginetorque instead.

Then, EBD should work in combination with ABS+ASR to deliver peak slipRatio during full throttle, full brake, or mixed inputs without any slip override hacks.

But is very tricky and due you may remove it and improve drivetrain on Big Update, will keep that hack for now until review the new code.

1881

Could you screenshot the character movement component’s details panel? I can try replicating those settings and see if the issue stops

1882

I tested with the character in EnterExitDemo map in the example project.

1 Like