Unityの物理演算（physX）に関する諸々

Rigidbody同士の振る舞いにおいてインスペクターの階層（Hierarchy）上の親子関係は無視されます。

代わりに、Rigidbodyを固定したり接続関係を作る場合、ジョイント（Joint）系のコンポーネントに基づいてお互いを拘束する必要があります。普通のオブジェクトだとヒエラルキー上の親子関係が固定関係とイコールですが、リジッドボディ同士はジョイントを使わないと一切物理的な関係が発生しません。

(1,1,1)以外の値になってると計算量が増えるとかなんとか・・・

個人的な経験で言えば、(1,1,1)以外だと謎な場面で暴れだしたり力が変な方向に働いたりとか変な挙動になった気がします（※厳密には別の原因だった可能性はある）

物理演算パーツについては

• 物理的なサイズを変更したい場合：TransformのスケールではなくColliderのサイズだけを変える。

• 見た目上のサイズを変更したい場合：表示メッシュは子オブジェクトとして、物理演算パーツとは別のGameObjectにして扱った方が良いです。

基本中の基本ですが、物理演算に関する計算は基本的にUpdateでなくFixedUpdate内で行います。

なお、Update()関数の方は可変タイミングのため、移動量などにTime.deltaTimeを乗算するのがセオリーになっていますが、FixedUpdate内では通常その必要はありません。AddForce()メソッドを使って力を加える場合も、AddForce内でfixedDeltaTimeが乗算されるのでスクリプト側で乗算する必要はないです。

• ちなみにTime.deltaTimeはUpdate()から呼び出すとTime.deltaTimeが呼ばれ、FixedUpdate()から呼び出すとTime.fixedDeltaTimeが呼び出されるようになっているらしい。
• このページの一番下あたりで言及している「Simulation Mode = Update」の設定を使うと、UpdateとFixedUpdateをほぼ区別なく扱えるようになるそうです

らしい

それ以外の特定の位置にAddForceしたい場合は、AddForceAtPositionをつかひます

慣性テンソルは物体の回転しやすさを決める値だそうです。これによって、例えば同じだけ力がかかっても、回転が鈍重だったり軽やかだったりするような特性が再現されます。

質量中心は物体の重心のことです。当たり前ですが車のオブジェクトを作っても、前に重心がある場合と後ろに重心がある場合、挙動が全然違ってきます。

単一のコライダーの場合、通常はコライダーの中心が質量中心になると思いますが、例えば飛行機の胴体で前の方に重いエンジンが載っているから前の方が重いとか、そういうのを再現するためには正しく重心が設定されていなければいけません。

ただ、こちらの値も前の「慣性テンソル」同様、各Rigidbody物体の重さ・重心位置に基づいて、接続関係にあるオブジェクト全体で自動計算されます。複数の物理パーツから成るオブジェクトでは、各物理パーツの取り付け位置と重さによって全体としての重心が決まるため、RigidbodyのCenter of Massの値を直接変更する必要は通常はないと思います。

例えば前述の「飛行機の胴体の前の方に重いエンジンが載っている」というような場合でも、そのエンジンの重さがはっきりとわかっている場合は、適切に重さを設定した不可視のパーツをあるべき位置において胴体パーツにJointで接続固定するなどした方が、自動計算の恩恵を受けるうえで適切なやり方になると思います。

こちらは厳密には物理演算に限った話では無いのですが、浮動小数点精度（floating point precision）に関する制限があります。

intやbyteなどの整数のデータ形式は、整数を表すためにほぼ全てのビットが使えます。一方で浮動小数点の場合、少数も扱うためにもう少し複雑なやり方でビットを扱っているらしいです。その関係で、実際に整数としては扱える値の範囲はかなり小さく、整数部の桁が大きくなってくると小数部の精度が圧迫されて細かな位置情報が大雑把になり、原点（0,0,0）から離れれば離れるほど、結果としてオブジェクトやカメラが振動したりするといった現象が起きます。

よく、ゲームで地面のない場所をどこまでも落下したり、原点から遠く離れた場所まで行くと、次第に主人公モデルがカクカク振動し始めたりモデルがグチャグチャに暴れ始めたりする現象がそれです。

これらの問題はレンダリング表示上のジッターとして現れることが多いですが、物理演算も当然浮動小数点を使って行われています。そのため、表示だけでなく物理演算上の計算においても、あまり原点から離れてはいけません。

だいたい原点から6000m（正確には6000u）あたりの範囲にとどめておくのが良いようです。

軽すぎたり重すぎたり、小さすぎたり大きすぎたりするオブジェクトを使うなどすると、物理演算は不安定になり、結果も正しくなくなります。

• 力：10,000(N)未満

• 速度：0 ～ 1000(m/s)未満

• 重さ：0.01kg以上 ～ 10,000(kg)未満

くらいにとどめておくのが良いようです。

Rigidbodyをカメラで追うなどすると、物理演算のタイミングとカメラの更新タイミングが異なるため、カメラが振動したりするジッターが起こります。

これに対する対策として、通常はRigidbodyの「補間モード」を設定することで対処します。この補間モードはオブジェクトのTransformを補間しますが、Rigidbodyの姿勢には影響しません。

"補間は物理的なものではなく、レンダリングのみに使用されます。以前と現在のボディ ポーズを維持し、位置を補間して回転を滑らかにします。(中略)このため、補間時には Transform.position != Rigidbody.position を常に意識する必要があります。Rigidbody.position はシミュレーションの実行時に常に更新されますが、Transform はそれに一致せず、Interpolate / Extrapolateがオンの場合はフレームごとに更新されます。この場合、Transform は履歴的なものとなり、現在の Rigidbody.position の後ろにあり、現在の位置に向かって移動します。"

https://forum.unity.com/threads/how-to-properly-fix-camera-and-rigidbody-stutter-jitter-lag.1251702/

このことが問題を引き起こします。

例えば、補間モードがONになったRigidbodyからレイキャストを行う際、Transform.positionを引数としてレイキャストを行ってしまうと、FixedUpdateレートでの最新の位置ではなく、最後に補間された古い位置からレイをキャストしてしまうため、正しくない結果が返ってきてしまいます。

もしRigidbodyがこの正しくないレイキャストに基づいて位置を更新している場合、補間モードがONになっていても、オブジェクト自体が正しくないレイキャストに起因したジッターを起こしたりするので、結果的にオブジェクトはカメラ内でも振動して「補間モードがONなのになぜ…！？」的なことになります。

物理演算はFixedUpdateレートで行われ、補間は可変レートで後追いで起こる。Rigidbodyの最新の姿勢に、オブジェクトのTransformを後追いで合わせていくイメージですね。「補間がONの時、Transformの位置はRigidbodyの位置と基本的に一致しない」というこの原則を理解していないと、凝ったことをしようとするときに迷宮に入り込んでしまうことになります。

物理演算による最新の状態を得たい時は、Transform.position/rotationの代わりにRigidbody.position/rotationを使う必要があります。

前の項で述べた理由から、Rigidbodyをテレポートさせたい場合にはtransform.positionではなくrigidbody.positionを書き換えます（回転についても同様）。

1. transform.positionを変更　・・・　rigidbodyのことを一切考慮していないやり方なのでダメ

2. rigidBody.MovePosition()　・・・　移動に伴うスムーズな補間を計算してくれる移動法（補間モードがONの場合）。テレポート用途では補間はいらないのでダメ

3. rigidBody.positionを変更　・・・　補間を計算せずに直接位置を書き換えるのでテレポートにはこれが最適

なお、rigidBody.positionやrotationを直接変更しても、Rigidbody.velocityやangulerVelocityの値は残っていますので注意してください。そのままだとワープした先でもワープする前の加速度が残っているため、ワープ後に静止するためにはそれらをリセットする必要があります。

逆にPortalみたいにワープした先でも加速度を残したいゲームとか、floating originなどで位置だけを一瞬ですり替えるような用途では、加速度リセットはせずにrigidbody.position/rotationだけを書き換えればいいことになります。

前の２つの項で述べた「UpdateとFixedUpdateのタイミングの不一致」からくる様々な問題を、一気に解決できるのが2022.2から搭載された"Update"Simulationモードだそうです。

これは今までFixedUpdateタイミングで行われていた物理演算を、Updateのタイミングで行うようにするモードだそうで、それなら何も問題はなくなりますね！

ただ動画では「これは物理演算の更新タイミングが可変になることを意味するので、Deterministic（決定論的）性質が損なわれ、挙動に再現性がなくなる。物理演算を演出として使うゲームなら良いが、物理演算が重要な役割を果たしているゲームでは避けた方が良い」との注意もあり、ちゃんとしたシミュレーション前提のゲームでは依然としてSimulationモード＝FixedUpdateの状態で運用する方が良いかもしれません。