Box3D - オープンソース3D物理エンジンを公開
(box2d.org)- ゲームサーバーで大規模な3D物理シミュレーションを直接制御する需要が高まる中、Box3DがBox2D系のオープンソース3D物理エンジンとして公開された
- 構造はBox2Dに近く、C API、C17ソース、サブステッピングソルバー、連続衝突、グラフカラーリング、wide SIMD接触ソルバー、マルチスレッディングフックを含む
- Unreal EngineのChaosでジャイロスコピックトルク、木の倒壊、大規模broad-phaseの要件を満たしにくかった経験が開発の直接的な背景となった
- 三角形メッシュ・ハイトフィールド・baked compound collision、doubleベースの大規模ワールド、クロスプラットフォーム決定性、記録/再生が3Dゲーム向け機能として盛り込まれている
- 複数のゲーム・エンジンですでに使われているが、まだアルファソフトウェアであり、v0.1タグ以降v1.0までテストとドキュメント強化が必要である
Box3Dの性格と主要機能
- Box3DはGitHubで公開されたオープンソースの3D物理エンジンであり、Box2Dの設計を3Dゲームの要件に合わせて拡張したプロジェクトに近い
- 中核アーキテクチャはBox2Dとほぼ同一で、ライブラリ全体のソースはC17で書かれている
- 主なエンジン機能は次のとおり
-
C API
- サブステッピングソルバー
- 連続衝突
- 大規模アイランド向けグラフカラーリング
- wide SIMD接触ソルバー
- マルチスレッディングフック
- オプションの内部スケジューラー
- 位置にdoubleを使う大規模ワールド対応
- クロスプラットフォーム決定性
- 記録と再生
- 3Dゲーム向けに追加された衝突機能も含む
- 三角形メッシュ衝突
- ハイトフィールド衝突
- baked compound collision
-
The Legend of Californiaで生じた必要性
- Box3Dの最初の開発動機は、Kintsugiyamaで開発中のThe Legend of Californiaだった
- このゲームはUnreal Engineで制作され、プロジェクトはUnreal 5.0で始まった
- Unrealの標準物理エンジンであるChaosの実験で、複数の限界が明らかになった
- ジャイロスコピックトルクのシミュレーションをサポートしておらず、細長い物体が角速度を保ったまま長く回転する挙動を扱いにくかった
- 開発者は2015年のGDCで、物理エンジンにジャイロスコピックトルクを追加する約10行のドロップインアルゴリズムを発表したことがある
- Epicはこの機能を2024年末にUnreal Engineへ追加した
- より大きな問題は、サバイバルゲームの中核機能である木こりで発生した
- 倒れる木が不規則に動き、画面上で瞬間移動した
- 状況は、大きなカプセルが滑らかな三角形メッシュの上に落ちるシミュレーションで、容易に処理できるはずのケースだった
- サーバーには数十万のエンティティが存在するため、高速なbroad-phaseも必要だった
- この要素はゲームの中心にあるため、ミドルウェアに任せるのは危険だと判断した
- 開発者はbroad-phaseデータ構造の経験が豊富で、関連するGDC発表も行ったことがある
Rubikon-LiteからBox3Dへ
- 既存のオープンソース物理エンジンであるJoltの利用も検討したが、Dirk GregoriusがRubikon-Liteをフォークして必要に合わせて修正する方式を提案した
- Dirk Gregoriusは、Half-Life: Alyxに搭載されたカスタム物理エンジンRubikonを作った物理プログラマーであり、趣味・ホーム版のRubikonを保守している
- Rubikon-LiteをUnrealに直接接続すると、ジャイロスコピックトルクが動作し、木も正常に倒れた
- Unrealの物理エンジン置き換えでは、いくつかの近道を活用できた
- Blueprintではなく独自のスクリプティングシステムを使用している
- Esoterica animation systemをUnrealへ移植して使用している
- Box3Dに直接接続されるカスタムECSを使用している
- Box2D v3.0の最適化をRubikon-Liteフォークへ取り込もうとする中で、2Dと3Dの作業を可能な限り似たものに保つ必要が生じた
- Rubikon-LiteのほぼすべてのAPI、データ構造、アルゴリズムをBox2Dのコードに置き換えた
- 2Dと3Dのデータ構造のかなりの部分は、空間次元に依存しなかった
- 時間とともにRubikon-LiteフォークはBox3Dへと変わった
- 現在のBox3Dには、convex hull生成と一部の衝突アルゴリズムにRubikon-Liteのコードが残っている
- それ以外はBox2Dのコードと、Box3D向けの新規コードで構成されている
- Valve側ではRubikonが引き続き進化しており、DirkはBox3Dに似た最適化を新エンジンRagnarok向けに開発している
カスタム物理エンジンで合わせたゲーム要件
- The Legend of Californiaは、大規模なオープンワールドとサーバー権限型アーキテクチャを持つプロジェクトである
- 倒木、ラグドール、ボクセル、サルーンの扉、タンブルウィードのすべてがサーバー上でシミュレーションされる
- カスタム物理エンジンを使えば、ゲーム要件に合わせて機能と性能を直接調整できる
- 性能改善は特に倒木に多く割かれた
- 巨大なredwoodの木がボクセル地形の上へ高速に倒れる
- メッシュ衝突とCCDを安定して動作させる作業が大きかった
- ボクセルシステム用の衝突メッシュもランタイムで高速に作る必要があった
- ボクセルは格子状なので、median splitでうまく構成できる
- ストリーミングも重要な要件だった
- strongholdはkitbashingで構成される
- 大きなstrongholdには、個別の衝突メッシュが約50,000個存在することがある
- これを物理エンジンに1つずつロードすると非効率で、メモリも多く使う
- 個別の衝突形状を最適化データ構造へ調理し、単一のuber shapeとしてロードするcompound collision systemを作成した
- この方式により、数千個のbodyとshapeを作成するオーバーヘッドを取り除いた
オープンソース化した理由と対象ユーザー
- 開発者は2004年からゲーム向け物理エンジンを作ってきたが、転職のたびにその作業を置いていかなければならなかった
- Box2Dには、知識と努力をオープンソースプロジェクトとして蓄積し、その後の仕事の基盤として使うために作られたという側面がある
- 3D分野では、同様の作業を何度も作り直す負担があった
- KintsugiyamaはBox3Dをオープンソースとして公開し、業務の一部として取り組めるよう許可した
- Box3Dは他の物理エンジンと競争するためのプロジェクトではなく、Box2Dの設計が気に入っているユーザーならBox3Dもよく合う可能性が高い
始め方とドキュメント
- Box3Dを始めるには、基本的なgitとCMakeをインストールした後、Box3D repositoryをクローンすればよい
- ビルド方法はREADMEにある
- ビルド後はサンプルを実行して機能を確認し、サンプルコードをもとにコーディングを始められる
- エンジンヘッダーには完全なDoxygenコメントがあり、執筆中のマニュアルも進行している
- ホストされたdocumentationが提供されている
- 最小サンプルコードはHelloWorld testで確認できる
現在の採用先と今後の計画
- Box3DはThe Legend of California以外にも、すでに複数の場所で利用されている
- s&box: Facepunch Studiosのゲームプラットフォーム
- Esoterica: Bobby Anguelov率いるオープンソースゲームエンジン
- A 1000-player space game: Glenn Fiedlerのマルチプレイヤーゲーム
- 複数のゲームで使われているが、Box3Dはまだアルファソフトウェアと見なされている
- 近くv0.1タグを作成し、v1.0リリースまで発展させる計画である
- さらなるテストと完成度の高いドキュメントが必要だが、機能セットはすでに良い位置にある
- 検討中の作業は次のとおり
- キャラクター移動機能の強化
- ghost collision軽減の改善
- 最適化
- joint solverの改善
- Box2Dとともに、Box3Dも無期限にサポートしていく見込みである
- 成熟段階に達すれば、機能開発はいったん落ち着けるかもしれない
- Box2Dと異なり、Box3Dではpull requestを受け付ける見込みで、CLAを使う可能性がある
- Box3D専用のWebサイトやDiscordサーバーは作らない
- 更新情報はBox2Dサイトで提供する
- 会話はBox2D Discord serverで行う
- Box3DがThe Legend of Californiaで動作する様子を見たい場合は、home pageとSteamでフォローできる
1件のコメント
Hacker News のコメント
Box2Dの名前が出るたびに、同じ作者による Box3D ライブラリという当然のつながりと一緒に、昔のこんな話を思い出す
https://kotaku.com/this-guy-created-angry-birds-physics-and-...
Vesterbacka は「イベントが終わったら私のところに来てください」と返し、たぶんそのとき Erin はパーカーをもらえたのかもしれない。その後すぐにクレジットへ名前が追加されたそうだ
みんなが驚いたのは、マーケティング担当者がどの物理エンジンを使っているか把握していたことだった
Box2D はかつて物理ベースのインディーゲームを支える存在だった
今の状況は十分に空白があるので、再び盛り上がる余地があるのか気になる
こういう小さく閉じた一覧に新しい項目が増えるのは、いつだって歓迎すべきことだ
Box2D と、そして今の Box3D の C API は本当に扱いやすい
これは本当にうれしい。Erin Catto は素晴らしいハッカーだし、オープンソースコミュニティにコードを共有してくれて感謝している
発表では 決定性(determinism) に触れられていなかったけれど、その点ももっと見てみたい。Unity 内蔵の物理でネットワーク対戦のビリヤードゲームを作ろうとすると、各クライアントが何が起きたのか一致できず、かなり厄介になる
ドキュメントによれば
-ffast-mathはサポートしていないので、もしかするとクロスプラットフォームの決定性を意図しているのかもしれない: https://box2d.org/documentation3d/recording.html修正:
ffast-mathに関する意味を明確化機械学習の研究者として、Box2D には 強化学習環境を通じてなじみがある。OpenAI Gym の Lunar Lander や Car Racing のような標準ベンチマーク環境を支える基盤だ
https://gymnasium.farama.org/environments/box2d/car_racing/
物理シミュレーションは危険な沼だ。剛体と物理的にもっともらしい挙動だけに絞っても、衝突検出と衝突解決には未解決の問題が多い
幾何では凸近似や分解を使い、ソルバは手作業でチューニングするのが一般的で、堅牢性と精度は常に速度とのトレードオフになる
これは本当に待ち望んでいた。以前 Box2D でかなり成功したことがあり、F/OSS の中でも間違いなく最上位クラスの成果物だ
Box3D ベースの Spectre VR？ これはきっと出てきそうだ。Tanarus っぽさもある
修正: Legend of California デモ（Unreal Engine ベース）で録画と再生に切り替わる部分は、かなり急激な飛躍に見える。最初は少し基本的に感じても、デモ動画の少なくとも 18 分あたりまではぜひ見てほしい。かなり荒削りながら面白くなってきて、録画と再生機能がすごい
Rapier、その前だと Cannon と Ammo を少し知っているが、Box3D と比べてどうなのか気になる
ついでに言うと、数週間前に自分でも 3D 空間の物理エンジンを作ってここで共有した。実際には一定間隔で物体を下に移動させる 1 行のものだが、それでも驚くほどうまく動く。学習目的としては本当に面白いので、一度やってみるのを勧める
ここ数日 Jolt を使ってブラウザ向けの Tron 風 3D ゲームを作り始めたところなので、ちょうどこれを見ると面白い。今のところ Jolt はかなりうまく動いているが、これもぜひ見てみるつもりだ
1 - このドメインは何年も前から持っていた: https://lightcycles.io
Jolt とどう比較されるのか気になる。どちらも経歴は良さそうだが、一方は Valve と Erin Catto の系譜で、もう一方は Horizon シリーズで使われていた
「Valve 側では Rubikon が引き続き進化しており、Dirk は Box3D に似た最適化を新しいエンジン Ragnarok 向けに開発した。今後の Valve のゲームで目にすることになるだろう」
ちょっと待ってくれ……
Box3D
3D
3
希望！