I would also love to know if they plan on letting us mess around with these options as much as possible, to tie a fixed physics frame rate for certain situations and objects. Would love if they plan on keeping the Adaptive and Fixed options too, so developers can change according to how they see fit for their games.
example: setting a model to always have a simulation rate of 240hz and another model always running at a rate of 60hz, only changeable thru scripts
example2: setting a fixed value of 60hz or lower if said type of game has too many physics objects to calculate, for when the developer wants a consistent frame rate for physics rather than an adaptive version.
I also would like to support this idea, this would be useful for games that don’t really need to run the physics at 240hz or 120hz so instead we can cap it at 60hz, having a performance boost in the game overall.
I love the update but my one question is, will this make a game lag much. I have seen with a lot of physics stuff I have been testing with I lag a lot, so I am wondering will this affect the games frame rate.
This is cool, but it would be nice if we had control over the physics framerate itself.
It is no news that not being able to run code between the physics steps is a huge downside. I believe that projects which use custom physics, such as raycast cars, would benefit immensely from being able to disable physics stepping entirely. That way we can get accurate information on collision and prevent unwanted interactions between instances, even if it comes at a cost of accuracy.
I love the feature, when this is finished it’s gonna be sick
I know it’s in beta and all, but the projectiles just become overall slower and a bit choppy most likely due to the fixed step rate, I tried playing around with the PhysicsSteppingMethod property under workspace, but I haven’t been able to get that good of a result
And that is adaptive(default is pretty much the same as fixed result wise) There aren’t any options to change the step frequency manually, that’d be just awesome, being able to manipulate the way that the physics engine works on studio would be shocking for a lot of people, me included
Even though the feature is in beta and lacks major patches and whatnot, the idea is amazing and I’d be more than happy to see this feature implemented in the feature, not as a beta feature but made it public some day
Why not have both, with Adaptive doing automatic frequency assignment and Fixed letting you set a value? I’m sure many experienced developers would love to have those options to get Roblox closer to the customizability of Unity and Unreal engine.
The whole point of adaptive (at least, in my point of view) is that those who don’t want to deal with manually optimizing physics, don’t have games that require consistent physics (like physics-based puzzle games), or just don’t really understand how to mess with physics can just use Adaptive to do the job for them, while Fixed lets more experienced developers control how they can optimize their games and maintain consistency in their own ways.
I love this however when using a bodyposition and adaptive timestepping. the stepping starts rapidly swapping between 240hz and 120hz resulting in erratic and spontaneous movements
Without / fixed timestepping
the part just stays mid-air without rotating at all like its expected to
here’s a copy of the place file: Adaptive timestepping bodyposition bug.rbxl (26.0 KB)
the only thing added is a single part with a bodyposition and the only property changed on the bodyposition is the maxforce
this bug can be reproduced by simply adding a bodyposition to any part whilst having adaptive timestepping enabled
I think having Fixed as an option would be good for games where the physics are highly constrained and expected to behave in very specific ways; having an automatic system running in the background which might decide to change the frequency at seemingly random points will result in less predictable simulation.
Automatic is obviously more desirable for games where the physics are more dynamic, like maybe in one moment you have a perfectly rigid block tower, and in the next moment, the tower blows up. But for games where the physics is expected to behave consistently, even though a well designed automatic system should hold a steady simulation rate, it’s just one extra variable that one might want to eliminate that could potentially introduce problems in some edge cases in the future.
