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 Terrain Physics Bug Repro - YouTube
Roblox Place: Terrain Physics Bug Repro - Roblox (Public and Copyable)
Analysis
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!
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.
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
Lag as in game lag not computer wise
Keep in mind you don’t have to use adaptive physics step rates so your assertion that it will break a lot of games isn’t necessarily true.
Yes, I agree, GodSysAdmin, regardless of the Adaptive choice, the “Fill terrain with Air” feature should be fixed. As an alternative, you could use explosions to remove terrain (non-joint-breaking). It does push the character a little, but they seem to fall in the hole just fine. Maybe its the little push that helps the character fall. I use this technique (terrain explosions) in my game Growing Up (Growing Up - 🐲🎂 - Roblox) and I have never had the levitation problem you described. Its the Dream task at age18: Blast for Treasure. If you don’t have time to level up, you can watch this youtuber: (Growing Up Dream Update! | Roblox Growing Up - YouTube)
Uhh… My computer still lagging.
[color=“FF0000”]Important[/color]
The new physics stepping method crashes inverse kinematics
I had a three day row about how these crashes were completely ruining my ability to work, and then I had discovered this new beta feature was the culprit.
On release, will the criterion for this be well documented enough so that we’d be able to design our game such that we can keep as much of it in a frequency that we want?
This feature looks helpful, but what I’d really like to see is a reduction in the rate of physics related network traffic for parts that are distant from the client. I’m bottlenecking on physics server->client kB/s way before hitting a physics CPU bottleneck. I’ve had to move much of the game’s physics simulation to client-side CFraming to make the game playable.
Also, ideally the server wouldn’t need to send any data to the client for the case where the client can perfectly predict the next server->client update based on its own parallel physics simulation.