Nope! Looks strange for sure. Can you send me a repro of the problem?
Not at all, it just means that more calculations are performed, making the simulation more accurate.
If I enabled this, would this improve performance of a large amount of parts moving on conveyor belts (Anchored parts with AssemblyLinearVelocity set). I’m wondering because almost the only things that have physics in my game are player characters and ores on conveyors. Would this new update help in this case?
Its difficult to send a repro, the plane has around 10.000 parts inside of it and a lot of scripts are tied to the game mechanics, i’d have to send over the whole game as a repro in my case.
I cant really set up a repro for this but it surely does happen every time i try it.
What should i do to help you out?
Gotcha, if you can DM me the PlaceID of the game, that would also help.
Possibly. If you would like to test it out, you can DM me and I’ll see if we can do some testing.
So we can change the Hz When we want?
That’s not what this means. Physics run at a frame rate independent of the frame rate. This is to allow physics to be simulated more accurately. For example when the physics rate is 240fps, that means that while your monitor will only display one new frame every 1/60th of a second, physics will have calculated 4 new frames in that timespan. These frames are only for physics and have nothing to do with code loops or the games refresh rate.
I’m curious how you determine if a part is safe to be assigned 60hz. Are you able to provide a brief explanation of how that will happen? Thanks.
I do not see this setting even after restarting Studio.
Restarted multiple times, beta feature is enabled.
Would it be feasible to allow us to completely disable physics simulation altogether? I know this sounds really stupid, but my game literally uses zero physics. By that, I mean that absolutely every single part in my world is anchored, everything. Yet the physics simulation still seems to take up non-zero time (when viewed with the microprofiler).
This adaptive property will be excellent for me because I am absolutely certain the engine will happily run my game’s physics at 60hz, so 4x cheaper. But in theory the savings could be pushed even further with no physics at all :P.
For perspective on how “unphysicsy” my game is, every part that I wish to move in the game has their CFrames set using the WorldRoot:BulkMoveTo method, which if I understood correctly, has some side effects of breaking physics interactions (or something along those lines). WorldRoot:BulkMoveTo
I remember that Natual Disaster Survival tested out 100 player servers once. But the physics were being solved wayy to slow which caused everything to be kind of stiff and boring. Meteors would despawn before they even reached the ground.
I hope this will make 100 player NDS possible. @Stickmasterluke
Try disabling the beta feature, restarting studio, enabling it and restarting studio again. that worked for me.
Have you considered each player’s character moving around as part of the physics simulated?
Still not working for me… weird.
When I say literally everything is anchor, I meant it. Including any character bodies. In fact, I do use roblox character rigs (but not humanoid physics) and I have custom code that plays back animations by loading the keyframesequence and manually doing the math. Every single limb of the character is anchored though.
Lets say the client has a vehicle that it networkly owns. And the server has physics step set to 60. If the client had it at set to like 240, would the server and other players see the client’s vehicle physics at 240, or 60? (assuming ping is 0)
Is this safe to use in a VR sandbox game?
Can I be sure the physics involving player rigs and the things they’re interacting with wont be stepped down to 120hz or 60hz?
How does the engine determine what is and what isn’t safe to have a lower step rate?
Overall I do like this as a feature. Lack of fine control and little detail on how it works is a little bit disappointing though. I hope to see some clarification before this gets rolled out to live games.
Regarding this update:
How does the solver determine when to increase the stepping frequency? Say, a 240hz part flying at 100km/h out of nowhere comes into contact with a 60hz assembly at rest. Is there one or two frames of 60hz simulation before the solver steps up to 120, or 240?
Is there a way for us to manually tell the solver that an assembly should be considered “at rest” (such as anchoring, then unanchoring the assembly)?