Adaptive Timestepping as Default

Updates Announcements
#1

Hey Developers!

In the coming weeks, the Default mode on PhysicsSteppingMethod property on Workspace will be set to Adaptive.

Adaptive Timestepping allows better physics performance by stepping using larger timesteps when possible. For more information, visit our documentation.

With this change, physics simulations may behave differently in some cases, so we encourage everyone to test their experiences with PhysicsSteppingMethod.Adaptive first.

If you wish to opt-out, you can always use the Fixed option to keep everything the way it was. However, as we continue to update this feature and other components within our engine, the ‘Fixed’ option is subject to being removed in the future. We recommend moving away from deprecated APIs that may not work well with Adaptive Timestepping.

Please note, if your experience heavily relies on legacy BodyPosition instances, the system will default those bodies into 240hz mode. This is an unfortunate decision we had to make since legacy BodyMovers are generally unstable under lower frequencies. It is strongly encouraged that you migrate these Instances to the new AlignPosition constraints to benefit from Adaptive Timestepping.

Please let us know if you have any questions or concerns.

Thank you.

59 Likes
#2

This topic was automatically opened after 10 minutes.

#3

Maybe now would be a good time to consider giving AlignPosition control over independent axis like BodyPosition has? using MaxForce with 0 on one axis for example made it unable to push in that direction and let other physics constraints act on it, AlignPosition has no such feature even after years of its release and BodyPositions deprecation.

42 Likes
#4

We are currently looking into exactly this, as it seems like this is the #1 reason why most people do not want to migrate to the new API.

48 Likes
#6

I’d like to mention the post I wrote here:

Constraints seem powerful by the ones who have existing physics knowledge already, but for someone who doesn’t have prior knowledge it’s very hard to make the switch.

4 Likes
#7

Would appreciate it if VectorVelocity didnt cause the physics replication to go to sleep. It’s been very annoying to have to build all kinds of manual replication methods and hacks to force the physics engine to stay awake when dealing with vector velocity related issues. VectorForce does not have issues relating to this, neither do a lot of the other constraints. Would appear VectorVelocity is one of the only ones facing this issue.

9 Likes
#8

While I appreciate the option to offer up a more limited version of the Physics Stepping Method, using the Adaptive mode in physics heavy games simply won’t work.

The first issue is speed. If you have a lot of objects moving around (say more than +100 for example), the physics engine basically seizes up and all objects are just stuck floating in the air.

The second issue is the player physics. Any player that runs into another object ends up getting flung off in some weird bug that sends the player tumbling sideways for a few seconds until the game engine finally catches up and fixes it. Players can’t push open a door for example because if they run into it, they might be sent high in the air or crashed into the ground like they just fell 10,000 studs with Jupiter gravity.

So if the default is Adaptive and it works for your game, then more power to you. But the fixed mode needs to stay forever for those of us using very heavy physics games that depend on the precision and speed of the server to avoid physics seizes or player movement bugs.

I’ve never submitted any bug reports about the Adaptive mode because I just chalked to “limited by design” for those games that don’t depend heavily on this. It makes sense. But the rest of us, the “Fixed” mode needs to stay and talks about removing it are just silly as it would break a lot of games. Actually, it will break a lot of games when it becomes the default because most don’t even know they need until it stops working. :sweat_smile:

18 Likes
#9

I cant use this. Some Airport People Movers has been tested under adaptive timestepping and it cant handle it due to its interesting behaviour of root priority abuse.

It flings whenever it tries to change physics setting. This will probably break a lot of other of my CFrame based mover systems which rely on a deterministic root part, I’ve noticed under adaptive, the root part mysteriously changes for no reason

Please stop trying to push one system over the other, this is an approach I’ve seen Roblox take with quite a few features and its detremental to game development. Is “why not both” too difficult of a workflow for you guys?

3 Likes
#10

Or just… not change it? Adaptive is a pain for most of my games and it literally has broken a lot of them. It is nowhere close to good enough to even be usable in the cases I have. The character has a lot of problems just existing with this mode on.

I have tried to use adaptive, but it just ends out horribly every single time. Please, have fixed still be available for games that can’t use adaptive

2 Likes
#11

Is it possible to manually set the timestepping of certain objects?

If not, I think that could be game changer for physics in general and actually make this more viable

#12

Best news i’ve received today. Impressive, very nice. :clap:
By the way I already use the new constraints (mostly AlignPosition/Orientation and LinearVelocity) but i’m limited to what I can do with them because of this issue.

1 Like
#13

Hey metatablecatmaid, thanks for your feedback. So root priorities aren’t respected with adaptive stepping on? I’ll try to look into this issue.

#14

Rejoice! I can finally swap to the new API!

2 Likes
#15

Found a major issue with this as well; using an FPS unlocker makes the stepping visible to your character’s physics. I think that character physics stepping should automatically adjust to your framerate. This just looks ugly with FPS unlockers set higher than 60. I have to use an FPS unlocker due to Roblox eating my very fast inputs. My PC uses a 120Hz monitor, so it’s really needed for this.

2 Likes
#16

I’m unsure of the exact cause, from my own testing it looks like the root part gets changed when the assembly gets anchored (which is fine, i expect this to happen), its when the model gets unanchored, it doesn’t respect the fact that the root part needs to move back to where i want it

This works fine in 240hz fixed physics, so its an issue with adaptive timestepping.

https://devforum.roblox.com/t/1441851?u=metatablecatmaid

#17

Thanks for posting. I’ll try out the game to see if I find anything.

#18

I don’t think this change is a good idea. the Adaptive mode is still extremely broken. When 2 players walk into eachother they get flung, when you walk into a wall the whole camera and player shake like crazy, assets fling around like crazy, it breaks when there’s too many assets, players get flung like crazy. The Fixed mode must stay permamently especially for games that heavily rely on the physics.

10 Likes
#19

That is true along with other major issues. Roblox should really just keep both if they admit that there are differences in how physics is going to react. Just keep the option as something optional.

There is no bug being fixed with this, so it’s no big issue to allow developers to keep the option. Having it as default is one thing, but removing fixed is a no go.

3 Likes
#20

Hey realOmlet, thanks for the feedback. We won’t be getting rid of the capability to simulate everything at “high-res” physics. If we decide to remove the “Fixed” option, we will make sure whatever it gets replaced with can provide similar simulation quality to “Fixed”.

I’m also interested in the issues you mentioned; it would be great to get a repro so we can make the system more reliable.

4 Likes
#21

That is a good thing that you are considering keeping something similar to the quality of fixed. I do hope that the character physics get fixed as the characters I use always start freaking out when there is a slight angle when moving at a wall. I use custom characters for my game, but this still happens with R6 and R15.

3 Likes