Download

Found bugs

In this thread I will post all the bugs I find.

Engine\Source\Runtime\Experimental\ChaosVehicles\ChaosVehiclesCore\Private\WheelSystem.cpp

Line 120

// use slip angle to generate a sideways force
			if (Setup().LateralSlipGraph.IsEmpty())
			{
				float AngleLimit = FMath::DegreesToRadians(8.0f);
				if (SlipAngle > AngleLimit)
				{
					SlipAngle = AngleLimit;
				}
				else if (SlipAngle < AngleLimit)
				{
					SlipAngle = AngleLimit;
				}
				FinalLateralForce = SlipAngle * CorneringStiffness;
			}

This is a simple signed limit, but the code is missing two minus signs so actual says

SlipAngle = AngleLimit;

Code should be

// use slip angle to generate a sideways force
			if (Setup().LateralSlipGraph.IsEmpty())
			{
				float AngleLimit = FMath::DegreesToRadians(8.0f);
				if (SlipAngle > AngleLimit)
				{
					SlipAngle = AngleLimit;
				}
				else if (SlipAngle < -AngleLimit)
				{
					SlipAngle = -AngleLimit;
				}
				FinalLateralForce = SlipAngle * CorneringStiffness ;
			}

This code actually looks wrong to me anyway.
What I am seeing is that once the speed of the vehicle gets above 55KPH, you lose all grip and the vehicle spins out.

2 Likes

Another none obvious problem.

In
Engine\Plugins\Experimental\ChaosVehiclesPlugin\Source\ChaosVehicles\Private\ChaosVehicleMovementComponent.cpp

Around line 280 , you have this code

    // Work out velocity at each aerofoil before applying any forces so there's no bias on the first ones processed
	for (int AerofoilIdx = 0; AerofoilIdx < PVehicle->Aerofoils.Num(); AerofoilIdx++)
	{
		FVector WorldLocation = VehicleState.VehicleWorldTransform.TransformPosition(PVehicle->GetAerofoil(AerofoilIdx).Setup().Offset * Chaos::MToCmScaling());
		VelocityWorld[AerofoilIdx] = GetWorldVelocityAtPoint(RigidHandle, WorldLocation);
		VelocityLocal[AerofoilIdx] = VehicleState.VehicleWorldTransform.InverseTransformVector(VelocityWorld[AerofoilIdx]);
	}

Notice that the offset is multiplied by Chaos::MToCMScaling() , so the value in the setup is not in the standard 1 == 1cm coordinate set

This caused me immense problems as my vehicle accelerated to 30 KPH and then left the planet

EPIC Games: ‘Please stay on the line. Your call is important to us’. :stuck_out_tongue:
Seriously… You have to formally file bug reports to get Epic to act. :wink:
The challenge is the bug report form itself is a bit em- challenged. :grin:

I am doing this so other coders that have problems have solutions available.

EPIC will be reworking all this code multiple times before UE5 goes live

2 Likes

:+1:
FYI: Normally Rama starts transition threads where everyone can pool samples… Here’s 4.26. So expect to see more for 4.27 & UE5 eventually, if there isn’t EA5 C++ one already.

Hey @PaulBlythe . I also found the same bug + submitted a bug report. On UDN, Epic games confirmed it’s a bug but they have been using the Lateral slip graph instead that overrides that part of the code.

I believe I found another bug in the Arcade Control systems( UChaosVehicleSimulation::ApplyTorqueControl) where the wrong “Enabled” flag is used (submitted bug report).
The code checks the Torque Control Enabled flag and then has another if branch after that checking it again, while it doesn’t check at all the Target Rotation Control flag despite the fact that everything under that branch has to do with parameters defined under the Target Rotation Control section).

So I think the correct code should use the Target Rotation Control “enabled” flag in the 1st if branch.

Do you know of any working examples of this? Since the advanced vehicle demo doesn’t use it I’m guessing they’re talking about fortnite or something? I’ve tried using the graph and the other way with Paul’s fix and no matter what I do the wheels lose grip around 50mph as Paul noted.

I am still looking into this, one thing you can do in the short term is increase CorneringStiffness massively

I saw in some EPIC test code that they were multiplying it by 10,000 so I tried it and it does have an effect

So found out what the problem is, but not the cause yet.

I reinstated the debug displays and did some testing.

When the vehicle is stationary, the down force in the wheels looks … well wrong, but sensible

As you accelerate it decreases and even goes negative, so the vehicle is flying.

No surprise you can’t corner

1 Like

That would explain it. No matter how much I increased the frictions it wouldn’t corner, but acts really weird (jerking) while making the contact(s) with the ground. I’ll look around a bit, just short on time the next few days…

I’ve switched to VR land for the meantime, but here’s a few things I’ve checked…

Disabled the forces in the following with no luck.

ApplyAerodynamics(DeltaTime);
ApplyAerofoilForces(DeltaTime);
ApplyThrustForces(DeltaTime);
ApplyTorqueControl(DeltaTime, InputData);

ApplyAerodynamics was the only one that tried adding a force but it was small and didn’t change anything noticeably when I disabled it.

I turned on the debug visuals but I didn’t see the up forces on the wheels, just lat and long… they did seem clamped around 50mph but I’m not sure if that’s just the debug version or a true clamping of the frictional forces.

1 Like

I think I found another one but wanted to see what people think. If we have an AWD vehicle and the FrontRear split is e.g 0.5 then I would expect the total Transmission torque to be evenly distributed between all 4 wheels, right? But in the code below it would multiply the total transmission torque by 0.5 (so divide the torque by 2) and then also divides by all wheels. So in the end it’s dividing the torque by 8.

Example : Let’s say transmission torque is 100 and front-rear split is 0.5 in an AWD vehicle with all wheels affected by engine. For the front-left wheel we do TransmissionTorqueSplitTorque/ numWheels = 1000.5/4 = 12.5. I think in that scenario the result should be 25 instead, right>?

Yes that is a bug.

Why you’re not creating pull requests in GitHub? Writing those code pieces here won’t help anyone I believe.

I am doing both, but want to get some feedback/ other people’s views on whether something is indeed a bug first.