Friction force to counteract gravity and velocity causes object to slide down or jiggle

Development Asset Creation
, ,
1

Hello. I’m playing around Chaos and possibilities it provides. I’ve set up an actor, containing a static mesh component as a root, of mass 100 kg. The Actor is rotated 30 degrees to point towards ground. Also I’ve added a PhysicsConstraint component, locked the movement to X axis, as on image:

[Image Removed]

So the body moves under the gravity towards the ground.

Now I want to counteract this movement, by applying opposing force to stop the body in Tick, tick group is set to TG_PostPhysics:

FVector Velocity = Mesh->GetPhysicsLinearVelocity();
const double Mass = Mesh->GetMass();
FVector ForceToStop = -Velocity * Mass / DeltaSeconds;
Mesh->AddForce(ForceToStop);

This leads to body slowly, but constantly sliding towards the ground (video 2025-05-05 01-18-22.mp4).

So I’ve added a “warm start” - reapplying the force from last frame together with current force:

FVector Velocity = Mesh->GetPhysicsLinearVelocity();
const double Mass = Mesh->GetMass();
 
FVector ForceToStop = -Velocity * Mass / DeltaSeconds;
FVector ForceToApply = ForceToStop + LastApplied;
LastApplied = ForceToApply;
Mesh->AddForce(ForceToApply);

This looks better, but jiggles back and forth. This is almost unnoticeable at 120+ FPS, but pretty noticeable at 60/30 Hz.

Async Physics are not used, solver iterations set to 8/8/4, also tried 16/16/16, same result.

I’ve seen ChaosVehicles uses the similar formula for braking, in WheelModule:97

float ForceRequiredToBringToStop = MassPerWheel * K * (LocalWheelVelocity.X) / DeltaTime;But I still wonder, what is this K coefficient, and why it equals to 0.4, and how this helps in stability.

Some similar questions were asked here: [Wheel system [Content removed]

Then I set up a different and simpler test - an Actor with a Cube mesh as root, without a constraint, which falls to the ground. I was trying to counteract gravity by applying a force F = -mg. Apparently box slides down slowly too.

I’ve added a BP project (see attachments, EPS_Test) to reproduce the case: box with force counteracting gravity, box with constraint and counteracting velocity, box with constraint and counteracting velocity and warm starting.

Could you help on these questions? What am I missing?

p.s. to note, I had to disable Chaos sleeping globally, since I was working on bodies with way higher masses, e.g. 100-150 tons, otherwise they do not start moving after stop (too little force applied?)

2

Hello [mention removed]​

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

Thank you also for the repro project.

I’ve run it, and indeed, there’s some strong instability:

[Image Removed]I’ll investigate a bit and let you know.

All the best,

[mention removed]​

3

Hello [mention removed]​

I’m still investigating, but regarding the slowly falling cube (BP_BoxFalling on your repro), if you change to PrePhysics the cube stays put - zero movement.

Do you have a particular requirement to set this up on PostPhysics?

Let me know.

All the best,

[mention removed]​

4

Hi Bohdan,

This could be being caused by one of 2 issues.

  1. The constraints if they are on multiple primary axes (ie at an angle) can sometimes give slight errors - meaning the calculation is different to the one you are doing
  2. Calculating the forces/impulses are done out of step with the physics time delta (kind of like a 1 off error, but in time).

I’ll take a deeper look into this, likely next week

Best

Geoff Stacey

Developer Relations

EPIC Games

5

Hi Bohdan

I am going to ask the silly question here - just so that I can fully wrap my head around this use case :slight_smile: . Why not just set the velocity to 0? - The aim is to get a result where there is not velocity, so why not just set it to be that (or make the object kinematic so that is won’t move unless you tell it to?).

For the car wheel, this can’t be done because it is semi coupled, ie matched friction up until a maximum and then clamps the max value.

Agreed on the collision side - as you say the impulses are implicit - what are you trying to achieve there - assumedly you want the contact penetration resolved - but the object to remain stationary?

All the best

Geoff

6

Hello Geoff,

Imagine mine carts on rails in a gold mine, some of them are powered (i.e. locomotives). They are affected by gravity, can collide, can be coupled with spring constraints. I want to add brakes, and let carts stay on slopes (depending on the slope and how much brakes are applied).

You are correct, when simulating one cart:

  1. Calculate Gravity manually. Define NetForce = |Gravity Force + Throttle Force pushing| - |Brake Force|
  2. If Speed is not near zero, AddForce(NetForce)
  3. If Speed is near zero -> SetVelocity(0) + SetKinematic(true);
  4. If NetForce < 0 -> keep kinematic (gravity is not enough to overcome brakes)
  5. If NetForce > 0, SetKinematic(false), AddForce(NetForce) -> keep dynamic (gravity pushes more than brakes)

Simulating one cart is trivial

If there are other carts pushing with collision, I need somehow to take this into account, at least, if hit impulse was enough to put body out of kinematic state, e.g. if one cart has 100 N brakes applied, other cart cannot push it with 50 N force. So yes, contact shall be resolved, and both objects remain stationary. I assume this is doable with OnHit callback.

Another issue, if locomotive cart pulls other cart that has brakes applied (again 100 N). If locomotive has 50 N traction force, both carts shall remain stationary. If I release brakes, even not fully (e.g. 25 N braking force), locomotive shall pull both. I assume I would need to foreach all coupling constraints in world and check if GetConstraintForce was greater, than braking force of constrained carts and then set corresponding carts to be dynamic.

Instead of all these, I wanted to have generic solution, which would work regardless of forces/bodies around. Chaos Vehicle tires code does exactly this - counteracts movement. (despite I still wonder what is that K = 0.4 value there).

I tried to put Fixed constraint with linear motor, position target = 0 and velocity target = 0, when speed is near zero, made this constraint breakable, and this was not really stable, when speed goes back and forth near zero. Also, setting correct motor strengths can be difficult (maybe I need Force mode instead of Acceleration mode).

Another option would be creating own ConstraintContainer + Constraint type + make it highest priority - so a constraint which counteracts any movement, with the force available, but I doubt it’s possible to do so without changing the engine code (it’s not a problem per se, but I’m concerned that it’s not the best idea).

Best regards,

Bohdan

7

Hi Bohdan,

I’ve been chewing this over a bit, and although the vehicle is interesting as a way of stopping itself - I’m not sure it’ll work in your case. It looks like it is splitting the mass between the wheels, and _kind of_ iterating - that 0.4 seems to be lost to history, but there was a similar number used in an older physics engine for constraint resolution - so it could be from that thinking.

Your main issue is that there need to either be knowledge of the complete system (which is what the car is doing in a sense), or an iterative mechanism to handle convergence, but also with bearing in mind that this is partially coupled as well (ie linear, but up to a point and then constant if using basic friction)- which could put it into solver territory, and certainly engine level modifications.

What I am wondering though is if you could use the built in friction system, and couple these trailers together using a constraint - this would then use the core systems to accomplish what you are looking for. It would naturally iterate anyway, so that should scale - and if the objects are not too dissimilar mass wise this shouldn’t need extra iterations. I’m not 100% yet on the friction - we’d want it to provide an opposing force up to a maximum - the maximum would certainly work in the friction system, but it wouldn’t stop motion initially - but there could be a callback and a way of altering it mid-step we could use so that you still get as much of the build in physics as possible

I’ll come back to you when I’ve thought a bit more about the braking - but what are your thoughts on using friction for the ‘uncoupled’ part of the brakes (ie when there is enough force to overcome the brakes), and contraints for the trailers?

Geoff

8

Hi Bohdan,

At a high level, I’m leaning towards this needing some custom work in order to get this generic. Essentially, because this is a partial coupling (ie 0-Max), there will need to be some iterative solving going on - so if this were me I’d be looking to feed that into a solver.

What is the latest from your end on this?

Best

Geoff

9

That does sound very cool - when you get it working I’d be keen to take a look!

For the time being - any worries with getting this ticket closed off?

Best

Geoff

10

Absolutely. I (personally) love the idea of something similar to this concept in the future, but there is nothing on the roadmap. If that changes though I’ll let you know!

Best

Geoff

11

Hello [mention removed]​, thanks for the heads up. To note, I changed the original question a bit, since when I was investigating the issue, I stripped everything down to have just a falling box (rightmost on your video), which has AddForce(-m*g) and it still goes down (so constraint is not in charge here).

12

Hello [mention removed]​

Thanks for the heads up, I’ll make sure to check out the updated version.

Also, I had the page open, and the website does not refresh automatically, so I missed your reply, and only noticed it after I received an email notification about it.

I wanted to let you know I sent the other reply regarding BP_BoxFalling before seeing this.

All the best,

[mention removed]​

13

There was a reason with constraints, my idea was to let constraints settle in place first.

PrePhysics works. To note, should both Actor and Mesh have Pre Physics? I see that Actor PrePhysics + Mesh DuringPhysics works too

Other than that, is the difference in “Accel Change” flag is scaling by Mass only?

14

Hey, I also missed this message with no notification.. Anyway, yes, I’ve read about BoxFalling, PrePhysics helps there.

For the best example of tilted boxes - try one without “warming”. I assume gravity affects the body each frame, but I still want to somehow brake the body, by applying some “braking force”

15

Hello [mention removed]​

As Event Tick is running on the Actor, I believe you need to set it’s Tick Group to Pre Physics.

It looks like the Tick Group of the component does not matter in this particular case.

When enabling Accel Change you don’t need to worry with the Mass:

[Image Removed]Since the gravity acceleration is known and exact, this setup will make the box stop completely.

Let me know if this is enough for your particular use case or if you need further assistance!

All the best,

[mention removed]​

16

Thanks for the help!

For the mentioned box falling it works, just tested.

But for the constrained box generic movement stop (based on -Velocity * Mass), I still did not find a clean solution (see below).

I’m simulating a bead on a wire (box + constraint to local X axis), which is being moved by gravity + external forces, and is able to apply “brakes” to stop. My idea is to apply a force, that will stop the box from moving (including gravity and inertia). Such force shall be clamped against brake force available (how much it can put to stop, so how much brakes are applied).

I found the aforementioned code in Chaos Vehicles, where a force to stop the wheel is calculated every frame, also taking into account available slip etc.

I think the math behind this is applying a force equals to -Velocity * Mass / DeltaSeconds (or an impulse = -Velocity * Mass), but apparently it’s not enough to stop the bead on a wire (box with a constraint). I assume that happens because gravity was already taken into account in a physics tick and moves the box before it being pushed back by my AddForce call

Technically, I could simulate gravity myself, something like:

FVector CurrentVelocity = Box->GetPhysicsLinearVelocity();
 
const FVector GravityForce = FVector(0, 0, -980) * Mass;
const FVector NetPushForce = ExternalPushForces + GravityForce;
const double BrakeLimit = 100000; // 100 kN
 
FVector PushForceAlongWire = FVector::DotProduct(NetPushForce, Forward) * Forward; // project push force to wire tangent
 
CurrentVelocity += PushForceAlongWire * DeltaTime / Mass; // Integrate external forces to properly calculate friction
 
const FVector ForceToStop = (-CurrentVelocity * Mass / DeltaTime).GetClampedToMaxSize(BrakeLimit ); // Force that is needed to stop a box after gravity applied
 
const FVector FullForce = PushForceAlongWire + ForceToStop; // Full force is push + clamped friction
 
Box->AddForce(FullForce);

This works, actually as expected, but I feel like it shall be possible to do easier, and not cheating the physics, gravity and velocity integration (why it’s not enough to AddForce(-Velocity*Mass/dt?)

17

Hello [mention removed]​

To me, it looks like a control problem: we are trying to stabilize a system with a delay.

By the time the counter velocity calculated from the return from GetPhysicsLinearVelocity() is applied, the actual velocity has changed, and this would cause the slow slide.

If you calculate the gravity effect and the friction in one go, it makes sense that the result is exact.

The overshooting/oscillating behavior we get when trying to compensate (the warming start BP) is also something that we commonly see on unstable control systems.

I’ve read a bit about friction in game physics, and this is far from a solved issue.

Let me know if you want me to escalate the case to Epic; someone from the physics team might provide a different perspective.

All the best,

[mention removed]​

18

Hello [mention removed]​

More I think about this, more I agree to you - the issue is applying Friction as an aftermath.

And as far as I understand constraints, it’s not possible to apply friction force when calculating displacement needed to satisfy constraint, if I understand PBD/XPBD correctly, firstly position constraints are satisfied, and then velocities/forces are derived from that displacement.

If we could, I think it’s a good idea to ask Epic engineers as well, because something similar (calculating stopping force) is in Chaos Vehicles. The generic question is “How to apply friction on constrained bodies movement”. I tried motors with velocity target and altering max force limit, but I doubt I used them correct.

Thanks

19

Hello [mention removed]​

Sure, of course, we can escalate.

I’ll do that now.

Thank you again for reaching out.

All the best,

[mention removed]​

20

One more example of the behavior:

There are 2 boxes, both are constrained to world X axis with constraint. Green box adds (100, 0, 0) force every frame, so it tries to push Red box. Red box applies a non-clamped braking force. And it never stops, and moves with 3.33 cm/s @ 30 FPS and 0.833-1 cm/s @ 120 FPS.

Red box brakes as discussed earlier:[Image Removed]I’m looking for applying a friction without a contact (friction is normally simulated when contact exists).

Create a dummy contact maybe (to apply friction earlier)?