Feedback Physics Sub-stepping

Hi,

I know it can be implemented by setting Physics.autoSimulate to false and then calling Physics.Simulate manually at fixed rate per each physics "frame".
But that breaks rigidbody interpolation (only extrapolation is left intact, but we can't use that in our project, since we have lots of fast moving rigidbodies).
I reported it as a bug but was redirected here to ask for proper physics sub-stepping implementation on Unity side (since current behavior is said to be by design).

Physics sub-stepping is really needed in our project, we need that extra, cheap, physics joint convergence etc.
I believe many other users would benefit from it as well.

For example Unreal Engine does offer explicit implementation of it.

Regards,
Stepan

 

Hi @MelvMay ,

I believe developers using both 2D and 3D physics would benefit greatly from this improvement.
I'm just trying to bump this a little, because I have zero idea if this is the proper way of making improvement suggestions to Unity, simply through forums. And i've got no reaction. And couldn't google anyone else making the same suggestion before.
What so you think about this?

Regards,
Stepan

 

After extensive experimentation with adjusting fixed timestep to increase physics update frequency, implementing my own sub-stepping by disabling AutoSimulate and calling Simulate manually and adjusting solver iteration count, higher iteration counts that gave much needed results lead to huge FPS drops under huge joint strains.

Using higher physics framerate instead also improved things (it actually improved joint behavior the most, as to be expected), but decreased framerate in general. But at least it kept the framerate much more stable.

Finally using physics sub-stepping improved things almost as much as higher physics framerate, kept performance stable, and kept performance AMAZING!!!
It also removed the need to tweak each joint like crazy for most stability and performance at the same time. Day night difference.

I also tested Unreal Engine sub-stepping and got similar results.

This feature would be a game changer for our physics heavy game. I say that as someone who has spent months tweaking physics and learning how to stabilize joints the most. I already tried all tricks I could find on various forums, after inspecting PhysX code on GitHub etc. Sub-stepping offers, by far, the best performance/tweaking difficulty/framerate stability/joint convergence and overall quality ratio.

Also thanks for responding <3

 

Indeed I gave it a thought. But that is a last resort solution since making sure such custom interpolation works fast, on all rigidbodies in the scene under all circumstance, doesn't break anything, that all timings are perfect etc. would be hard.
I also tried using rigidbody extrapolation instead - but that gave unpleasant results on fast moving rigidbodies in our scene for obvious reasons.

I have created a bug report ticket for this actually, in the past (Case 1297438). It took some effort convincing Unity QA firewall that it actually isn't working properly. After that, I was informed this will not be fixed, since interpolation can't possibly work in combination with sub-stepping implemented by user through manual Simulate calls. I'm not sure about that, but I'm not a full-time physics developer, so I did what QA told me - made a feature request here, in this thread, asking for a proper physics sub-stepping implementation (with bool setting to enable it and an integer setting to configure sub-step count would be more than enough I suppose).

Please @yant , you are my last chance for an amazing almost free physics quality boost <3

 

Hmmm this sound interesting, but I'm not sure I totally understand what the (sub)stepping does on top of regular physics stepping. The only thing I saw was, that physics callbacks are delayed until all sub-steps are completed.

From the link you posted on the other thread:

This already is the case for Unity, when you set a fixed time step smaller than the frame-rate. Can you elaborate on what would be the additional benefit of that? I'd like to understand the implications.

(Disclaimer: I mostly use 2d Physics, so things might be handled a bit differently for 3d?)

 

Sub-stepping doesn't update collisions, doesn't call FixedUpdates etc. This way it saves lots of performance. Main benefit of it is solving joints in between regular physics updates. Increasing the frequency of this particular job means amazing joint convergence at very low cost.

I'm no expert myself, just speaking from experience here. With sub-stepping I can achieve rock solid joints + high and stable FPS. Without sub-stepping, I can only increase the physics update frequency itself. This leads to horrible performance. By the time I get rock solid joints, I'm at unstable ~8 FPS in our test scene

The thing is that I don't really need the extra work that full physics update does. I just want the joints to converge better.
I was able to do that, to some extent, by using all the joint stability hacks I could find online and/or by myself. But it's impossible to get the level of stability that I really need in our heavily physics based game.

The difference with sub-stepping is incredible. All joint rubbery behavior and various jerking etc. disappears. Under all circumstance, when dropping heavy things on a low mass joint objects, let alone push something very hard into it, forcing it to break its constraints. Everything works.

So sub-stepping not only increases the top bar for the simulation quality you can achieve, it also does so without requiring heavy tweaking and testing per every single joint. It's just an amazing global improvement.

 

OK, I see! I guess you are aware of the position/ velocity iteration settings – I always thought they might be used for stuff like this, but never really tweaked those a lot. Also it seems like 2d and 3d are different from what you can change there. For 3d it seems to mostly be for collision resolving, generally not sure if those are relevant for joints also. Thanks for laying out the details!

 

These are relevant to what I'm talking about, but not a silver bullet. They improve stuff, but cost a lot of performance in a very inconsistent manner. I mean - you find a value that brings solid stability, but then, when strained too much, tank performance quite a lot.
Also using the general values for these does not cut it for us. We have to fine tweak these per joint, takes time and is annoying as heck.

These also don't work as well as upping the physics frequency or using the sub-stepping. Sub-stepping has much more stable performance, is a general setting and improves joint convergence much much more. I mean much more than even using max iteration counts for the lulz.

Hence my cry for proper sub-stepping implementation here. It just works so damn well. But I need it with working rigidbody interpolation.

 

Bumpity? It's been a month since last reply now
@yant

 

I really wish I had known about this limitation before committing to Unity instead of Unreal.

 

Don't get me wrong, I have no idea how PhysX integration compares across the two engines overall.

But yeah, sub-stepping has such a global effect and just is such a killer feature. I was able to see its effect on test scenario in Unreal, or in the amazing demo project from Bepu Physics.

 

If your making a game involving high speed physics objects, like melee combat, it's a must have, so far I've got away with continuous dynamic on rigidbodies but collisions are often detected long after the sword is already stuck in an object which ruins the immersion to some degree, and turning down the physics timestep causes major lag as the game levels are pretty big.

Considering the devs comments above I think I will need to move to Unreal 5 at some point, whether Epic will help with that or not I don't know, and then there's converting all the C# to C++, ahh fml

 

Why do I always have the feeling that cool stuff happens on 2D physics side of force but nothing at all happens for 3D physics? Articulation bodies, yes, but that's hardly going to affect majority of Unity devs out there.

I vote for @MelvMay switching sides. He's so active on the forums and always trying to help. Amazing work man, please, share your implementation and notes with someone from 3D physics department. This is lovely!

 

Huge thanks to all of you guys then!

For me, as I previously stated in this thread, the biggest deal is the global, easy to achieve, low performance cost added joint stability. We have complicated joint setups, non-kinematic bodies that are either falling or being pushed into the mechanisms etc. Without sub-stepping, joints inevitably go crazy at some (not actually that hard to reach) point.

This isn't a problem for intentionally silly games. Not so much in case of psychological horror games, where the immersion goes out the window right when that happens

 

I meant when you stress the joints hard enough by any means (pushing, pulling, impacting on them etc.) they will start to jitter.

This will improve when increasing solver iteration count, but from my experience, higher solver iteration counts cause huge spikes in performance when joints are over-stressed (imagine player pushing a dishwasher into a hinge joint high solver iteration count valve by accident, suddenly dropping FPS by 60% ). We need extremely solid joints, ready for lots of stress, and iteration counts simply did not provide high enough stability benefit to justify the inconsistency in performance caused by these conditional huge performance drops.

Increasing the time step is best for quality, but obviously kills the performance completely (at least in our case, when increased enough to achieve the desired stability). This makes sense, because simply increasing physics framerate across the board leads to more frequent collision detection and other things that are skipped when sub-stepping is being employed (during the sub-steps).

All this, mind you, is after tweaking center of mass, mass, inertia tensor etc. of the objects. Lots of tweaking have been done already.

When I implemented sub-stepping as previously mentioned in post #1, stability gains are incredible, across the board. I can also keep the fixed time step relatively low, so the performance is also solid. The only downside is rigidbody interpolation not working (meaning it acts like it was disabled).

EDIT: You can find more info about the interpolation issues in "Case 1297438"

 

All my information about sub-stepping come mostly from BepuPhysics physics engine:
- Code that says more than a 1000 words.
- Docs

Should be in alignment with PhysX official docs on the topic.

 

Almost there, but I believe there is one important thing you missed (or I missed the fact that you didn't miss it ). Since you are a programmer, the easiest way to show it would be to do so on the BepuPhysics code I linked in my previous post.
These sub-steps perform only some of the typical physics step work. If they were not, sub-stepping would be pretty much useless.

In the code, you can see that each physics step, collision detection is performed once as per usual (very expensive, not necessary to repeat, since sub-stepping is primarily used for better joint convergence) at line 75. This is very important and one of if not the most important reason why sub-stepping option would be a nice to have compared to only being able to increase the fixed time step itself. Because I'm not bothered by things falling through the ground etc., I'm bothered by non-satisfying joint convergence that is, without sub-stepping, incredibly expensive to acquire under all scenarios that normally occur in our game.

After that, sub-stepping is performed (joint convergence etc.) within the for loop. Engine dev was also able to make some assumptions (like skipping 'IncrementallyUpdateContactConstraints' for the first sub-step) since the sub-stepping is implemented on the engine level and he has a fine-grain control over everything, hence me asking for an official solution from Unity.

Unity can implement this better than me with my naive solution from post #1. And you might also be able to fix the interpolation. Then, I would be living a dream.
Also everyone would be able to use this, it would be enough to just spot this setting in Project->Physics settings for each user. So everyone would be happy

EDIT: When I free up some time, I will try to provide some example project. But it will not be that easy, since all I'm talking about is best seen in our full, huge project that I'm not even allowed to post anywhere freely.
To better demonstrate how much joint convergence and general stability can improve with this feature, even with my naive implementation with somewhat limited high-level API, one would have to be able to play with our interactive joint powered objects. We use prismatic joints, revolute joints, fixed joints, specialized configurable joints for physics simulated ropes etc.
The moment you turn sub-stepping on and ultimately "raise physics update frequency for selected parts of the simulation", stability goes way up and the game still performs nicely (meaning the CPU doesn't become a bottleneck, unlike with any other approach (or approach combination) that raises stability enough).

EDIT2: I re-read your post... ahem... you are correct, official implementation can only provide better performance and hopefully working interpolation. Because that not working as soon as you repeatedly start calling Physics.Simulate is an issue for us. Extrapolation works, but yields not very satisfying results under some scenarios in our game (fast moving objects).

 

I'm all for extra control for the end developer. I have no experience with 2D physics in Unity, but what you mention sounds very useful and I would love to have something like that in the 3D counter-part as well.

 

So has anyone figured out a way to implement substepping in 3d physics in unity? I really need this for my vehicle physics

 

Man, I would love it if this were possible in 3d physics. I have a use case that involves a bouncing ball… under some circumstances I would like unity to calculate collision points but I would like to resolve the velocity of the collision myself, and other circumstances where I want to just let unity physics do it’s thing.

right now I just “overwrite “ the resolved velocity in OnCollisionEnter, but doing it this way means I’m incurring the the performance hit of unity’s physics calculations as well as my own.

 

I assume you're using WheelColliders?... because sub-stepping would not invoke FixedUpdate more, so you wouldn't be able to improve raycast based wheels.

 

No I built my own vehicle physics solution from complete scratch (no wheel-colliders)

 

Your tweet suggests it can only be automatically increased behind the scenes when framerate dips below target fixed framerate. Would it be possible to expose the substep count to be changeable at runtime so I could achieve my current usecase below? And if so, is there any harm in changing the substep count every frame?

For my project, my 2d platformer terrain collisions use fixed-length Raycasts with kinematic body instead of the physics system for solid collisions (can't use velocity-length raycasts or collidercasts because of nonlinear 2d sloped movement per frame), and in order to prevent tunneling if any object is moving faster than the steplimit of x units per frame, I need to break down the movement into steps in fixedupdate by teleporting the rigidbody and then checking the new raycast collisions

Code (CSharp):

1. //pseudocode
2. for(each substep) {
3.      for(every physics obj) {
4.            obj.rb.position += obj.velocity * fixedtimestep * subtimestep;
5.            obj.Raycastcollisions();
6.      }
7. }
8. for(every physics obj) {
9.      Vector3 finalPosition = obj.rb.position;
10.      obj.rb.position = originalposition;
11.      obj.rb.MovePosition(finalPosition);
12. }

with that final loop being needed in order to not break rb interpolation.

As you can see it's a bit awkward having to manually loop through and update every physics object multiple times per frame from an updatemanager's fixedupdate, then do another loop after in order to satisfy interpolation requirements.

Is that something that the substeps you're implementing could be used for to alleviate that awkwardness? Or would there no way to inject the raycast-based collision checks into those substeps?

 

Please if you meet the 3D Physics team at the lunch, tell them they must make this too
It tears me apart!

 

Just my two cents:

Substepping + amortizing collision detection (reusing the same set of contacts for the all substeps within a step) is indeed a good way of improving overall perceived stability.

For velocity-based constraint solvers, the improvement over just using more iterations is moderate. However for position-based ones it's been demonstrated to clearly outperform using iterations:
http://mmacklin.com/smallsteps.pdf

If the engine is using any kind of positional projection for joint/contact stability, it will benefit from substepping quite a lot.

 

Oh my friend,we truly need substep in 3d.In Unreal,there are some awesome feature about movementcomp. When you do some kinematic rigidbody movement in an uphill，normally we will calculate the result that is the body first move in its origin velocity,and collision with the uphill,then sliding on the face.All these process happens in a frame,but unreal use physX-substep to keep velocity correct in the whole process.Maybe there are two substep,one for origin speed,one for slide on the face.
I need to say some word about step and substep.In unity we use step in every fixedupdate,call PhysX simulate and fetchResults,these two func make a step.Substep is a physX conception which will do a step in some small timestep for detail correct. I need to say substep can both work in fixed timestep engine like Unity and in auto timestep engine like Unreal.We certainly can maintain some timestep sliced pieces and call few times simulate by ourselves,but it will cause some problem make unity break down.For example,the rigidbody interpolation system,we need to rewrite it and apply it in the whole project.

Call some times step is expensive then substep,because call n times step will call n times board phase check and n times of narrow phase check,yet substep will call 1 times board phase check and n times narrow phase check.

Thanks.