Physics Sub-Stepping

Hey everyone! Engine programmer has put together a great little post on physics sub-stepping for you guys. Hope you enjoy!
[HR][/HR]
One of the lesser known features in UE4 is the ability to turn on physics sub-stepping. By doing this you can get physics simulations that are more accurate and stable. The most noticeable improvement will be with ragdoll jitter and other complex physical assets.

Sub-stepping can be turned on in the project specific physics settings:

This feature is still a work in progress, and is not fully supported by APEX destruction. It is also currently not supported on mobile devices. However, we are working towards this as it can greatly improve the look and feel.

What does this do?

UE4 uses a variable frame rate. While this is good for hardware scalability, it creates a challenge for the physics engine, which works best with small fixed time steps. Sub-stepping takes the total frame time and divides it into sub-steps. The physics simulation is then ticked multiple times per frame. The number of sub-steps taken will depend on how small your max sub-step delta time is set to. The smaller the max sub-step time the more stable your simulation will be, but at a greater CPU cost.

How does it actually work?

Sub-stepping is completely hidden from the user, which means that some calls to the physics engine have to be interpolated or maintained. For example, if a user applies a force to an actor for a single frame, and the frame is internally sub-stepped N times, we need to apply the force for N consecutive simulation steps in order to achieve the same acceleration. Similarly, if the user sets the target location of an actor, we must interpolate the target location over multiple sub-steps in order to maintain the desired speed. All of these details are already handled internally by UE4, but there are some CPU and memory costs associated with the required bookkeeping.

Another technical detail to be aware of is the way collision callbacks behave while sub-stepping. UE4 runs the physics sub-stepping in a separate physics thread, allowing the game thread to continue doing work. In order to get the best performance we delay the collision callbacks until the final sub-step is done. This means that you can get several callbacks for the same collision. For example, if A collides with B and bounces off, you may get a callback for A and B overlapping AND a callback for A and B no longer overlapping in the same frame. Internally all callbacks are pushed into a queue and so callbacks from sub-step 1 will be processed before callbacks from sub-step 2.

Should I turn this on?

The answer depends on the needs of your game. If you are using complex physics assets it’s likely that you’ll see a significant improvement in quality by turning sub-stepping on. On the other hand, if the physics simulation is not as important to you as some other features, it might be CPU time better spent elsewhere. Either way, I would strongly recommend trying this feature out to see what kind of improvements it makes for your game!

Have questions? Let me hear about them below!

Which of these techniqueswould enabling this option be most similar to? I would prefer the “Free the Physics” method, as that seems to produce the most reliable results for a timing/physics-sensitive game like a platformer.

It’s been a while since the original post, so I was wondering on the status of physics sub-stepping being available on mobile? Thanks!

Thank You !

I recently tried Physics Substepping and wow! It made such a huge difference for my game where the player controlled unit is a physics simulating mesh!

Controls feel so much more fluid now!

Thanks !

And thanks Crystal for letting us know about it!

Rama

Hi ! It’s good to know that the sub stepping is not a true fixed time step. Could you direct me to the files you mentioned to attempt to make it a fixed frame rate as I’d like to experiment with it.
Also – could you elaborate a bit more on the technical limitations in doing a fixed frame rate in Unreal as I believe the time issue you’ve described can be solved using the interpolation technique described in the “Free the Physics” article unless I’m horribly mis-understanding something…

Explanation: If the physics is run 1 frame ahead then that remaining left over bit or time is the amount to interpolate between the last complete physics frame on the current side of the game update and the end of the first physics update on the next game update. Therefore the physics frame can be some small delta that fits n times into a normal render frame accumulating the left over time each render frame and using it for the next one using this idea of “the renderer produces time and the simulation consumes it in discrete delta time sized chunks”. The game layer can do its calculations using the render frame time as it wants to and will be given interpolated values from physics.
Does that sound valid?

Physics Substepping is very useful. I always use it if physics is involved.

I also increase the velocity iteration and position iteration in each actor’s physics tab.
Default is something like position iteration=8, velocity iteration=1. I usually go like 80 and 10. I noticed there is an effect, but I am not sure about the interplay of these iteration and substepping.
Can you elaborate on this?

Overall I am very happy with the physics at such high settings (substepping and velocity/position interation count).
I did pure ragdolling using the HeroTPP+PhAT and human-like swing/twist limits for the ‘joints’ and threw the HeroTPP down cliffs and whatever and the motion looked absolutely live-like.
And I am in the middle of creating a euphoria engine-like selfbalancing and powered ragdoll, with the intention of fully animation-free character control, that uses physics constraints and angular motors for ‘joints and muscles’ and a balancing AI. It works really well!

Only thing that is a bit annoying, is that PhysX multithreading seems to be limited to 2 cpu cores.

Would it be possible for callbacks to receive information about additional callbacks that might be firing in that frame? (Even just a number of callbacks would be enough) so that functionality that might rely on this info doesn’t break.

I use Sub-Stepping in a racing game and the effect is huge :slight_smile:

dev100000 sad something about position Iteration and velocity Iteration. This sounds interesting, is there a docu or can someone describe how it works ?

Thanks for the thread.

Out of interest, how much more expensive is this? I’m working on a hobby title where players control and command Physics-based Hovertanks (see here), and it’s Multiplayer. My calculation changes PhysicsAngularVelocity and PhysicsLinearVelocity directly, and I simulate the input over the network on the server and send authoritative updates back. (That way it feels nice and instantaneous for Clients).

Thing is, I eventually want to simulate up to a couple of hundred of these bodies in PS2 style games. Is sub-stepping going to help me or am I better off going down the fixed lockstep approach?

Is there a way to access each sub step from game code? For our car project, we’re doing our own engine/clutch/gearbox simulations. It would be great if we could do them every substep and not just once per frame in Tick (our current approach).

Yes, for our project we have added that feature and it should be present in engine versions 4.6 and up.

In the tick of component which you want to access sub-steps from the game, do this:



void URailroadWheelComponent::TickComponent(float DeltaTime, enum ELevelTick TickType, FActorComponentTickFunction *ThisTickFunction)
{
	Super::TickComponent(DeltaTime, TickType, ThisTickFunction);

	// Add custom physics forces each tick
	GetBodyInstance()->AddCustomPhysics(OnCalculateCustomPhysics);
}


This will call the delegate ‘OnCalculateCustomPhysics’ during next tick, for each substep (16 times for 16 substeps). Define delegate as:



FCalculateCustomPhysics OnCalculateCustomPhysics;
OnCalculateCustomPhysics.BindUObject(this, &UTrainPhysicsSimulator::CustomPhysics);


The delegate body is:



void UTrainPhysicsSimulator::CustomPhysics(float DeltaTime, FBodyInstance* BodyInstance)
{
	URailroadWheelComponent* RailroadWheelComponent = Cast<URailroadWheelComponent>(BodyInstance->OwnerComponent.Get());
	if (!RailroadWheelComponent) return;

	// Calculate custom forces
	//.....

	// You will have to apply forces directly to PhysX body if you want to apply forces! If you want to read body coordinates, read them from PhysX bodies! This is important for sub-steps as transformations aren't updated until end of physics tick
	PxRigidBody* PRigidBody = BodyInstance->GetPxRigidBody();
	PxTransform PTransform = PRigidBody->getGlobalPose();
	PxVec3 PVelocity = PRigidBody->getLinearVelocity();
	PxVec3 PAngVelocity = PRigidBody->getAngularVelocity();

	//......

	PRigidBody->addForce(PForce, PxForceMode::eFORCE, true);
	PRigidBody->addTorque(PTorque, PxForceMode::eFORCE, true);
}


You can contact me at #unrealengine (nickname ), this isn’t the correct account from which I should be replying.

1 Like

Thanks a lot, it’s exactly what i was looking for. Just to clarify for others, it’s not included in 4.6.1, but it is in 4.7

Physics sub-stepping is a great feature. Having the “free the physics” approach would be much better than the semi-fixed timestep however in my opinion. All physics-based game/simulation would greatly benefit of the fixed timestep and the reproducible physics of the “free the physics” approach. But it’s still an interesting feature.

One question though: do you plan to expose the “physics tick” of the sub-stepping in Blueprint ? That would be extremely useful. I have a case where enabling sub-stepping without having access to the physics tick breaks things… I’m going to explain it so you can have an actual example and might see the value in exposing it.

I’m trying to prototype a UAV simulator (quadcopter for now) using Blueprints. The modelling of the quadcopter is physics-based. What I mean by that is that the quadcopter has 4 thrusters (imagine a X shape with a propeller at each corner and I placed a thruster at each propeller’s location). The motion of the quadcopter is entirely controlled by the strength set for the thrusters. In this situation, if the object on which I have my 4 thrusters attached (my mesh) is perfectly balanced (if my center of mass is exactly at the center of the 4 thrusters), setting the same thrust value for each propeller will keep my quadcopter perfectly horizontal (no roll and no pitch). On the other hand, if I want to turn right, I increase the thrust on the left propellers and reduce the thrust on the right propellers. However, as with actual quadcopters, if I send a command to the quad to turn left by 10 degrees, I have no way to know how much thrust is needed to achieve 10 degrees (it’s a non-linear problem and it might depends on external conditions like wind for instance). So the solution is to implement PID controllers on each axis to control the motion correctly. For those not familiar with PID controllers, this is the idea behind it: let’s say I ask for a 10 degrees angle to the right (so target = 10 degrees) and my quadcopter is currently horizontal (so actual = 0 degree). We calculate the error (target - actual) and we use this error and some PID coefficients to compute a correction (the simplest case would be to compute a correction = constant * error). In my case, I produce a correction to modulate the propeller speeds, which in turn changes the thrust produced by each propeller. The next frame, the quadcopter will have started to move right, and it might be at 6 degrees. So the new error would be 10 - 6 = 4, and the new correction for this frame would be smaller than the previous frame so we can converge towards our target with a smaller and smaller correction until no correction is no longer needed when we are on target.

My control works great and the quadcopter moves as expected. I compute the error between the command (target) and the actual value (current orientation of the quadcopter), use my PID controller to generate a correction to be applied to the propeller speed, which varies the thrust of each propeller and correct the motion of my quadcopter to converge towards the target. To check that, I asked a target of 1 degree and looked at all the values in my simulation at each frame. In less than 10 frames the actual angle was on target (with a decreasing speed when approaching the targeted angle).

So here’s my problem now. When I came across this physics sub-stepping features (and the promise to get an improved physics), I turned it on. And my control stopped working. First, the actual angle seems to converge towards my target of 1 degree, but actually went much beyond the target. When I observe the speed at which it converged towards the target, it first slowed down (as expected since the error decreases, so the amount of correction at each new frame should decrease too) but after a few frames (5 or 6), the speed at which it converged increased. Basically, it does not work.

My guess is that the force is applied at each sub step, the new position/orientation is computed, and my physics simulation is going forward much faster, right? And since I’m doing my control only once by frame, the motion of my quadcopter basically goes uncontrolled during the sub-steps process. I compute a correction based on the current error right before starting a frame. With physics sub-stepping on, after one sub-step, my quadcopter had updated its position/orientation. Even though it’s now closer to the target, the same correction is applied once again (based on the position at the beginning of the frame). Instead, the correction should be reduced after each sub-step since we are getting closer to the target. If I had access to the physics sub-steps, I could update the correction between each sub-step.

Being able to implement the control within each sub-step would also allow it to be executed faster than only at each frame. In real life, the control loop of a quadcopter is executed at frequencies ranging from 100 Hz to 500 Hz. The quadcopter seems more responsive and the quality of the control is better. Doing the control in Unreal Engine at a higher frequency will see my quad to be more responsive too.

I think that giving users more control on the physics (and adding features like sub-stepping) is crucial for serious games. I’m new to UE4 and so far I’m very impressed by it. Keep the great work! We have a custom engine for doing surgical real-time simulation and we consider using UE4 for a few new projets we have (like this UAV simulator). Being able to implement our own physics in a decoupled way from the rendering is crucial. So I just wanted to let you guys know about that.

1 Like

You can try to avoid the tick for your PID controller and use a timer instead. The timer can tick at 100 Hz, probably much faster. This will maybe help a lot, but you still can’t predict physics exactly - Sadly, the time when the physics calculation starts is unpredictable.

Is it possible to access these sub-steps in blueprints? Some work is better done during the physics sub-step.

1 Like

Thanks. It seems like a good idea intially. But it wouldn’t work un my case. Executing my control faster is not sufficient. I need to be able to retrieve the position of my object at a faster rate too and it’s my understanding that the position is not updated between sub-steps. So I would need access to the tick of the sub-steps, the PhysX position and the ability to add force to the PhysX object too. I guess if I need to increase the frequency of my control (I have good results once per frame for now, even though I don’t like the fact it’s framerate dependent) I will go the C++ route then…

Could you post a more extensive example?

Hi I have a question: Do you think it is possible, to substepping physic with a constant delta time, and at the end interpolate the left over time? (just used in this frame, discard it and recalculate in next update).

How do you enable substepping and tie it to an update now? This no longer works, the BodyInstance->GetPxRigidBody(); is always nullptr and the bound function CustomPhysics() is never called. Yeah, substepping is enabled in project settings -> physics.

Epic please document this properly.

Enable Physic Simulation for body component. CustomPhysics should be called. For Actor, better use this function for Actors::Tick, we had some artifacts using it in Component.

1 Like