New Physics Stepping Method: Adaptive Timestepping

Great update, reducing lag, improving the physics engine and the gameplay
The kinda updates that make me wanna boogie :smile:


No, it just means that physics will run smoother and I assume it will reduce some bugs that happen where an object is moving fast and then it clips through a wall.


It’s called “adaptive” because it will automatically adapt, and it would be adapting to the games performance.


I am pretty sure lag depends on your computer mostly. But physics is also a main part of lag.


Sounds great however i do have a question will this new engine be automatically be enabled for new games or will have to always be manually turned on?


Looks awesome to try it out
but there are a few issues I encountered in Adaptive :
auto-throttling makes parts shake while disabled throttling has no impact
repro is basic, and it only requires a classic Roblox house with an explosion inside the house:
blastradius = 60, blastpressure = 50
then when the house collapses the small parts is trying to clip through solid unanchored floor, then starts the shaking
Update: while reproducing again I have encountered absurd physics bugs
It shows parts clipping and some of it floats
spawning parts that create this!
more clips of hunting adaptive bugs:


I was waiting for this for such a long time.


seems like this will be pretty good for devs to use.


Whatever we consider “hard to simulate” will be simulated at higher freq. ex) Fast moving parts, stiff springs, etc. This criterion is subject to change as we fine-tune this feature.


Thanks for the report! We will be looking into this.


this is gonna be great for my “SuperSpleef” game as the falling plates tend to cause alot of lag!


The moment the 240hz part touches the 60hz part, it basically rolls-back time for the 60hz part so that it can take a smaller step at 240hz.


I’m really excited about this optimization feature. I’m sure changing this underlying physics code involves careful surgery, so I would expect to find issues in edge cases.

Terrain Removal Physics Bug
Recently (the last few days or so), I’ve been running into bizarre problems involving runtime Terrain removal. When the voxel underneath my character is removed, it starts to fall. But sometimes this glitches, and the player is stuck “levitating” for a long time (maybe forever) with flapping arms. You can overcome this by moving around sometimes, but it will keep happening on other voxels too.

Repro Demo
This video shows a simple example of a repro for this bug. I built a simple demo Place to remove Terrain content under my character’s feet when you press “F”. The LocalScript invokes a RemoteFunction which does a game.Workspace.Terrain:FillBlock() with Air. This effectively removes the Voxel contents. If you do this 1-2 times, you can reproduce the bug.

Demo Video:
Roblox Place:​ (Public and Copyable)

It’s possible that there is some kind of optimistic caching involving Terrain Voxels which impacts the Physics Engine. This might lead to a situation where the built-in Character Controller is successfully doing RayCasting to determine FloorMaterial and update the Humanoid state to FreeFall, but the Physics engine is seeing a phantom Voxel present (maybe a stale cache?), so it does not fall. Note: I’m merely speculating about the internal implementation.

It seems likely to me that the bug involves changes for the new Adaptive TimeStepping in Physics features. The video is from the Roblox Player (not Studio), so those changes should not be live yet. However, it is possible that some recent changes to the Physics Engine were considered non-breaking and only-preparatory for the new Adaptive stuff?

Next Steps
This bug destroys a few of my games. Hopefully this helps identify the root cause and get it patched quickly.


This is an exciting feature. I’m always looking for ways to optimise my games - especially since a-lot of the limitations of Roblox Studio currently exist in the back-end of the engine, which keeps Roblox slightly dated in comparison to other game engines. Looking forward to seeing this get released and I’m on the lookout for any more features in relation to optimisation in the future! :slightly_smiling_face: :+1:


Nice feature, but I have a question, will we be able to set a custom frequency for each part in the near future?
So for example if everything works perfectly but that two wheels of a physical based (non-thruster) and (non-CFrame) car suspension front wheels lag when turning, will we be able to set a custom frequency for each part to optimize the game and make it more playable for players on slow devices?


I just enabled it, and my physics enemies move better than before.
thumbs up


This looks like a very useful addition!

I have recently made a post on the inaccuracies of object trajectories due to the integration method used in physics, and the script I currently use to compensate for this error assumes that physics are run at a fixed value of 240 steps per second. This is a script run by the server for checking the legitimacy of projectile-based hit registration in a shooting game, so running the script on the client is out of the question, and fetching the client’s current step duration, if at all possible, sounds rather impractical.

I guess my main concern is this: is the fixed option here to stay, or do you plan on disabling it altogether sometime in the future?


I just went in Studio test this new feature but I met a big problem while using my scale tool : it is just not working now.
In Studio and in-game:

In Studio but the Beta feature is disabled:

In Studio but the Beta feature is enabled:

There was no difference between the two versions.

This mean if you enable this in all the games, some things will break, and you should look at what can cause this problem.

After some more researchs
Only one time, it is saying the part is inside a folder in the workspace, but the others times, it says it is not in my folder but somewhere in the workspace (using :IsDescendantOf(workspace.Blocs)).

Few minutes after
It now says the part’s parent is the SelectionBox ! But this is false and it is still wrote in the explorer it is at the correct position, and the SelectionBox is empty.
image image

New informations
I found this in the script, and it was probably using this block instead of the true block…
I still don’t know why it was working before.

I now fixed the problem (because I put the temporary block in the ReplicatedStorage), but some games can break.

One more big bug with this : parts falling out of the world with collisions enabled.


Being able to choose the frequency would be nice. I can see a situation happening where 60hz would be ideal for me, yet Roblox decides it’s going to do something else. Kind of like how I can set the server settings to fill each server with players before making a new one, but it actually doesn’t do that and just does its own thing where it still leaves servers with a low amount of players and creates new ones despite having a different setting.


I’m seeing more and more defects that are probably related to these physics changes. This will break many games if not corrected. Also, you should try publishing something and testing it - it might be broken for you in the Player too.

See my post about on defects which are live in the Player now: New Physics Stepping Method: Adaptive Timestepping - #56 by GodSysAdmin