Having worked through half of the Nature of Code book and implemented all of its physics examples, I realized that the physics libraries are all approximations (not simulations) of the real world. To make the approximations as close as possible to what we see in the real world, you need to make many more fine calculations. This limits the frame rate at which the simulation can run. You either run your simulation less accurately at 30 updates-per-second, or you run it with increased accuracy at 10 updates-per-second. When demo-ing physics libraries, authors usually want to showcase the small details that increase realism. This leads to more calculations, which leads to a greater slowdown.
I think gravity is the first force we notice when it's off, because we're very used to seeing objects fall. For gravity to feel right, it needs to feel like 9.8N/kg at a specific framerate. If you update less often, you'll slow down the world. If you update much faster, objects will fall faster. You might want to increase the value of gravity to 19.6N/kg if your fps is 50% slower to maintain the illusion of the real speed, but that effectively means that objects will skip ahead 19.6 units instead of just 9.8units, and that affects collision accuracy. There are a lot of parameters like this that can be tweaked, but since many results are then used as inputs to other calculations, changing one parameter affects the entire simulation. Once you reach a certain level of realism, you don't want to adjust those parameters again for a different rate of updates-per-second.
In theory. this shouldn't happen if you run your physics library as a state machine that takes time as input, and outputs the state of the system into your renderer. This should let your physics simulation run at 30 updates per second, and your graphics rendering at 60fps. In practice, they're all running on the same machine, along with any video capturing, and are competing for resources. This leads to slow-downs, which you notice as slow-motions.
If anyone can explain this better, please do chime in.
Having worked through half of the Nature of Code book and implemented all of its physics examples, I realized that the physics libraries are all approximations (not simulations) of the real world. To make the approximations as close as possible to what we see in the real world, you need to make many more fine calculations. This limits the frame rate at which the simulation can run. You either run your simulation less accurately at 30 updates-per-second, or you run it with increased accuracy at 10 updates-per-second. When demo-ing physics libraries, authors usually want to showcase the small details that increase realism. This leads to more calculations, which leads to a greater slowdown.
I think gravity is the first force we notice when it's off, because we're very used to seeing objects fall. For gravity to feel right, it needs to feel like 9.8N/kg at a specific framerate. If you update less often, you'll slow down the world. If you update much faster, objects will fall faster. You might want to increase the value of gravity to 19.6N/kg if your fps is 50% slower to maintain the illusion of the real speed, but that effectively means that objects will skip ahead 19.6 units instead of just 9.8units, and that affects collision accuracy. There are a lot of parameters like this that can be tweaked, but since many results are then used as inputs to other calculations, changing one parameter affects the entire simulation. Once you reach a certain level of realism, you don't want to adjust those parameters again for a different rate of updates-per-second.
In theory. this shouldn't happen if you run your physics library as a state machine that takes time as input, and outputs the state of the system into your renderer. This should let your physics simulation run at 30 updates per second, and your graphics rendering at 60fps. In practice, they're all running on the same machine, along with any video capturing, and are competing for resources. This leads to slow-downs, which you notice as slow-motions.
If anyone can explain this better, please do chime in.