[Resolved] PhysicTick in 2019 with UE4.25.3 (not UE4.15 or UE 4.24)

Hello,

I am writing this post after 2 weeks of research and several tests.

I need to execute the physic exactly 120 times per second. I don’t just need to make the physic execution independent of rendering. I need it to run physic at precisely 120 executions per second . And that regardless of the frame rate. AND : the physical state of my game need to be the same after 10 seconds at 20 FPS and 120 FPS.

I want to warn that there are several sources on the subject but that these sources are old and I’m pretty sure that the engine has evolved since then.

Proof of this evolution: before, in UE4.15-, you could call a “PhysicSubStep” on an actor. Now: we call a “PhysicSubStep” on a scene.

These sources in particular seem to me obsolete:

Here is why I want to run physics 120 times per second.

I try to build an efficient Netcode like the one described by Rocket League Team in this video It IS Rocket Science! The Physics of Rocket League Detailed - YouTube

To achieve my ends I absolutely need to have a fixed time step for physics.

As you can see at the bottom right of the photo “Rocket League Stat” they use 120 Physic Tick per second (regardless of the FPS rate). And they are able to control the speed of client side physic frame rate from the server. They can make it go faster (122 / secondes) or slower (118 / seconds) depending on the size of their server side input buffer.

Server and clients communicate with physic frame numbers instead of a synchronized clock.

I need to run physics at the same rate on the server and on all clients.

My target is 120 physical executions per second.

I already have activated the “SubSteping” function.

This feature is very useful because it allows to make physics independent of rendering.

I have attached a photo of my configuration:

I am now trying to access what I call the “PhysicTick”.

I’ve tryied to connect a function that I called “SubstepTick” to a callback of the PScene-> OnPhysSceneStep engine using the following line of code:
OnPhysSceneStepHandle = PScene->OnPhysSceneStep.AddUObject(this, &UPhysMeshComponentCUSTOM::SubstepTick);

I think I succeeded but I am very amazed because when I log I realize that my function SubstepTick (in which I’ve integrated AddForce) is running at the same rate as my render (at 120 FPS it performs 120 times my SubStepTick function, and at 20 FPS it executes 20 times my function).

You can check my C++ code in the pic “CAS 1 CallBack Method”

Still: my physique seems to run with the same result at 120 FPS as at 20 FPS.

To do tests, I built a Level in which I’ve inserted a start line and a finish line.

I measure the time it takes for a ball to roll from the start line to the finish line at 120 then 20 FPS using an addForce place in my SubstepTick function.

The time is almost the same at 0.012s difference.

What I don’t understand is that my function which runs physics was played 6 times more at 120 FPS than at 20 FPS. Yet the result is the same.

Take a look at my pic “CAS 1 CallBack Method” photo which shows this simulations (at the top left of the screen, we see “Temps Total” (Total time in french) which corresponds to the travel time of the ball between the 2 lines).

In the upper part of the pic you will see the simulation at 120 FPS. In the lower part you will see the simulation at 20 FPS. And on the right you’ll see the C ++ code that I used to take measurements of what’s going on while displaying 120 images.

This result does not suit me as I actually need the physics to run at a fixed rate and in this case I feel like UE4 is weighing the forces to add instead of actually fixing the execution step. At the bottom of the pic in the “Output Log” I measure the number of times my SubStepTick function was called while displaying 120 images.

So I tried to manually build a Fixed Physic Tick system by taking inspiration from Fix Your Timestep! | Gaffer On Games

This time I get a fixed execution step: 100 executions per second. It’s perfect. But: when the game is running at 120 FPS the ball travel takes 19.48 seconds while at 20 FPS the ball travel only takes 7.8 seconds. See photo “CAS 2 Gaffer on Games Method”

I don’t understand how this is possible ??
Whether I am at 20 FPS or 120 FPS I perform my physique 100 times per second and yet I get different results.

How can we get UE4 to run physics 120 times per second and still get the same result for actors locations at any frame rate?

Out of curiosity, I performed a test under Unity and I managed to run the physics 120 times per second (I used the “fixed update” function and I have forced the Time.FixedDeltaTime to 0.0083333 = 1/120). At 20 FPS or 120 FPS the ball takes exactly the same time to go from the start line to the finish line (with an accuracy greater than 5 digits behind the decimal point).
See “CAS 3 Unity Test”

How do I get the same on Unreal Engine? And how do you set the “Physic Tick” at 120 times per second and get the same physical result regardless of the rendering?

Up plz help :slight_smile:

Problem is different countries run different systems and refresh rates, according to the local electricity power companies generators.

NTSC is an abbreviation for National Television Standards Committee, named for the group that originally developed the black & white and subsequently color television system that is used in the United States, Japan and many other countries. An NTSC picture is made up of 525 interlaced lines and is displayed at a rate of 29.97 frames per second.

PAL is an abbreviation for Phase Alternate Line. This is the video format standard used in many European countries. A PAL picture is made up of 625 interlaced lines and is displayed at a rate of 25 frames per second.

SECAM is an abbreviation for Sequential Color and Memory. This video format is used in many Eastern countries such as the USSR, China, Pakistan, France, and a few others. Like PAL, a SECAM picture is also made up of 625 interlaced lines and is displayed at a rate of 25 frames per second. However, the way SECAM processes the color information, it is not compatible with the PAL video format standard.
it.

I would think best approach at this is to tap into the monitors actual refresh rates.> 60hz, 120hz, 240hz. That way if the monitor is 60hz you know you need to double. if it is 120 your on the nose. If its 240 divide it by 2. You can always come out to 120hz refresh rate. Then use that to set your physics tick rate. Sounds like a good solution , Now to actually make it work. :slight_smile:

If I understood that GDC talk, they use a custom physics engine based on a fixed-point math library, avoiding already existing physics simulation code.

Hi BrUnO Xavier, thank you a lot for your help.