多くのレーシングゲーム（たとえば、バーンアウトパラダイス）では、衝突が発生しようとすると、ゲームのプレイは自動的にスローモーションに切り替わり、衝突が完了するまでスローシーケンスで続行されます。
これは効果のためだといつも思っていました。衝突の一部を見逃したくない！しかし、私の友人の1人は、衝突が発生したときに必要とされる処理の圧倒的な速度がないことを確認するためにこれが行われることを最近提案しました。
今、私はそれが実際には逆だと思います。衝突が発生すると、多くの詳細がスローモーションで表示されるため、コンピューティングとレンダリングのパイプラインにオーバーヘッドがあると確信しています。
何が正しいですか？
スローモーションシーンは、CPU / GPU使用量を増やしますか、それとも減らしますか？
回答:
（必要に応じて）固定タイムステップで物理シミュレーションを実行している場合、スローモーションは物理シミュレーションへの負荷を軽減します。これは、フレームごとに実行する必要がある計算が少なくなるためです。
1秒あたり200回の更新で物理演算を実行しているとします。例えば。0.005シミュレーション時間の毎秒1回の更新。1秒あたり50回の更新でゲームを実行すると、レンダリングの更新ごとに4回の物理更新が発生します。ここで、ゲームをスローモーションで実行します。つまり、シミュレーション時間を遅くします。したがって、ゲームが1 0.02秒あたり50回の更新（シミュレーション時間の秒数）で実行されていても、世界をスローモーション（半分の速度としましょう）で表示している場合、1フレームは0.01シミュレーション時間の秒数に相当します。そのため、レンダリングされたフレームごとに2つの物理演算のみが更新されます。レンダリングされたフレームあたりの物理演算が少ないことを意味します。
したがって、レンダリングされたフレームあたりのCPU使用率の観点から見た場合、スローモーションはCPUの負荷が低くなります（スローモーション中に物理シミュレーションレートを上げることを選択しない限り）。フレームあたりのGPU負荷はもちろんほぼ一定です。
1回の衝突の間の累積CPU / GPU負荷について質問している場合、スローモーションであろうと通常の速度であろうと、物理シミュレーションは明らかに同じです。より多くのフレームをレンダリングするため、GPUの負荷が高くなります。
可能、こうである可能性があること。GPUでの衝突の物理演算を行わない限り、それはスクワットを意味します。しかし、物理学自体に関しては...それは可能です。
複数のボディの動きをシミュレートしている場合、ボディは非常に予測可能な方法で動く傾向があります。力と力場（つまり、重力）は簡単に予測できます。物事の移動する場所はすぐに計算されます。
あるものが別の物にぶつかるまで。物理学では、タイムスライスと呼ばれるものがあります。これは、物理システムの実行がカバーする時間です。タイムスライスが1/30秒（物理更新の場合30fps）をカバーしている場合、各物理更新はオブジェクトを33.3ミリ秒先に移動します。
オブジェクトが衝突しない場合は、33.3msの最初から最後まで移動するだけです。そうするための物理学は単純であり、何世紀にもわたってよく知られています。正味の力から加速度を決定し、タイムスライスの加速度をオブジェクトに適用して、新しい速度で移動します（注：精度を高めたい場合は、さらに複雑になる可能性があります）。
問題は、オブジェクトが衝突したときです。突然、今、物理スライスを最初に一度だけではなく、タイムスライス内で処理する必要があります。物理フレーム内でオブジェクトが2回または3回衝突する場合は、やり直さなければならない物理計算が増えます。
1つのタイムスライス内に多数の衝突がある場合は、フレームレートを本当に殺すことができます。ただし、タイムスライスのサイズが小さくなると、タイムスライス内で複数の衝突が発生する可能性が低くなります。ForzaやGran Turismoなどのハイエンドレーシングシムは、驚異的なフレームレートで物理システムを実行します。そのうちの1人は、物理演算の更新で最大300 + fpsを得ると思います。
スローモーションはそれと実質的に同等です。補正するためにレンダリングフレームレートを増加させることなく物理タイムスライスを減少させることにより、世界はより遅く見えます。したがって、タイムスライス内で複数の衝突が発生する可能性が大幅に低くなります。
そうは言っても、このようなゲームがスローモーションになる理由は間違いありません。一般的には、視覚的でドラマティックな表現に適しています。これらの物理システムは、一般的に、パフォーマンスを考慮して処理できます。
まず、これは視覚的な効果のために行われ、パフォーマンス上の理由ではありません。
物理学の重いゲームでパフォーマンスを処理する標準的な方法は、オブジェクトの数をスケーリングし、オブジェクトの複雑さをスケーリングし、エンジンの設定をいじってシミュレーションの精度とパフォーマンスをスケーリングすることです。問題がある場合は、最も重要でない機能であると思われるものを削除します。
ただし、業界では過去15年ほど、かなり現実的な自動車ゲームを作成してきました。現代のコンピューターでは、3つの車輪にスケールを戻して物事を実行する必要はありません。
問題：
衝突により余分な作業が発生する可能性があることは事実であり、その程度はゲームの詳細に大きく依存します。より詳細な物理エンジンは、必要な計算の大幅な増加を構成する可能性のあるさまざまなパーツ間の小さな衝突を多数行います。しかし、物理学がスケーリングされるとき、それは考慮に入れられるべきです、それでもいくつかの衝突を処理することができる良い物理学を得ることは問題ではありません。
単純に物理シミュレーションをゆっくり実行してスローモーションを取得すると、それに比例して負荷が低下します。ただし、スローモーションとリアルタイム物理の要件は異なるため、何かがレーシングスピードで発生する場合は、精度を低くすることもできます。プレイヤーが物理エンジンが間違っていることに気付かない限り、それは大きな問題ではありません。スローモーションは、スリップを非常に簡単に捕らえるので、スローモーションにはより高い精度要件があります。
両方の要件を満たすようにスケーリングされた同じ物理を使用することを選択できます。このソリューションには追加の処理能力が必要ですが、実装が簡単で、最新のコンピューターを完全に実行可能にすることができます。
物理設定の切り替えはより複雑ですが、いくつかのゴージャスな衝突が発生する可能性があります。精度を向上できるだけでなく、自動車の物理モデルを切り替えて、より現実的な方法で壊れるより詳細な物理モデルに切り替えることもできます。このモードは、両方とも同じminspec構成で実行するようにスケーリングされているという理由だけで、通常モードとほぼ同じ物理時間のCPU時間を使用することになります。
真ん中の方法は、可変ステップ物理エンジンを使用することです。シミュレーションを遅くすると、一般に精度が向上し、問題の少なくとも一部が解決されます。可変ステップ物理を使用しない理由は他にもありますが、可変ステップは業界ではまだかなり一般的です。