Currently, the highest frequency we can run code is at 60Hz, maybe since it’s variable and also, if I understand correctly, is directly tied to the rendering system and so is limited by both the CPU and GPU of the player. This is good for most purposes, but one thing it’s not good for, is custom physics.
When creating a spring simulation, the stiffness and damping of the spring is directly limited by the rate the code is executed:
Fkmax = m/dt^2 * x
Fcmax = m/dt * dx
But an additional reduction must also be applied to account for multiple springs attached to the same object, and then a further reduction to account for frame drops. At 60Hz, it’s difficult to make a realistically stiff and damped suspension without exceeding these limits and causing a feedback loop. The resultant force is sent to a VectorForce, so it’s not possible to run the code multiple times per frame, as a physics step must have passed for it to make a difference.
While I’m sure there are probably a few things I could do to help improve this (If any of you have any tips, it would be really appreciated!) most games that simulate performance vehicles use a timestep of 1/100 or lower https://www.lfs.net/forum/thread/48927-Racing-sim-physics-engine-rates
So why do you need a higher frame rate? Just run the physics update step for your spring multiple times per frame, X times with dt/X as delta for each step.
This is exactly what the internal physics subsystem does too. It does multiple steps per frame (throttled by performance etc etc).
This does not work, as the forces are calculated by lua, but then input into a VectorForce. Ideally the spring code would be able to run with every physics step, and know the duration each step is going to be, as this would allow the force limits to be drastically lower.
I would adjust the title to mention this – use case seems to be that you want to run code before each physics step, not just any code at a higher frequency (which I can’t think of a use case for that makes sense, for anything other than physics) EDIT: title was edited
One thing I’m having a serious problem with is how Heartbeat will slow down when the graphics card cant cope. I have no idea if this is fundamental to how Roblox works, but it does mean it completely screws up my physics when someone joins a large game with their graphics options manually set too high.
I’ve solved for a simple harmonic ODE and I can’t use a vector force and delta time to make the spring mass follow a predicted path given initial conditions.
This is due to the delta time in the future being unpredictable and the 1/60 sec will not suffice for accuracy when applying acceleration.
EDIT: This could be also be fixed I we could get the rate that physics is going to update at before it does.
I’m trying to calculate how much a velocity has to be before a physics step to reach a certain location and I just can’t find any way due to you only being able to access delta time of the PreSimulation event which isn’t what’s used to calculate the physics it seems.
The delta time of .Stepped is supposed to be the amount of physics time that will elapse this frame. As the adaptive time-stepping works in multiples of 60Hz, this really should work independently of the new adaptive time stepping, but since this parameter is documented wrong on the developer hub you’d have to run some tests to actually find out.
Although having said that, if you’re having to do these calculations I suppose your game should probably be on Fixed timestepping anyway and you can just keep using PreSim.
