Is showing a collision in slow motion computationally relaxing?

Question

In a lot of racing games (Burnout Paradise, for example) when a collision is about to happen, the game play automatically switches to slow motion and carries on in slow sequence until after the collision is complete.

I always thought this was for the effects. You don't want to miss any part of the collision! But one of my friends recently suggested that this is done to make sure there is not an overwhelming rate of processing required when a collision happens.

Now I think it is actually the other way round. When a collision happens, so many details are shown in slow motion, I am sure there is an overhead on the computing and rendering pipeline.

What is correct?

Does a slow motion scene increase CPU / GPU usage, or decrease it?

Answer 1

If you're running your physics-simulation with a fixed timestep (as you should), then a slow-motion will put less load on the physics-simulation, because less calculations will have to be made per frame.

Let's assume you're running your physics with 200 updates per second. Eg. one update every 0.005 seconds of simulation time. When running the game with 50 updates per second, that would result in 4 physics updates per render update. Now you would run the game in slow motion, that means you're slowing down simulation time. So if the game still runs at 50 updates per second (0.02 seconds of simulation time), but you're showing the world in slow-motion (let's say half the speed), then one frame would be equivalent to 0.01 seconds of simulation time. So only 2 physics updates per rendered frame. Meaning less physics-calculations per rendered frame.

So if you're looking at it from the perspective of CPU usage per rendered frame, then slow motion is less CPU heavy (unless you choose to increase your physics simulation rate during the slow-motion). GPU load per frame is of course pretty much constant.

If you're asking about cumulative CPU/GPU load for the duration of one collision, then obviously the physics simulation is the same, be it slow-motion or normal-speed. The GPU load will be higher, because you render more frames.

Answer 2

It is possible that this could be the case. Unless you're doing physics for the collision on the GPU, it means squat for that. But in terms of the physics itself... it's possible.

If you're simulating the movement of a number of bodies, they tend to move in a very predictable way. Forces and force fields (ie: gravity) are easily predictable. Where things move is quickly computed.

Right up until one thing hits another. See, in physics, you have what is called a timeslice; this is the amount of time that the execution of the physics system covers. If your timeslice covers 1/30th of a second (30fps for the physics update), then each physics update moves objects 33.3 milliseconds into the future.

When objects don't collide, you can just move them from the beginning of that 33.3ms to the end. The physics for doing so are simple and has been well-known for centuries. You just determine the acceleration from the net forces, apply that acceleration for the timeslice to the object, and move it at its new velocity (note: this can be more complex if you want greater accuracy).

The problem is when objects collide. Suddenly, now you have to process physics forces within a timeslice, rather than just once at the beginning. If an object collides twice or three-times within a physics frame, then that's more physics computations you have to redo.

If you have a lot of collisions within one timeslice, you can really kill your framerate. However, the chance of multiple collisions within a timeslice decreases as the size of the timeslice decreases. High-end racing sims like Forza and Gran Turismo run their physics systems at incredible framerates. I think one of them gets up to 300+fps on their physics update.

Slow-motion is the effective equivalent of that. By decreasing the physics timeslice without also increasing the rendering framerate to compensate, the world appears slower. And therefore, you make it much less likely that you get multiple collisions within a timeslice.

That being said, I do doubt that this is why games like this go into slow-motion. In general, it's more for visual flair and dramatic presentation. Those physics systems can generally handle it, performance wise.

Answer 3

First of all, this is done for the visual effect, not for performance reasons.

The standard way of dealing with performance in physics heavy games is to scale the number of objects, scale the object complexity, and fiddle with engine settings to scale between simulation precision and performance. If there is problems you'd drop what you perceive to be the least significant features.

Do remember though, the industry has made pretty realistic car games for the past ~15 years, with modern computers it's not like they have to scale back to 3 wheels to get things running.

The problem:
It is true that a collision may cause extra work, how much depends a lot on the specifics of the game, a more detailed physics engine will have a lot of small collisions between different parts that may constitute a significant increase in required computation. But that should be taken into account when the physics is scaled, it's not a problem to get good physics that can still handle some collisions.

If you simply run the physics simulation slower to get slow motion the load will drop proportionately. However, one should note that the requirements for slow motion and real time physics are different, you can afford to have lower precision when stuff happens at racing speed. As long as the player does not notice that the physics engine is wrong it is not a big problem, the slow motion makes the slips much easier to catch, thus the slow motion has a higher precision requirement.

One may choose to use the same physics, scaled to meet both sets of requirements. This solution will require some extra processing power, but it's easy to implement and given modern computers perfectly viable.

Switching physics settings is more complicated, but can potentially result in some gorgeous collisions, not only can one increase the precision, it is also possible to switch the physics models of the cars for better detailed ones that break in more realistic fashion. This mode should end up using approximately the same amount of CPU time for physics as the normal mode, simply because they are both scaled to run at the same minspec configuration.

A middle way is to use a variable step physics engine, those will in general increase the precision when you slow down the simulation, thus solving at least part of the problem. There are other reasons not to use variable step physics, but variable step is still pretty common in the industry.