I see so much hate for adaptive physics stepping here, I’m honestly a bit saddened because it’s some amazing tech (when it works correctly). Let me try to explain something real quick: Fixed stepping simulates every bit of physics 240 times a second. This impacts your servers fps, which you absolutely do not want going down. Of all the games I’ve developed for, physics has eaten up at least a third of the frame time.
A lot of the physics calculations and simulations being done were, well, unnecessary. For example on characters! You just don’t need a 240hz simulation for an R6 character standing still. It’s just not necessary, and it is so cost intensive. In fact, this barrier is the main reason many people switch away from humanoids, and write their own character controller.
Adaptive timestepping is awesome because it doesn’t simulate that random character standing still at 240hz, it simulates it at, say, 60hz! That means there’s 4x less calculations being done, to put it simply. This means smoother servers. Obviously this benefits Roblox (less processing power used in data centers), but there’s also a massive advantage to devs too. Any time I show a microprofiler log to a non-Roblox developer, they’re shocked at how much time is spent on physics of all things. This is because Roblox just “over-simulates” a lot right now.
Of course, adaptive physics will have issues. It’s new, and young. It messes with an integral part of Roblox. But when I switched it on in a few games I developed for (they weren’t really physics reliant games), I experienced nothing but a performance gain by switching a toggle (which is the goal here for Roblox!). There are going to be issues, and these issues need to be fixed, but adaptive is very promising. There is a point to adaptive physics, you just don’t realize it until you open up the microprofile log for your game.
While I agree with your point, I think it is a mistake to make Adaptive the way it is right now the default method. Hajimalago mentioned a few times that they went for a more aggresive slower rate, and they plan on implementing other modes. Both in between what we have, and one that should be as stable as fixed is right now.
I think they should have waited until a third mode and made that default. I also think that for something that’s been present for a long while, Adaptive still has some pretty major problems that have to be kinked out. Luckily Hajimalago is fully on it, and I hope they can improve the mode before the default release!
Removing Fixed timestepping would break an anti-cheat project that our team worked on in the past, where we re-compute the physics of projectiles to detect any discrepancy in their movement between what the server expects and what the client reports. We would analytically compute the expected trajectory of an arced projectile, including in our calculations the Local Truncation Error that comes with the current implementation of the physics solver. Because this truncation error depends on the timestepping value, setting it to Adaptive renders our anticheat inaccurate and obsolete.
We knew this would come though, and we would understand the type of answers we could get: our implementation is highly dependent on the current physics solver, and we should avoid deploying projects that heavily rely on implementations that are prone to changes. But with all the other reports of instability from other developers in here, I figured I’d add this example of a project that would not work with the Adaptive method.
While you have mentioned wanting to retain an alternative that would give “the same quality as the Fixed timestepping option”, even a more accurate adaptive timestep (like the mentioned UltraPrecise example) might still be incompatible with this anticheat implementation. That being said…
But when combined with the planned updates to our solver/physics system…
Is there any information currently available on the new physics solver? Specifically anything to be said about the integration method and the local truncation error that would come with it?
An issue I have with the new API is the unnecessary steps/clutter required to accomplish the same goal I can, using less steps, with the old API. e.g. Why would I bother having attachments that serve no other purpose than bringing functionality to the physics movers? Especially given the fact that we already have properties such as “apply at center of mass,” why not give us the ability to forgo attachments entirely, if that is more convenient for the use-case? Having control over the individual axis power would help, but it still wouldn’t actually make the new API more convenient to accomplish many of the goals I, and seemingly many others, have when we use the physics movers. There have also been notes of issues where the behavior can be unpredictable (maybe because of its cooperation with adaptive timestepping?). For example, if a developer wants to add a simple effect to knock players back, the end result can be very inconsistent and jarring to players, sometimes resulting in a player appearing to teleport as the server seems to skip over the journey.
When using the adaptive setting, a lot of loose parts start shaking around and falling over. The only thing these parts are using is a weld, no special movers or anything. We would really like to use this feature but we cannot for this reason.
I would like to use Adaptive Timestepping… it just causes my characters when standing still to shake a lot, and act as if they’re about to fall through the floor but be corrected last minute.
My game, Whale Survival, is physics heavy, and Adaptive Physics makes it unplayable. I have a destructive ship in my game that a whale attacks and breaks it into pieces. With adaptive Physics enabled, players will phase through walls almost every other hit by the whale. Or players will get launched into the air. And the ship physics is unstable too and often flies into the air and disappear.
I turned on the adaptive Physics visualization tool to see what physics step parts were using. I saw that the Ship assembly was still green or yellow after getting hit by the whale. # of physics steps needs to be at maximum on whale impact, but it was often at the minimum and the gameplay suffered.
If Roblox is getting rid of Fixed step physics, they’ve gotta fix adaptive Physics. Otherwise we’ll need to take down Whale Survival. Something that would save Whale Survival is to make it assemblies always use max physics step, and indivual parts could use adaptive.
They are some issues with the collision of players , it’s way too easy to fling other people and we are able to climb through the truss, while other times you experience it being jittery when climbing into a part
This will probably be fixed when the new physics controller is released. I tested this with both controllers and it’s harder to be flung with the new one.
Adaptive Timestepping is breaking too many objects in my games. It would break countless other games. BodyPosition is too ubiqiutous to have such a monumental change. Please do not force this eventually.
My game is broken now that Adaptive became the default. I switched back to Fixed and will not use Adaptive because it has way too many problems with AlignOrientation. With Fixed mode I can use the left arrow to point the AlignOrientation to the left, and it goes left. In Adaptive mode when I press left it just spins wildly around in tight circles. The AlignOrientation parameters of MaxAngularVelocity and Torque don’t seem to do anything to control the speed of rotation with Adaptive on. This needs to be thoroughly tested with AlignOrientation to solve all of these issues ASAP.
I haven’t seen anyone point this out but this causes massive stuttering on humanoid characters while rotating. This happens when the character is being simulated at 60hz.
You can see it even in this 30fps video and it gets worse to look at with higher framerates.
Adonis admin has only recently become compatible with Adaptive Timestepping, and so I decided to implement it in my experience to see these potential performance boosts. Unfortunately, having Adaptive Timestepping on causes very frequent glitches with player characters, including stuttering, flinging when you run into another player or an object, falling down in the same circumstances, glitching into floors above you after jumping over a seat, glitching into walls and objects and getting stuck, etc. I’m afraid nothing my experience uses, except perhaps R6, would contribute to these bugs, and none of them happen with Adaptive Timestepping set to Fixed. For these reasons, I will have to keep my game set to Fixed, and I believe that the default option should remain as Fixed until the myriad of glitches and bugs associated with Adaptive can be resolved.
I’ve recently encountered an issue with the AlignOrientation constraint behavior when switching between different PhysicsSteppingMethods. I have documented the behavior in a YouTube video and have also provided a place file to aid in reproducing the issue.
Issue Description: When using different PhysicsSteppingMethods, the behavior of the AlignOrientation constraint changes (especially with PrimaryAxisOnly set to true), resulting in unexpected and problematic outcomes.
Steps to Reproduce:
Open the provided place file.
Observe the behavior of the AlignOrientation constraint with the default PhysicsSteppingMethod by rotating the part named “Control” about its Y axis (yaw).
Switch between different PhysicsSteppingMethods and PrimaryAxisEnabled on the AlignOrientation.
Observe the changes in AlignOrientation constraint behavior.
Expected Behavior: The AlignOrientation constraint should maintain consistent behavior across different PhysicsSteppingMethods.
Actual Behavior: The AlignOrientation constraint behaves differently when different PhysicsSteppingMethods are used.
