PhysX simulation skipping steps

Omniverse Apps USD Composer (Create)
,
1

Hello,

I wrote an extension that records object movements over time and noticed that the physX simulation seems to skip steps.
So I got curious and printed out the number of physX steps for a 10s long animation, each time with a different number of time steps per second (in the physX scene properties). These are the results:

time steps per second number of sim steps in 10s anim
10 100
20 200
50 301
100 301
200 903
500 2400
1000 4816

The results are as expected for 10 and for 20 time steps per second. However, the simulation skips steps for higher values.

Is there anything I can do to force correct time stepping? I also tried the asynchronous simulate/render option. That did not change the results.

Many Thanks in Advance!

2

Hello @axel.goedrich! I need to reach out to the dev team for help on this one! Thanks for letting us know!

3

The Omniverse PhysX integration can take multiple sub-steps per rendered frame to try and keep up with the amount of real time that has elapsed. PhysX itself will be stepped the expected number of times at time-step sizes of 1/50 and 1/100 respectively to generate 10s of simulation.

You do have some level of control over this. This particular control option has moved around in the UI a few times so, depending on the version of Omniverse you run, it may not be in the location I describe. In the most recent version of Omniverse, if you open up the Physics Settings tab, you should see an option called “Min Simulation Frame Rate”. This defaults to a value of 30. This means that PhysX will simulate sub-steps of the size that you defined and it can consume up to 1/30 of a second of time before it discards any left-over real-time. If you set this number to match your desired time steps per second, this will force PhysX to run 1 sub-step per rendered frame, otherwise it could run more than 1 sub-step.

Please let me know if this doesn’t resolve the issue or if I’m misunderstood the issue that you raised.

4

Hi,
this should work in ideal case, it depends if the framerate in general was high enough. There is one more setting that determines the number of substeps that executed in omni.physx.
There is also minFrameRate setting that blocks simulating more steps to not make the general framerate be worse and worse.
Here is the substepping code:

void PhysXScene::computeSubstepping(float elapsedSecs, float fixedTimeStep, float timestepsPerSecond)
{
    uint32_t steps = (uint32_t)((elapsedSecs + mRemaining) * (1.f / fixedTimeStep));

    const uint32_t minFrameRate = OmniPhysX::getInstance().getCachedSettings().minFrameRate;

    const uint32_t floorSteps = (uint32_t)timestepsPerSecond / minFrameRate;
    const uint32_t maxIters = floorSteps > 0 ? floorSteps : 1;

    if (steps > maxIters)
        steps = maxIters;
    
    mRemaining = fminf((elapsedSecs + mRemaining) - (fixedTimeStep * steps), (maxIters)*fixedTimeStep);
    mCurrentStep = steps;
    mCurrentTimeStep = fixedTimeStep;
}

So we are trying to simulate given steps per second, but if the frame rate drops too much we start to discard steps. This is probably what is going on in your case. So try to change minFrameRate too (in Window->Simulation->Settings, that should help.

Regards,
Ales

5

Hello,
thank you all for the helpful replies! If I’m not mistaken you both meant the same setting (see image below).

min_sim_frame_rate
min_sim_frame_rate1041Ă—1114 69.2 KB

@AlesBorovicka, thanks for the code snippet, that helped to understand the internal process.

With a lower “Min Simulation Frame Rate”, the stepping now works as expected!

But when I capture the animation as a video (using the movie capture extension), depending on the number of time steps per second, some object movements don’t seem to be updated in the renderer (as shown in the videos below):

The first video was captured with 50 time steps per second. This is how the animation should look like:

The second video was recorded with 160 time steps per second, the movements of the large gear seem to be frozen for a few frames. After looking at the recorded object movements (I read out the object positions in each simulation step), I can confirm that the movements are correctly updated in the physics simulation, the big gear still seems to be frozen in the video:
Uploading: test_160.mp4…

For clarification:
The bolt is animated and the large gear is connected to the bolt via a d6 joint. Each axis of rotation and translation of the joint has a drive with a certain stiffness. I implemented this as a workaround to determine the forces on the large gear (position difference between bolt and gear * stiffness = force). I originally intended to use the collision callback for this, but there seems to be a bug when using sdf collisions (as mentioned here: Accurate collisions for complex meshes - Apps / Create - NVIDIA Developer Forums).

Interestingly, in the video, the bolt appears to move correctly, while the large gear, which is connected to the bolt via a d6 joint, does not move in some cases.

Is this a known problem?

6

The second video doesn’t seem to upload, so here another try:

7

I think here the problem is with the way how movie capture steps. It does step based on the given Frame rate, so unless you capture with 60 FPS and simulation stepping is multiple of 60, then there is most likely some disconnection between rendering and simulation.

Could you please try to sync the Movie capture FPS and the scene num steps per second to see if it helps?

8

This unfortunately doesn’t fix the issue. I’ve tested multiple configurations of capture framerate and number of time steps per second:

Capture FPS Time Steps Per Second Workes Ratio (TSPS/FPS)
30 30 yes 1
30 50 yes 1.667
30 60 yes 2
30 63 yes 2,1
30 90 yes 3
30 120 no 4
30 150 no 5
30 180 no 6
60 60 yes 1
60 120 yes 2
60 240 no 4

The freezing seems to occur for high ratios between framerate and simulation steps per second.

9

The freezing is also visible, when the simulation is started in the viewport (without the movie capture extension).

10

Sorry I am a bit confused now, so you are saying even without the movie capture you see freezes?

When we do substepping, the transformations for rendering get updated after all the substeps are done. But that should be correct for the regular simulation when you press play. Every frame we should output the transformations for the renderer.

I could see maybe with the movie capture to see some issues, as I think its stepping things differently. But regular simulation should not really have freezes.

I could try to repro it locally if you can share the assets. Also a question, how do you update the D6 joint drive? Is that animated or do you update it every frame? There is a subscription to update value after very simulation step, I think that would have to be used if you update the drive yourself.

Regards,
Ales

11

Yes, that is correct. I see the freezing even when starting the simulation directly in the viewport.

The joint updates could be the source of this problem, since the animated bolt is updated properly, while the gear which is connected to the bolt through a d6 joint, is sometimes freezing.

But what’s still confusing to me, is that the big gear only freezes for the renderer. When I read out the object positions in each simulation step, the big gear moves properly, while it is freezing in the viewport.

I Created the joints and everything else in the Create UI.

Here is the USD-File of the project (simplified collisions because of file size):
Gear_test_stepping.usd (24.3 KB)

And here is the referenced file for the gears:
zahnrad1_und_2_geschlossen v3.usd (889.2 KB)

12

Please what version of Create are you using? I am not really able to reproduce the issues yet.

13

I use version 2022.1.2, maybe it has something to do with the hardware? I’m using a Nvidia RTX A3000 laptop GPU, which is not very powerful. I get about 15 FPS in the viewport (when the simulation is running). Maybe you can try it with a higher number of time steps per second?

But if you can’t reproduce the problem, then it’s probably something more specific. This problem is not very relevant for our project (we focus more on physics simulation than rendering). So please don’t waste too much time on this.

Just for reference, here an example of the freezing in the viewport:

14

I will ask more people to try this out. Can you try to switch the renderer to RTX - real time? I am not able to repro this with 2022.1.2 even if I limit the FPS to 15 FPS, strange. Let me ask more people to try, this is a bit strange especially if you see the data to be updated.

15

I tested it with all the renderers available:

Renderer Number of Time Steps Per Second, at which Freezing starts to occur Framerate at this setting
RTX Interactive 110 28
RTX Accurate (Iray) 120 30-45
RTX Real-Time 200 55
Pixar Storm 270 75

The freezing occurs with every renderer, but at a different number of “Time Steps Per Second”.

By the way, thank you very much for your efforts, I really appreceate it.

16

Interesting, we were not able to really repro the issue, but its really puzzling why it would appear based on the time steps per second, as thats really just simulation frequency the USD write happens only once after all the steps.

Will play with the stepping a bit more to try to repro this, its suspicious.

Just out of curiosity, can you try the above with this command line parameter added when you execute create:

--/app/asyncRendering=false
17

I’m sorry, I’m not quite sure how to do this. I always use the Omniverse Launcher in Windows to launch Create. Should I launch the executable in the command window, with this command added? And which executable should I use?

18

You can click next to launch to the hamburger menu and there for the settings. From there you can get to a location where the Create is installed. There should be omni.create.bat, so you can open a cmd window there and execute it with the additional parameter.

19

I launched it with the additional parameter, but the behavior was the same.

Interestingly, I get an error message when I launch Create through the cmd :

CMD_feedback_Omniverse
CMD_feedback_Omniverse1469Ă—514 22.5 KB

Could that be somehow connected?

20

Ok was finally able to reproduce the problem and I know what the problem is. Since the AnimationData are not updated with every substep, with the increased substepping the body goes to sleep and is not awaken, please set the sleep threshold on the body to 0 to disable sleeping.
I will try to figure out if its a sleeping bug or not…
Thanks for reporting,
Ales

1 Like