New Workspace Option: PhysicsSteppingMethod

Please see updated information here:

Hello! A new physics option on the workspace is now available: PhysicsSteppingMethod. This feature has been in Beta for a while, and can now be enabled via your workspace settings.

We are supporting 2 different choices for this option: Fixed and Adaptive

  • With Fixed, our solver will take approximately 240 timesteps per second to advance the physics forwards in time, which is identical to the time stepping method Roblox has been using.

  • With Adaptive, our solver will attempt to adaptively assign appropriate timesteps (60hz, 120hz or 240hz) to separate simulating mechanisms. This will allow the solver to take less steps, improving performance at the cost of physical accuracy.

  • The Default setting would be set to Fixed, until further notice.

In general, Adaptive will try to simulate physics at a lower frequency than Fixed. This can cause the simulation in your games to behave differently, and sometimes the effect might not be desirable for your gameplay experience.

Please keep in mind that we are continuing to tune and polish the system so that the automatic timestep assignment system can work seamlessly for all possible scenarios. In the meantime, there might be cases where the lowered physics simulation rate can cause unexpected behaviors.

To read more about this option in detail, we strongly recommend that you have a look at our DevHub article and API reference!


This topic was automatically opened after 10 minutes.

Could we get an option to change the rate for the fixed option? It’d be nice to have more control over the physics rate rather than be locked to 240 and auto.


So to put it in more understandable terms, Adaptive is useful for showy animations but not useful if we are trying to perform an accurate operation like firing a projectile? I know that in most cases you should use raycasting and cframe the projectile instead of using the physics engine because the .Touched event is not that reliable. However, if you were to rely on the physics engine and use Adaptabe does that mean the .Touched event will be even less reliable or more?


And to make an API that allows us to set the physics rate of a specific model, something like :SetPhysicsStep(int) that way we can control which physics objects are prioritized for 240hz and which ones are prioritized for lower timesteps


This is definitely a benefit for non-physics heavy games. Good job!


Will it be possible to have anything local run Adaptive & everything on server run Fixed?


Glad to see new fixes for this! In the beta my pet system was freaking out all over the place and now that doesn’t seem to be an issue!


I agree, some games might be able to benefit from consistent less accurate physics such as uhh basically anything that relys heavily on destruction physics


An intValue for this would be great. I’d set it at 30Hz because I don’t make physics games.


I can imagine how this would create issues as the game is being rendered on 60hz, also as devices natural refresh rate is 60hz. If you have literally nothing in your game that runs with physics (not even the player), then it wouldn’t make a difference anyway on performance.


Adaptive Timestepping:

(This has been reported in the beta group)


Only issues I can think of is a moderate stutter with assemblies moving and generally higher unreliability. I also believe the OP meant physics-orientated games rather than a game without physics.


Personally, I believe there should be an option to force the stepping of models/baseparts to a fixed value. Honestly it doesn’t even need to be to a specific value. For me at least, a Fixed/Adaptive enum would be fine.

Adaptive stepping is good for performance, but in certain cases it can be detrimental.

I want the ability to have adaptive stepping for non-critical physics calculations, and fixed for the critical ones.

For example:

Let’s say I have an Explosion Spell in a RPG game. It shoots a projectile that temporarily explodes part of the map on contact and sends Part particulates flying out.

In this case I would want more stable stepping for the projectile, but to allow for adaptive stepping on the particulates.

Due to the potential instability of adaptive stepping and the inability to guarantee stability on more critical physics calculations, I won’t be using this feature for now.

I can foresee some potential caveats to implementing this additional feature.

Namely, how would you decide what the stepping rate of an assembly is if it has parts set to different rates?

For an Adaptive/Fixed system, you could potentially have Fixed override Adaptive.
For a defined rate system, you could have the highest rate take priority.

Still, this could easily lead to a programming pitfall in which an inexperienced programmer wouldn’t get the behavior they expected. Or worse, they won’t even know that the code isn’t working as expected.

Said programmer could weld a model or basepart with a fixed rate to a large model with an adaptive rate and be under the notion that the large model is still using adaptive.

Nevertheless, I believe there’s no net gain for using this in a experience where there are individual parts or models that need more reliable physics calculations unless there’s a way to distinct critical calculations and non-critical calculations.


A lot of games run physics at 60 FPS, while their render framerate can go over 200. They simply interpolate object positions to make them look smooth.


Glad to see this finally released!

I discussed with an engineer in a private DM a while ago and made some suggestions with respect to the ability to set the stepping rate for certain critical models. It has not changed that I will need the ability to do this to be able to use this feature in my experience because my custom characters do not behave well at lower step rates (i.e. tunneling, springy bodymovers, instability, nauseating position stepping).


Nice to see this got updated.

I initially had my doubts about this because of the amount of bugs it had between now and when I tested it around a month ago, glad to see those have been fixed. Gameplay in my experience is identical so this is like an invisible but very real performance boost. Good work!


It’d most likely be an enum value.


Does this fix the issue in the beta where body movers would just freak out when it wasn’t set to fixed?

also has this api been enabled?

basically just allows us to set the physics rate in Fixed mode


I was able to set this to Adaptive in my game yesterday, but now I am no longer seeing the option in the workspace. I also don’t see it in the list of beta features. Was the option disabled?

1 Like