normally developer is expected to have a vehicle BP and set the input type at design time but if you’re building from source you can set the default input type to enhanced by modifying the constructor(line 15). after that you can use the setters for the mapping context and the input actions. there is no setter for input type because it doesn’t make sense to change it at runtime.
I have experimented on various differential types and it’s quite difficult to make it right.
after all parts of the drivetrain is in place I could work on torque vectoring maybe as a driving assist.
1 Like
@lazybitgames Hi, how can I make the steer return to center quickly? I’d like it so that when I’m turning and release the keyboard/gamepad, the return to center is faster.
@Y34GHDI36 Increase the steer input gravity, on the standard input component.
1 Like
@lazybitgames In UFGearWheel::myFixedUpdate, there is the torque.Y feedback this line:
torque.Y += mLongitudinalForce.Size() * -FMath::Sign(mWheelTorque) *(mBraking > 0.0f ? 0.3f : 1.0f) *mRadius;
Commented is:
“when braking take brake disc radius into account(~%30)” Related to:
*(mBraking > 0.0f ? 0.3f : 1.0f)
After some research seems this should be higher or better if customizable with mBrakeDisc for example. So we can change in BP the brake disc radius in front/rear wheels and not a fixed 0.3.
Also it goes from 0.3(brake disc) to 1.0 sudden, not will be more smooth/accurate if lerped? Like:
*FMath::Lerp(1.0f, mBrakeDisc, mBraking)
And to be full physical accurate maybe mBraking should be squared or similar instead of linear.
What you think?
for an arcade simulator a parametric brake disc radius sounds a bit overkill that’s why I did some kind of approximation there.
nevertheless any attempt to remove constants in the code is always an improvement and it’s quite easy to add so why not.
1 Like
Another small thing, more related to extras.
In vehicle, Actor and component tick are “Pre Physics”. This make skidmarks lag, which can be fixed if FGearEffects get his own component tick set as “Post_Physics”.
Change will be: telemetrydrawer by USceneComponent:
.cpp = UFGearEffects::UFGearEffects() : USceneComponent(),
.h = public USceneComponent
Is a silly thing, but in order to test/show the project demo to possible buyers it not looks there is a issue/broken.
2 Likes
@lazybitgames Have you fixed the ABS Accel+Brake bug?
If im right on ABS happens two major things:
- The scaler to down:
float scaler = 1.0f - mVehicle->getABS();
deltaV *= FMath::Max(scaler, 0.001f);
Tried disabled and bug still there.
- mLngSlipOverride
if (FMath::Abs(mLongitudinalSlip) < FMath::Abs(mLngSlipOverride)) mLongitudinalSlip = mLngSlipOverride;
Disabled and bug fixed.
-
Guess due optimal slip in the moment brake is pressed, gets better traction = more speed ¿?
With the bug, with 100% ABS, im able to go from 1st gear, 20% throttle, at steady 20km/h to 3rd gear(90km/h) braking around 1-20% .
This makes that in some scenarios when you use light brake/accel for some corner corrections car not behaves fully as expected.
-
Also another thing that increases the speed when not should is moving left/right the steering, we talked time ago but bug still there(i confirmed your guess was correct), to be clear this one:
Maybe is already fixed in the big update, just in case.
abs bug is fixed.
steering bug is not, it’s not possible to fix it with the current drivetrain but it is fixed in the big update branch.
1 Like
hello @lazybitgames I’m using splitscreen mode, but the player 2 car controller isn’t working. Any suggestions?
@lazybitgames About “Force Symmetry”, In theory it makes the curve symmetric, left/right/up/down.
I zeroed the shift factors:
Longitudinal: PHX & PVX,
Lateral: PHY, PVY & PEY3-5
Combined Longitudinal: RHX1
Combined Lateral: RHY & RVY
Aligning momment: QHZ
Now curve is the same with Force symmetric on/off. Also set Mx/My/Mz to 0 just in case.
But on/off still does a different behaviour when hits the max slipRatio/Angle, if keeps on limits does the same. For quick tests what i do is just hold down+left, and car does different behaviour when starts to slide.
Can you check please?
Checked the mForceSymmetry function on the tire model .cpp but not understand vey well what exactly does or if also does anything else in other component.
Also maybe im missing some param that needs to be zeroed to avoid that difference but after all day testing cant get the same. Curves are the same on/off but maybe some stuff is not represented like the camber but cant find what can be, so wonder if maybe the force symmetry is doing something wrong ¿?.
What im experimenting is that if checked the car slips more, like gets into max slipratio/angle faster than without. if Unchecked, the car has more grip and turns faster. I zeroed comb.longitudinal as default tire and as said zeroed all that can shift but still on/off slipratio ingame behaves different.
Tomorrow will try from scratch using tire96 to see if maybe the problem is only with 61.
if the tire model is not causing any issues then do not use force symmetry.
forced symmetry is a made up concept which forces the tire model to only have positive slip as input and negate the result if the slip was originally negative. this could cause discontinuity on the curve but it shouldn’t be a problem if the shifts are small.
sorry I never worked on split screen before so I have no idea at this moment.
@lazybitgames Regarding the issue where the physical material’s roughness value does not influence the vehicle’s skidding/sliding calculation:
I believe we discussed this previously, but I didn’t give it much attention at the time because my main project is a slow-paced hill-climbing game. However, I am now developing a small rally game on the side, and the problem has become much more apparent and frustrating.
A practical example: The vehicle is on asphalt (Friction 1.0 / Roughness 0.1) and enters a gravel road (Friction 0.5 / Roughness 0.6). The damping works correctly, and the sensation of terrain change is great. However, as soon as the car starts to slide (powerslide or skid), it feels as if it were on a very slick surface (e.g., Mud (Friction 0.4 / Roughness 0.0)). This is because the roughness value appears to be ignored in the lateral slip calculation, making the rally gameplay unrealistic and practically unplayable.
Would it be overly complex to include the material roughness in the slip/skid calculation, in conjunction with the friction value?
If this is a simple fix that you can share with me here before the next plugin update, I would be very grateful.
Thanks
P.S.: I’m also sharing my table with the values I use for terrain types, it might be helpful for anyone who needs reference values.
Friction and Roughness Coefficients (Simulation Scale 0-1)
| Surface | Condition | Friction | Roughness / Damping | Simulation and Usage Notes |
|---|---|---|---|---|
| Asphalt | Dry | 0.90 – 1.00 | 0.10 – 0.20 | Maximum grip and minimal vibration. |
| Asphalt | Wet | 0.50 – 0.70 | 0.05 – 0.15 | Hydroplaning risk. Compromised grip. |
| Gravel | Dry/Compact | 0.65 – 0.75 | 0.60 – 0.80 | Decent friction, high Damping (Energy Absorption). |
| Gravel | Wet | 0.50 – 0.65 | 0.50 – 0.70 | Less loose, but more slick gravel surface. |
| Dirt | Dry/Compact | 0.60 – 0.75 | 0.30 – 0.50 | Good base for off-road driving. |
| Dirt | Wet/Muddy | 0.30 – 0.50 | 0.50 – 0.75 | Wet dirt reduces friction and increases drag/resistance. |
| Mud | Deep/Slick | 0.15 – 0.40 | 0.70 – 0.90 | Very low friction, extremely high Damping. Tire sinks deep. |
| Sand | Dry/Loose | 0.40 – 0.55 | 0.60 – 0.80 | Requires wide tires and low speed. |
| Sand | Wet/Packed | 0.60 – 0.70 | 0.20 – 0.40 | Water compacts the sand, improving grip and reducing Damping. |
| Grass | Dry | 0.50 – 0.60 | 0.30 – 0.50 | Reasonable friction. |
| Grass | Wet | 0.20 – 0.40 | 0.20 – 0.40 | Extremely slick (similar to thin mud). |
| Rock | Dry/Clean | 0.60 – 0.85 | 0.10 – 0.30 | High friction, low Damping (hard surface). |
| Rock | Wet/Mossy | 0.30 – 0.50 | 0.05 – 0.20 | Water or moss makes rocks treacherous. |
| Cobblestone | Dry | 0.75 – 0.85 | 0.40 – 0.60 | Constant vibration (high Damping), good tire friction. |
| Cobblestone | Wet | 0.55 – 0.70 | 0.30 – 0.50 | Irregular surface retains water. |
| Snow | Fresh/Powder | 0.10 – 0.25 | 0.50 – 0.70 | Low friction, high Damping (car sinks). |
| Snow | Packed/Compact | 0.25 – 0.40 | 0.20 – 0.35 | Better grip, lower Damping (harder surface). |
| Ice | Pure | 0.05 – 0.15 | 0.01 – 0.10 | Almost no friction. Very low Damping. |
| Ice | Black Ice | 0.00 – 0.10 | 0.00 – 0.05 | The most slippery and dangerous state. |
| Concrete | Dry | 0.80 – 0.95 | 0.15 – 0.25 | Similar to asphalt, slightly rougher. |
| Concrete | Wet | 0.50 – 0.65 | 0.10 – 0.20 | Good water runoff. |
3 Likes
currently the drag force calculation is generated for both longitudinal and lateral movement so your assumption is wrong.
the current implementation is a pseudo force which is meant to be used for cases like a vehicle entering the sand around the track, for loosing a lot of momentum and to force a slow movement not meant to be used for all cases. that’s why it’s quite simple, just a linear drag force which is calculated based on drag factor, load and velocity.
in your case you can try scaling the lateral and longitudinal components of the drag force separately. for instance to duplicate the lateral component of the drag force go to UFGearWheel::calcWheelDragForce and modify it like the following:
if (mHasContact && (mGroundVelocity.X != 0.0f || mGroundVelocity.Y != 0.0f))
{
FVector horizontalVel = mGroundVelocity;
horizontalVel.Z = 0.0f;
horizontalVel.Normalize();
horizontalVel.Y *= 2.0f; //2x lateral drag
float dragFactor = mInherentDrag + mAdditionalDrag;
if (dragFactor < 0.0f) dragFactor = 0.0f;
float widthFactor = mWidth / 0.3f; //30 cm width assumed as average
float loadFactor = mCurrentLoad / 3000.0f; //300kg load assumed as average
return -dragFactor * widthFactor * loadFactor * mGroundVelocity.Size() * horizontalVel;
}
Thank you very much, I will test some values until I find something more coherent for my game.
Perhaps it would be interesting to expose these variables, in order to create variations of tires (street, off-road, snow, etc.) in a more arcade-like way, since it is not possible to change the physical material during runtime. For example, an off-road tire would increase friction and damping, which would make the vehicle more maneuverable on dirt roads and slower on asphalt.
No minor update/compatibility for 5.7 (a month ago)? Or trying to push the big update next? No hurry from side, just asking, i only will update on the big one.
v1.8.4 is now available
- Unreal 5.7 support
- Ability to change vehicle mesh at runtime
- Improvements and bug fixes
Notes
- Fixed the problem where the ordering of axles was shuffled. This could cause issues when you have 4 or more axles. The axles are sorted based on their distance to the front axle now. Additionally you can call Vehicle.setAxleIndex to alter the indices at runtime.
- Removed the call to mesh.SetAllBodiesSimulatePhysics(true) in vehicle beginplay. In certain cases you may not want a vehicle part to be simulated so from now on users should manage all the bodies themselves.
- Fixed the issue where time dilation could break the simulation.
- Fixed the order of torque components in MF6.1 tire model.
- Fixed FGearUtility::Euler function which caused some rotations like camber to be inverted.
- Vehicle’s Super::Beginplay call is moved to the end of the beginplay function. This may prevent some crash cases.
- Reference camber value is added to tire models. You can preview the effect of camber angle in the tire model blueprints now.
- Updated tire96 and mf6.1 tire models. Certain inputs and intermediate values are clamped based on original equations.
- MaxHillHolderSpeed variable is now serialized, can be saved/load via json.
- Fixed the bug where partial throttle + partial brake could lead to faster acceleration when ABS is on.
- Effect components tick group is set to post physics now.
- Improved torque.Y calculation in wheel class. Instead of blindly checking for brake input we now make sure the vehicle is decelerating.
- Improved activation/deactivation of hill holder. It won’t activate on a flat surface and it can deactivate if the slope angle changes after activation.
- Vehicle.setMesh function can be used to change the vehicle mesh. You need to provide the new mesh, animation bp and physics asset references. If the bone names differ then you also need to change the bone name parameter of each wheel.
- Fixed a problem with the auto clutch where it failed for the rear gear in manual transmission mode.
2 Likes
Wow nice improvements! i may update now then, the abs bug fixed and a new torque.Y calculation among others. Still no eta for the big update?
Also maybe update forum thread too, is “FGear Vehicle Physics (v1.4)” and we already on 1.8.4.
-
Just updated to 5.7 and 1.84:
1: The cam behaviour changed in any way? Now on accel/deccel seems it moves to much makes me feel a bit dizzy. ¿? Cant explain what is it, will continue testing.
Is like it changes the tilt on accel / brake / reverse in some way ¿?
EDIT: About the cam i found this difference between 1.82/1.83 and the new 1.84
//float tilt = mTarget->GetActorRotation().Euler().Y + mTiltAngle; // 184
float tilt = mTarget->GetActorRotation().Euler().Y - mTiltAngle; // 182 & 183
if (cspring > 0.0f) mCurrentTilt = FGearUtility::LerpAngle(mCurrentTilt, tilt, cspring * deltaTime);
//else mCurrentTilt = mTiltAngle; // 184
else mCurrentTilt = -mTiltAngle; // 182 & 183
I tried to revert and change some values in the BP but nothing, also on turn seems also tries to stabilize and you cant see the car really swing when zig-zag fast i dont know how to explain, is weird now.
Maybe is due Unreal 5.7 that does something different, later or tomorrow will do more tests.
EDIT2: Tested in 5.6 and cam does the same with 1.84, it changes the tilt with chasis movement, something not happened in 1.82 & 1.83.
So i guess is intentional?