Chaos Vehicle overwriting shared wheels torque ratio

Development Asset Creation
, ,
1

We’re facing a weird issue with Chaos Wheeled Vehicles. It looks like vehicles can override the torque distribution for wheels for other vehicles, changing their driving characteristics at a glance.

I’ve mostly tracked this down to the usage of the FSimpleWheelConfig. It looks like this is shared data, i.e. it’s only created once for the wheel CDO and then shared amongst all instances for wheel simulations:

Engine/Plugins/Experimental/ChaosVehiclesPlugin/Source/ChaosVehicles/Private/ChaosWheeledVehicleMovementComponent.cpp:1400

`UChaosVehicleWheel* Wheel = WheelSetups[WheelIdx].WheelClass.GetDefaultObject();

// create Dynamic states passing in pointer to their Static setup data
Chaos::FSimpleWheelSim WheelSim(&Wheel->GetPhysicsWheelConfig());`Now, the catch is that the CDO is of course “const”, and it’s stored as const in TVehicleSystem<>, BUT for some reason, TVehicleSystem<>:AccessSetup() returns a non-const reference to it! This breaks the whole const CDO contract, and I don’t see any documentation about why this happens and how this is guaranteed to be safe.

Now, as the wheel setup isn’t const anymore, there are several locations where the setup object is modified, like at

Engine/Plugins/Experimental/ChaosVehiclesPlugin/Source/ChaosVehicles/Private/ChaosWheeledVehicleMovementComponent.cpp:1425

WheelSim.AccessSetup().EngineEnabled = EngineEnable;or at Engine/Plugins/Experimental/ChaosVehiclesPlugin/Source/ChaosVehicles/Private/ChaosWheeledVehicleMovementComponent.cpp:1508

PWheel.AccessSetup().TorqueRatio = TorqueRatio;We’re especially suffering from the torque ratio, as different vehicles have different drivetrain setups, and this just “randomly” sets the value to whatever the most recent spawned vehicle wants it to be.

As the engine simulation uses the torque ratio, all vehicles are indirectly affected by this, at Engine/Plugins/Experimental/ChaosVehiclesPlugin/Source/ChaosVehicles/Private/ChaosWheeledVehicleMovementComponent.cpp:880

PWheel.SetDriveTorque(TorqueMToCm(TransmissionTorque) * PWheel.Setup().TorqueRatio);

Now, looking at this whole situation, I’m not sure if someone did mix up access to those values, as the FSimpleWheelSim PWheel itself has the same values declared as fields! So I wonder if the Setup() access is even correct and instead, the values should be set directly on the FSimpleWheelSim instances.

I’ve also looked into Perforce, and the most recent version of the vehicle simulation still has the same logic, so I guess this may happen on 5.5 as well.

I wonder, are my thoughs correct about this? Maybe I’m missing something crucial here.

2

Hello [mention removed]​

Thank you for reaching out and bringing this issue to our attention.

I’ve checked the ChaosVehiclePlugin, and since UE5.0, SetupVehicle had the same WheelSetup fetched from the CDO.

If you have different characteristics between wheels, I assume the system expects you to have a single ChaosVehicleWheel type for each.

Would it be possible to create a minimal project that illustrates the issue you are describing?

I’ll also ping the Epic team about this because I believe the physics team is putting development effort into the ChaosModularVehicle plugin, and ChaosVehiclePlugin might not be actively developed.

All the best,

[mention removed]​

3

Hi Rafael,

After discovery of this issue we’ve settled to work around this issue by separating wheel classes per vehicle type to ensure there is no cross-talk between the vehicles.

In case the ChaosVehiclePlugin may be deprecated and superceded by the modular vehicles plugin it may not be worth the effort to look for a proper solution here. A reproduction may be easily configurable from the samples but I currently lack the time to put it together.

4

Hello [mention removed]​

I’ve asked Epic, and they confirmed my observation that most of the devs’ time is dedicated to the Chaos Modular Vehicle Plugin.

They haven’t said the Chaos Vehicle Plugin is deprecated, though, so we are still providing support.

I’ll open a ticket so this issue is fixed regardless.

Will share the trackable link once I have it.

All the best,

[mention removed]​

5

Hello [mention removed]​

Thank you again for reaching out and reporting this issue.

I’ve made a JIRA report to be added to the Unreal issue tracker website (https://issues.unrealengine.com).

Epic will decide if the issue will be made publicly accessible, and the whole process can take a few days, so keep that in mind.

If/once it is made publicly available, you will be able to track the resolution by checking this link:

I’ll close the case, but feel free to reply if you have anything else to add.

All the best,

[mention removed]​