Our game consists of fast-moving projectiles, revolving around ROBLOX’s guarantee of a robust physics engine. We do not require that many physics computations, and so we rely on the accuracy of a fixed PhysicsStepping method. This report is to indicate that the Adaptive Timestepping method is too unreliable for games like ours, in case the sunsetting of the fixed timestepping method is ever decided.
Here is an example video where a fast-moving projectile (a couple hundred studs/sec of velocity) goes straight through a wall in the adaptive timestepping method.
Here’s the test place used to reproduce the issue.
Using the Fixed Physicsstepping method, collisions always occur as expected at this speed.
I don’t really expect the projectile to collide with the wall with the adaptive method, I understand the implications of a lower-frequency physics stepping approach. I’m posting this to indicate that some developers still critically need an accurate physics system over a performant one (and we’ll find other ways to improve performance). This is a recommendation to keep the Fixed PhysicsStepping method for as long as feasibly possible, or to propose an alternative to its eventual sunsetting.
Thank you for the report and the test place. We are looking into improvements to the adaptive system and this kind of behavior is exactly what we want to improve. Ideally, the Adaptive stepping system is something that you should never really notice and you can rest assured that we won’t be eliminating the fixed option until that is the case.
For this particular setup, it looks like the projectiles are already simulating at 240Hz, so its unclear why there would be any changes between fixed and adaptive.
Thanks for your reply. Could you expand on what you mean by “it looks like the projectiles are already simulating at 240Hz”? My understanding was that the stepping would change between 240, 120 and 60Hz based on performance, but I’m not sure if we can actually see when the frequency changes in studio. Do you mean that the example place is simple enough that it shouldn’t cause the physics step to be less frequent than 240Hz, or is it something else entirely?
You can enable Studio Settings > Physics > Are Timesteps Shown to debug the stepping rate for each physics object. The objects highlighted in Red are the ones being stepped at the maximum 240hz, which is what Fixed will use for every object, but any other colour will be for rates lower than that, which is what Adaptive brings to the table: Use lower rates for less precision-dependent object physics.
i.e., a Red-outlined object should act consistently, regardless of whether in Fixed or Adaptive mode. Check and see if your projectiles are outlined in Red like they should be, as they are fast-moving and clearly need all the precision they can get.
Thanks for the info. Testing this a bit further with this setting on, I can now say that the superballs are being simulated at 240Hz at the time of collision, whether they bounce or go through the wall; however I’ve tested this further and can find rare cases where they will also go through the wall with the Fixed PhysicsStepping method, because of how fast the projectiles are, so I guess the Fixed and Adaptive methods might be more similar than I originally thought.
The issue was originally reported on a larger game, where shooting a superball at the floor of the lobby would occasionally make it go through said floor. In that larger game, however, the superballs seem to often simulate at 120Hz instead of 240Hz, which causes more of them to go through the floor. This is still a bit strange to me, because there are very few assemblies in the lobby, and strictly nothing outside of the lobby during intermissions, so I’m not sure why the frequency is being lowered in that scenario.
Totally doable - but in my opinion it points to a larger issue where those projectiles still require high accuracy and are not given this benefit in cases where they should be. Our games include maps which were not designed with this issue in mind, and reworking those would take a bit more time than fixing the floor of this lobby. In a perfect world, I think those projectiles should always be simulating at 240Hz, especially in environments with few moving parts, which is why we’re currently encouraging devs in our community to always use the Fixed PhysicsStepping method for small games.
That’s understandable But I think encouraging it’s use heavy-handedly could end up with misunderstandings and, maybe, some games running worse than they could be (which is what Adaptive was introduced to mitigate). Regardless, I look forward to this issue being fixed. They’ve kept the Fixed mode specifically for this interim until they implement it, after all.
Just to clarify a little bit about how timesteps are selected. We actually select the timestep based on the dynamics of the system and not based on any sort of computational budget. The selection will be the same whether you have a large number of moving parts or just a single part. We use things like the part’s velocity, its acceleration and the constraints acting on it to determine if we can drop to a larger timestep without sacrificing accuracy or stability. When this process is applied across the entire experience, it frees up resources for other systems and should generally improve performance overall, but it isn’t directly tied to the available hardware or the amount of work the physics system needs to do. Because it can always chose a small timestep when required, we should eventually get to a point where this system “just works” , providing a performance improvement without any outward signs that the system is doing anything different. That said, we are still addressing edge cases and improving our timestep selection logic to ensure we see the same behavior as Fixed timestepping.
Super interesting response, thank you very much for the clarification. I always wondered what parameters were taken into account when selecting the timestep for an assembly’s physics.
I don’t know if this was discussed before: do you reckon it would eventually be possible to “fix” the timestep of a single given assembly? I’m taking a shot in the dark here to assume that, in the future, maybe a superball’s physics would lower to 120Hz or 60Hz if it’s high in the air and there’s zero chance of it colliding with anything. If that’s the case, because of the Local Truncation Error in the current integration method, the superball might land in a different spot based on the timesteps that were selected throughout its trajectory. In our games, it’s not unlikely for a good player to land shots across the map, where the projectile is in midair for more than a second; if my calculations are correct, the LTE for a 240Hz superball at default gravity would be around 0.4 studs/sec, and 1.6 studs/sec for a 60Hz superball, resulting in a height difference of 1.2 studs after a second, which could create some frustrating (even if minor) inconsistencies for high-level players.
I think generally we would like to avoid such fine grained controls but its not completely out of the question. For things like Collisions and Aerodynamics, we do have properties that allow Creators to control the fidelity of the physics. If there was no other way to achieve the desired affect, we could consider something similar for timestep control. For now, we are hoping we can arrive at an acceptable set of heuristics so that manual control won’t be required. We explicitly look at terms that affect the local truncation error of our integration so the timestep should reduce when we detect that this error will be large.
But I think encouraging it’s use heavy-handedly could end up with misunderstandings and, maybe, some games running worse than they could be (which is what