FGear Vehicle Physics (v1.4)

Distribution UE Marketplace
,
1680

@lazybitgames In FgearWheel, about ABS, this line:
mABSActive &= FMath::Abs(deltaV * mVehicle->getABS()) > optimalSlip;
Not should be just “=” without “&” ?
mABSActive = FMath::Abs(deltaV * mVehicle->getABS()) > optimalSlip;

And why the “bool activate = mABSActive;” ¿?

Why not just:

mABSActive = FMath::Abs(deltaV * mVehicle->getABS()) > optimalSlip;

if (mABSActive)
{
    float scaler = 1.0f - mVehicle->getABS();
    deltaV *= FMath::Max(scaler, 0.001f);
}
else if (mHandbrakeActive)
{
    deltaV *= mVehicle->getHandbrakePower();
}
1681

we want to eliminate a false positive case there.
so that &= cannot make it true unless it’s already true but it can make it false.
it doesn’t actually effect the behavior but we may want to display an ABS icon on screen with AFGearVehicle::getABSActive but sometimes even if the ABS is activated we don’t want to show it to the player. that’s why we clear the state here.

using a direct assignment like you suggested will break the logic, we need the original mABSActive value for the if case.

1 Like
1682

Also, there is no other way to get the car angle correctly in all scenarios?

Using “mVehicle->getSteerDeltaAngle(true)” (or “false” for rear) the problems are:

1.- On reverse they are always -90 or 90.
2.- When car on still erratic -90 or 90.
3.- When hold brake and almost stopped, cornering, 360º… same problem.

Due using carAngle for my EBD system had some bad behaviour that thought it was messing with ABS but after more debug found it.

Car angle not works as it should or it works as expected due was built with that limitations?

Im looking into AFGearVehicle::getSteerDeltaAngle, but too much maths for me.
Any chance to get fixed/improved? or any workaround?

1683

@lazybitgames Also found a possible bug, when you disable “allow wheel rotation against engine”, when the speed goes to 0 it does some push-forward, and when it goes to 0 again does the same always.

Here a video:

You can see that when car stops it goes foward like something pushed it. But no key presed or similar. ¿?

EDIT: TEsted in all cars in FGearExample and all does the same more or less.
EDIT2: Seems on 162 is fine, later 1.7 and 1.8 does this. Still schecking to confirm 100%

EDIT3: It looks on 1.62 thereis some Poxwer-Hp and Torque that remains static when car is still. Later +v1.7 when car is still, power-hp and torque goes to 0, and when torque get -0 this push happens. Testing and seems with mSpeedOverflow editing kind of fixes but i dont think is the way.

1684

getSteerDeltaAngle finds the angle between vehicles heading direction and the velocity at front or rear axle center so it is undefined when the vehicle is stationary. we use it for certain assist features and those assists are only meant to be used while going forward. overall it gives correct results for it’s use cases and it doesn’t need to be fixed.

the math is not that complicated so you can easily implement your version of it that handles those edge cases you need fixed. basically there are 3 directions needs to be found:
dir1: the heading of front tires (heading of vehicle + steering angle)
dir2: direction of velocity at front or rear axle centers
dir3: the heading of rear tires (same as heading of the vehicle)

then find the result as:

result = front ? angleBetween(dir2 dir1) : angleBetween(dir2, dir3)

1685

right Allow Wheel Rotation Against Engine seems to be broken with recent changes, luckily it’s an unrealistic feature and it can be skipped, I might remove it in the future.

1 Like
1686

Well, maybe easy maths for you :P, but if is not gonna fixed and i need to do my own “carAngle” to cover all scenarios will leave for later.

–
The bug/bad behaviour im trying to fix now, with automatic reverse disabled, on brake, i expect the car wheels NOT rotates against the engine, but they does, thats why i was trying to use that feature.

If the wheel has some speed and on turning or whatever, i hold brake(without accel pressed and ABS=0), the wheels slow down that in some cases there are negative values.

I think they not should do, how to fix that?

Some video:

Btw, is the third time im trying to use a supposed deprecated feature/assist, so please, in next version do some cleaning.

EDIT: Tested on Dirt4 and DirtRally2 and wheels got locked, i cant appreciated any reverse speed on wheels in this scenario.

1687

Tried to fix the carAngle to work with my needs. What you think?
Still testing but seems it does what expected.

    // My :: carAngle :: | Iteration 3
	// ----------------------------------------------------
	// Angle=0 if speed lower than 0.001 (avoid noisy)
	if (vel.SizeSquared() < 0.001f) return 0.0f; 

    float angle = front ? FGearUtility::SignedAngle(dir2, dir1, FVector::UpVector) 
	                    : FGearUtility::SignedAngle(dir2, dir3, FVector::UpVector);
    
    // Manage any direction (Forward & Reverse)	
	angle -= ((angle > 90.f) - (angle < -90.f)) * 180.f;
	
    return angle;
    // -------------------------------------

Wonder if will be safe add the fixes on the official function ¿?

1688

if it works for you then you’re good to go. as I have said earlier original version is not broken, it gives correct results for it’s use cases. users can create their own versions(c++ or bp) based on their needs just like you did but your version would change the behavior so it’s not a good idea to replace it.

1689

I know, was refering in my end, actually have a “getSteerDeltaAngle2” just cloned for this case. But yeah will keep separated atm until do all tests and double check im not using any assists or similar that can cause any interference.

–

Btw, what about lock wheels rotation when holding braking? Not should they got locked when reach 0 and not move forward-backward?

1690

brakes can make the wheels come to a stop if there is enough brake torque, the tire friction force can overcome the brakes in certain cases and make the wheels rotate. it shouldn’t happen with strong brakes and/or slippery surface.

1 Like
1691

Hello, just one question since I am interested in buying your amazing system. I tested the demo a bit and I noticed that somehow the vehicle’s will try to recover to the correct position, no matter what. For instance, testing the bike, I noticed that it will always try to recover to have the wheels down to the ground, same for the cars.

Is this something that can be configured/disabled/avoided?

For my needs, I want the vehicles to be able to flip and also this “recovering” they are trying to do, doesn’t seem to natural, no offense :slight_smile:

Thanks in advance.

1692

hi, you can’t flip the bike yes but it’s not the case for cars. we apply an external force to keep the bike up and it can interfere with the overall motion. cars on the other hand should easily flip but most of the time we keep the center of gravity close to ground which makes it difficult to flip. that’s intended behavior and can be changed. can’t say the same for the bike though, bike assist is a demonstration and you’re encouraged to roll your own solution if the bikes are an important part of your project.

1693

Hello! Is there any plan to add linux as a target platform? im interested in making a steam deck native build of my project.

1694

short answer is no but don’t forget that when you have the source code you can build on any platform.

1695

Hello,

I’m currently trying to add force feedback effects to a vehicle, such as different vibration effects on the controller when the vehicle collides with something or drives over a bumpy road (similar to the speed bumps in SandBox.map).

My idea is to monitor some key data of the vehicle in the “Tick()" function to determine its state and further decide whether to play the ForceFeedbackEffect. However, I’m not sure which data I should obtain to determine if the vehicle has collided or is driving over a bumpy road. Do you have any suggestions?

Additionally, I’ve tried adding a Box for overlap detection on the road to achieve the effect I want, but I feel like this approach might be too cumbersome.

1696

And handbrake not should block rear wheels always?, even with max 100 handbrake power, and using 6000 braketorque on rear wheel if you have accel pressed the rear wheels not stop and they should.

So i have to do this ( Added a bit of lerp to avoid sudden stucks)

if ( mHanbrakeInput && aRearWheels ) { 		 	          
mAxle->setTorqueShare(FMath::Lerp(mAxle->getTorqueShare(), 0.0f, 0.08f));}
else mAxle->setTorqueShare(FMath::Lerp(mAxle->getTorqueShare(), aTorqueShare, 0.2f));

Or maybe “handbrake power” is another thing to be deprecated and i should avoid it?

1697

handbrake power does not effect the brake torque but it scales the rotational acceleration of the wheel. if you’re pressing the throttle then it can eliminate some of the brake power and when combined with the tire friction it might still rotate. “handbrake power” can be used in an arcade setup but ideally it shouldn’t exist in a proper simulation.

1698

hi, for collision events I would stick to regular physics hit events and maybe do some filtering. getting the impact velocity/normal should give some information about the feedback scale.
about bumps it could be handled in a couple of ways but hard to tell which would work best. I would probably try to get each wheels local Z velocity and consider it a bump when it reaches a certain threshold. you could check wheel.getRayHit or wheel.getSuspensionCompressedLength etc. to calculate the vertical velocity. make sure you add some averaging to filter noisy data.

1699

@lazybitgames I may found a bug with Clutch.

in UFGearEngine::setFeedback you use:
float clutchPower = mTransmission->getClutchState();
if i understood well, thats just 0 to 1?, clutch power not should be like this?:
float clutchPower = mVehicle->getTransmission()->getClutchScale();

Seems clutchstate is always in 1 and only goes to 0 when gear changes.

In UFGearWheel::applyRpmLimit you set:
float clutch = mVehicle->getTransmission()->getClutchState();
In this case guess is correct? so limit goes t 0 to 1 apply to be able to change.

Also in UFGearTransmission::updateClutchState, mClutchScale is clamped to 0-100:
mClutchScale = FMath::Clamp(mClutchScale, 0.0f, 100.0f);

But in The BP, slider is 1-1000, so means it really only will affect until 100?

Can you double check please?