Will this help with performance on higher player servers like 100 player servers?
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?
In my case, Adaptive Timestepping is actually more stable with the new humanoid physics controller.
In this experiment, I just simply walk into a part with a density of 0.01:
Adaptive:
robloxapp-20230123-0814576.wmv (1.5 MB)
Fixed:
robloxapp-20230123-0815351.wmv (567.9 KB)
Unfortunately, as stated, body movers like BodyPosition are broken on adaptive:
robloxapp-20230123-0818417.wmv (1.8 MB)
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.
They are a memory leak in PhysicsPart (happening with fixed and adaptive)
Devforum posts: On player load PhysicsParts memory increases permanently, resulting in crashes and severe lag
Massive PhysicsPart memory leak results in server crashes
I’m reporting here in case
Using Roblox’s Social Interactions Dev Module (Social Interactions | Documentation - Roblox Creator Hub) with PhysicsSteppingMethod = Adaptive causes lots of camera shaking when the player stands on a sloped terrain. Repro is easy: Start with a fresh baseplate, add a little terrain with a slope, follow the five simple steps to install Social Interactions from the Creator Documentation link above, and set PhysicsSteppingMethod = Adaptive.
PhysicsSteppingMethod Adaptive conflicts with SocialInteractions DevModule.rbxl (183.7 KB)
UPDATE 6/29/2023: SOLVED. I tested this again and it seems to be resolved. Thanks!
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.
To fix this specific issue, I would turn the part collisions off and use HumanoidHipHeight
and set it to like… 0.5 or lower as you would need.
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.
Thanks,
jelloman
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.
see also: Recent changes to AlignOrientation 100% broke my game
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.
Hello Engineers,
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.
Additional Resources: YouTube Video: AlignOrientation: Differences Between Adaptive and Fixed PhysicsSteppingMethod - YouTube (Please refer to the chapters in the video description for specific timestamps and details.) Place File: AlignRepro.rbxl (40.2 KB)
I hope this report helps in addressing the issue.
Thank you for your attention and support.
I guess a better explanation to this would be that the MaxAngularVelocity
property is not respected in adaptive timestepping, which is a real problem.
EDIT: Keeping the post here if needed for future reference, but this issue was discussed and patched. See this thread: Adaptive Physics Breaking Game
Earlier today we’ve received reports that our games had collision issues with their projectiles. It seems that when a fast-moving projectile tries to collide with an unanchored part, the collision frequently fails at the start of the projectile’s trajectory. We’ve come to the conclusion that the Adaptive Timestepping is currently causing the issue, as setting the PhysicsSteppingMethod to “Fixed” resolves this entirely. Here’s a place that reproduces the issue:
collisions_timestepping.rbxl (45.4 KB)
And two videos that showcase trying to have two parts collide at moderately high speed (the red projectile spawns 5 studs before the black one).
PhysicsSteppingMethod = Adaptive (fails most of the time, though not always)
PhysicsSteppingMethod = Fixed (never fails)
While it is expected that adaptive timestepping may lead to less accurate physics simulations, this issue has only been reported starting today. If Fixed Timestepping was not an option, this could have turned critical for our games.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.