3D物理エンジンOSS「Box3D」とは｜Box2D作者による新作の特徴

3D物理エンジンOSSを検討していると、必ずと言っていいほどBox2Dの名前が話題に上ります。2D物理エンジンのデファクトスタンダードとして15年以上ゲーム業界を支えてきたBox2Dの作者であるErin Cattoが、ついに3D版を公開しました。それが「Box3D」です。

しかし、いざ採用を検討しようとすると、Jolt Physics・Bullet Physics・Rapier・PhysXなど既存の3D物理エンジンOSSが多数存在するなかで、「なぜ今Box3Dなのか」「他エンジンとどう違うのか」「alpha段階でプロダクション投入して大丈夫なのか」という判断が難しいのが実情です。日本語の情報はニュース記事とクイックスタートに二分されており、選定判断に必要な情報を一気通貫で得るのは容易ではありません。

Box3DはMITライセンスで公開されており、GitHubスター数は2026年8月時点で6,135。C17で書かれた比較的コンパクトなライブラリでありながら、Box2Dで培われた設計思想と、Valve社のRubikonエンジンから派生した3D物理シミュレーションのノウハウを併せ持つ、極めて特徴的な立ち位置のOSSです。

本記事では、Box3Dの機能・設計背景・類似OSSとの違い・alpha段階における採用判断の要点までを、公式README・公式ドキュメント・公式アナウンスをもとに整理して解説します。Box3Dを自プロジェクトに採用すべきかを判断する初見エンジニアの意思決定を支援することを目的とし、公式リソースへの導線もあわせて示します。

Box3Dとは｜Box2D作者による新作3D物理エンジンOSS

Box3Dは、Box2Dの作者として知られるErin Cattoが2026年6月30日に発表した、ゲーム向けの3D物理エンジンOSSライブラリです。ライセンスはMIT、実装言語はC17で、GitHubリポジトリ（erincatto/box3d）で開発が進められています。

2026年8月時点のリポジトリメタデータは次のとおりです。

archived=false かつ fork=false であり、pushed_at も2026年8月19日と直近です。リリースから2ヶ月足らずですが活発に開発が続いていることが読み取れます。一方で、公式アナウンス記事で作者自身が「I still consider Box3D to be alpha software.」と明言しているとおり、現時点のバージョンは v0.1.0 の alpha 段階 です（Announcing Box3D）。v1.0に向けた開発途上であることを、採用検討の前提として把握しておく必要があります。

Box2Dが2D物理エンジンOSSのデファクトになったのと同じ土壌でBox3Dが育つのかは、まだこれからの話です。それでも「Box2Dの作者が新たに設計した3D物理エンジン」というだけで注目に値するプロジェクトです。

開発の背景とRubikon-Lite / Box2Dとの関係

Box3Dは、いきなりゼロから設計されたわけではありません。公式アナウンス記事「Announcing Box3D」で、Erin Catto自身が開発動機と系譜を詳細に述べています。

まず開発動機は、Unreal Engineに組み込まれている物理挙動に対する不満です。倒れた木がテレポートするような不安定な挙動、gyroscopic torque（ジャイロトルク）が未対応であること、サーバー側で数十万エンティティのbroad-phaseを自分でコントロールしたい要件などが挙げられています。Erin CattoはUnreal Engineの物理まわりに長く関わってきた立場から、既存の選択肢では自分の欲しい挙動が実現できないと判断し、自ら手を動かすことにしたと説明しています。

系譜としては、Box3Dは Valve社のRubikonエンジン（『Half-Life: Alyx』で使用された物理エンジン）の趣味版フォークである「Rubikon-Lite」を出発点にしています。その後、大部分のAPI・データ構造・アルゴリズムをBox2Dのコードに置き換えていくことで、現在のBox3Dの姿に至っています。ただし、凸包生成と一部の衝突アルゴリズムには、いまもRubikon-Lite由来のコードが残っているとのことです。

つまりBox3Dの正体は、「Valve系エンジンのDNA」+「Box2Dの設計思想」の融合ということになります。Box2D経験者にとって親しみやすいAPI感を持ちつつ、実運用に耐える3D物理シミュレーションの土台としてRubikon-Liteの実装知見を継承している、というのがBox3Dの技術的な出自です。

Box3Dの主要機能

READMEに列挙されている機能を、コリジョン・物理・システム設計の3ドメインに分けて整理します。詳細はGitHubリポジトリ（erincatto/box3d）のREADMEを参照してください。

コリジョン

• 連続衝突検出（Continuous collision detection）
• コンタクトイベント
• 形状: 凸包、カプセル、球、三角形メッシュ、ハイトフィールド
• 1つのボディに複数形状を持たせられる（Multiple shapes per body）
• コリジョンフィルタリング
• Ray cast / Shape cast / Overlap クエリ
• センサーシステム
• キャラクタームーバー（Character mover）

3Dゲームで必要になる基本的なクエリ・イベント系は一通り揃っています。ハイトフィールド対応があるため、地形との衝突を素直に扱えるのは屋外系ゲームで扱いやすいポイントです。

物理

• 堅牢な Soft Step 剛体ソルバ（Robust Soft Step rigid body solver）
• 高速な並進・回転に対応する連続物理
• 島ベースのスリープ（Island based sleep）
• ジョイント: revolute（回転）、prismatic（直動）、distance（距離）、motor、weld（溶接）、wheel
• ジョイントリミット、モーター、ばね、摩擦
• ジョイントおよびコンタクトの力（forces）取得
• ボディの動きイベント、スリープ通知

なお公式ドキュメント「Box3D Documentation」ではジョイントとして revolute / prismatic / distance / spherical / weld / wheel / motor / parallel / filter が挙げられており、READMEより新しい種別（spherical / parallel / filter）が追記されています。ドキュメント側が最新である点に留意し、実装時は公式ドキュメントを一次ソースとして参照するのが安全です。

システム設計

• データ指向設計（Data-oriented design）
• ポータブルなC17
• 広範なマルチスレッド化とSIMD（SSE2 / Neon、BOX3D_DISABLE_SIMD で無効化可能）
• 大量のボディ（large piles of bodies）に対して最適化
• クロスプラットフォーム決定論
• 記録と再生（Recording and replay）

システム設計の観点では「データ指向設計」「クロスプラットフォーム決定論」「大量ボディ向け最適化」の3点が特徴です。決定論はロールバックネットコードや、確定的な物理挙動を必要とするリプレイシステムで重要になります。加えて公式アナウンス記事では、baked compound collision（衝突形状を最適化済みのデータ構造にクックする仕組み）、doubleによる大規模ワールド対応、graph coloringによる大アイランドの並列化なども特筆機能として紹介されています。

Samplesアプリはsokol（Windows: D3D11、macOS: Metal、Linux: OpenGL 4.5）+ imguiで実装されており、様々なプラットフォームで動作確認できる構成です。

対応プラットフォームと導入方法

Box3Dの対応環境と導入方法は、公式READMEおよび公式ドキュメントにまとまっています。

対応プラットフォーム

• OS: Windows / Linux / macOS
• コンパイラ要件: ライブラリ本体は C17、samplesは C++20
• ブラウザ: WebAssembly（Emscripten SDK経由）でビルド可能
• SIMD: SSE2 / Neon（BOX3D_DISABLE_SIMD で無効化可能）
• 依存関係: コアライブラリの依存はCランタイムのみ（Unixでは libm）

「コアライブラリの依存はCランタイムのみ」というのは、既存プロジェクトへの統合時にコンフリクトを起こしにくく、静的リンクでのシンプルな配布にも向いた設計です。

ビルド方法

Box3Dは複数のビルド経路を用意しています。

• CMake presets（推奨）
• Visual Studio: build_vs2026.bat
• Xcode
• bash: build.sh

CMakeベースで一般的な流れに沿っており、Windows / macOS / Linuxの各エコシステム固有のビルド経路も併走している構成です。

導入方法（CMake）

READMEには CMake での取り込み方法として3方式が示されています。以下は README からの抜粋です（出典: erincatto/box3d README）。

FetchContent_Declare(
    box3d
    GIT_REPOSITORY https://github.com/erincatto/box3d.git
    GIT_TAG v0.1.0
)
FetchContent_MakeAvailable(box3d)

add_subdirectory(extern/box3d)、および find_package(box3d 0.1 REQUIRED) の3方式が選べます。いずれもCMakeターゲット名は box3d::box3d を使います。

自前ビルドを既存プロジェクトに組み込みたい場合は add_subdirectory、システムワイドにインストール済みの Box3D を参照したい場合は find_package、単純に取ってきて使いたい場合は FetchContent という使い分けになります。

類似3D物理エンジンOSSとの違い

Box3Dを検討する際に、必然的に比較対象となる既存の3D物理エンジンOSSが複数あります。ここでは Jolt Physics・Bullet Physics・Rapier・PhysX の4エンジンとの違いを整理します。

比較サマリ

Stars等の数値は各リポジトリの公開情報より参照。

Jolt Physics との違い

Jolt Physicsは、『Horizon Forbidden West』『Death Stranding 2』などAAAタイトルでの採用実績を持つ、成熟したC++製の3D物理エンジンです。マルチコア最適化とVRを含む幅広い用途への対応が特徴で、スター数も1万を超えています。

これに対しBox3DはC17のCライブラリで、まだalpha段階です。「本番安定運用を最優先し、C++テンプレートベースの豊富な機能を活かしたい」ならJolt、「Cで書ける小さなバイナリを望み、Box2D的な設計感と決定論を重視する」ならBox3Dが検討候補になります。

Bullet Physics との違い

Bullet Physicsは、ゲーム・VR・ロボティクス・機械学習など広範な用途で使われてきた歴史ある物理エンジンです。実績は非常に豊富で、様々な教材・言語バインディングが存在します。一方、近年はコミット頻度が落ち着いており、現代のマルチコア・SIMD前提の設計とはやや性質が異なります。

Box3Dはゲーム特化のスコープに絞り、データ指向設計・現代的なSIMD/マルチスレッド前提で作られている点が対照的です。「用途が幅広く、ロボティクスやML方面まで見据えるならBullet」「ゲーム用途に絞り、モダンな設計の物理エンジンをC言語で扱いたいならBox3D」というのが大まかな棲み分けです。

Rapier との違い

Rapierは、Rustネイティブの2D/3D物理エンジンで、WASM/JSバインディングを公式に提供しています。JavaScript/TypeScriptから直接扱いやすいのが強みです。

Box3DはC17のCライブラリで、Emscripten経由でWebAssemblyターゲットのビルドが可能です。「Rust製エンジンをRustエコシステムで使いたい・JS/TSから素直に扱いたい」ならRapier、「Cプロジェクト、または C 経由でWASMを扱う既存パイプラインに組み込みたい」ならBox3Dが有力候補になります。

PhysX との違い

PhysXはNVIDIA製で、Unreal Engineの標準物理として長く使われてきた重装備の物理エンジンです。CUDA最適化や豊富な機能を備え、エンタープライズ寄りの位置づけといえます。

興味深いのは、Erin Catto自身が公式アナウンスで、Unreal Engineの物理挙動に対する不満（先述の倒木テレポート、gyroscopic torque未対応など）を Box3D の開発動機に挙げていることです。裏を返せばBox3Dは、「PhysXほど重装備でなくてよいので、ゲームに必要な物理挙動を素直に得たい」というニーズに向けた軽量代替という文脈でも捉えられます。

導入イメージと最初の一歩

ここからは、Box3Dを実際に触り始めるにあたっての手掛かりを、公式ドキュメントの記述に沿って紹介します。動作確認は各自の環境で行う必要があるため、本記事ではあくまで公式ドキュメントの案内という位置づけです。

基本フロー

Box3Dの基本フローは、公式ドキュメント（Box3D Documentation）によれば、World（世界）を作り、Body（剛体）を追加し、Shape（形状）を貼り付け、Stepでシミュレーションを進めるという流れになります。この構造はBox2Dを触ったことがあるエンジニアには馴染みやすいはずです。

API規約

公式ドキュメントには、Box3D の API 規約として以下の点が記されています。

• 型プレフィックス: b3
• API構成: 定義構造体（b3DefaultBodyDef() などのデフォルト初期化関数）+ 不透明ハンドル
• クエリ: overlap / cast クエリ、および空間ソートを提供
• ソルバ: "high performance sequential solver that operates in order N time"

デフォルト初期化関数を通して定義構造体を作り、不透明ハンドルでリソースを扱うスタイルで、C言語らしい素直なAPI設計です。

単位系とワールドサイズの推奨

公式ドキュメントでは、単位系と推奨ワールドサイズについても明示されています。

• 推奨単位: MKS単位系
• 動体（動く形状）は 0.1〜10m 程度
• 静的形状は 50m 程度まで
• ワールド全体は 12km 以内

数値挙動の安定性を確保するための推奨レンジであり、これを大きく外すとソルバの精度・安定性に影響する可能性があります。「大規模ワールドに向けたdouble対応」が公式アナウンスで言及されているものの、上記推奨レンジは常に念頭に置いておく必要があります。

最初の一歩は docs/hello.md

コードを書き始める際の最初の一歩として、公式には「Hello Box3D」ドキュメント（docs/hello.md）が用意されています。GitHubリポジトリの docs/ 配下にあり、Doxygenでドキュメント生成もできます（BOX3D_DOCS オプション）。

なお公式ドキュメントには、次のような注意書きがある点にも触れておきます。

Box3D should not be your first C project.

— Box3D Documentation

「初めてのCプロジェクトとしてBox3Dを選ぶべきではない」という趣旨で、C言語のビルド・リンク・メモリ管理・デバッグに一定の慣れがある人向け、というスタンスが公式に明示されています。

採用判断の要点｜alpha段階でどう向き合うか

ここまでの情報を踏まえて、Box3Dが向いているプロジェクト・向いていないプロジェクトを整理します。

向いているプロジェクト

• Cで書かれたゲームプロジェクト（またはC言語互換のFFIから物理エンジンを呼び出したいケース）
• WebAssemblyターゲットのゲーム（Emscripten経由でC17ライブラリをビルドしたい）
• 決定論が必要なゲーム（ロールバックネットコード、リプレイ、マルチプレイヤー同期など）
• 大規模ワールドを扱いたいゲーム（baked compound collision、double対応、graph coloringによる大アイランド並列化）
• Box2D経験者が3Dに移行したいケース（API感・設計思想の連続性）
• Erin Cattoの設計思想に共感し、v1.0までの追随コストを受け入れられるチーム

向いていないプロジェクト

• 成熟した安定APIを必要とするプロジェクト（alpha段階のため、v1.0までAPI変更が入る前提）
• 豊富な日本語コミュニティ・日本語資料を必須とするチーム（現時点では英語情報が中心）
• C++・Rustエコシステム前提のプロジェクト（Jolt・Rapierのほうが素直）
• 外部からのプルリクエスト貢献を必要とするプロジェクト（詳細は次項）

コミュニティと貢献方針

READMEおよびリポジトリのコントリビュートに関する記述によれば、Box3Dは以下のコミュニティ経路を提供しています。

• Discord: https://discord.gg/NKYgCBP
• GitHub Discussions: https://github.com/erincatto/box3d/discussions
• Issues: バグ報告・機能要望はIssueで受付

一方で プルリクエストは現在無効 です。公式アナウンス記事では、将来的にCLA（Contributor License Agreement）ベースでのPR受け入れに開放する構想が示されていますが、現時点ではコードの外部貢献は行えません。「PRベースでプロジェクトに関与しながら育てたい」というニーズには合わないため、コア開発の一切をErin Catto個人が担うプロジェクトであると理解した上で採用可否を判断する必要があります。

LLM利用ポリシーの開示

Erin CattoはREADMEに「LLM Usage」セクションを設け、Box3D開発における生成AI（LLM）の使い方を明示的に開示しています。同セクションによれば、LLMは unit tests / samples app / Box2D↔Box3D間のコード移植 / build configuration / code reviews / benchmarking で使用しており、コアの物理コードそのものは自身が責任を持って開発している旨が記されています。

LLM利用ポリシーがREADMEに明記されているOSSは今なお少数派であり、コアロジックへのAI利用範囲を明確に線引きしていることは、意思決定材料として評価しやすいポイントです。ライセンス（MIT）と併せて、社内での採用検討時のガバナンス観点でも参照しやすい情報といえます。

採用実績（公式アナウンスより）

公式アナウンス「Announcing Box3D」で紹介されている採用実績は次のとおりです。

• The Legend of California（Kintsugiyama、Erin Catto自身が関わるプロジェクト）
• s&box（Facepunch Studiosのゲームプラットフォーム）
• Esoterica（Bobby Anguelovのオープンソースゲームエンジン）
• Glenn Fiedler氏の1000人参加型スペースゲーム

作者自身のプロジェクト以外に、s&box や Esoterica、Glenn Fiedler氏のような業界で著名なエンジニアのプロジェクトで採用されている点は、alpha段階ながら実装品質への一定の信頼材料になります。

まとめ｜Box3Dを読み解く3つの視点

最後に、本記事全体で確認した内容を3つの視点にまとめます。

1. Box2Dの設計思想が3Dに持ち込まれた継承関係
   Erin Cattoが手掛けることで、Box2Dで培われた素直で読みやすいAPI設計・データ指向設計の思想が3Dに引き継がれています。Box2D経験者にとって親しみやすい設計であるという点は、学習コスト評価で無視できないメリットです。

2. Rubikon-Lite由来のValve系エンジンの遺伝子
   Box3Dは Valve社のRubikonエンジンの趣味版フォーク Rubikon-Lite から出発しており、凸包生成や一部の衝突アルゴリズムに Rubikon-Lite 由来のコードが残っています。ゲーム物理のプロダクション実装からの継承がベースにある点は、意思決定における安心材料になり得ます。

3. alpha段階のため、採用は要件と完成度の見合いで判断する必要
   archived=false / fork=false かつ活発に開発中である一方、公式にalphaと位置づけられており、v1.0までAPI変更が入る前提です。要件（C言語プロジェクト・WASM・決定論・大規模ワールド）とBox3Dの現在地が合致し、追随コストを受容できるチームであれば、有力な選択肢となります。

次のアクションとして、以下の公式リソースへの導線を示します。

• erincatto/box3d（GitHubリポジトリ） — 一次ソースとしてのREADME・ソースコード
• Box3D Documentation（公式ドキュメント） — API仕様・単位系・推奨ワールドサイズ
• Announcing Box3D（公式アナウンス） — 開発背景・採用実績・ロードマップ
• GitHub Discussions: https://github.com/erincatto/box3d/discussions
• Discord: https://discord.gg/NKYgCBP

関連情報

自社ゲーム・自社プロダクトへの3D物理エンジン導入や、C/C++ ベースの技術選定について外部の視点を交えて検討したい方は、お問い合わせフォーム からご相談ください。要件整理の段階からご相談いただけます。

ゲーム開発・C/C++ / WebAssembly を活かせるフリーランス・複業案件をお探しの方は、Workee で案件を探すことができます。Workee（フリーランス向け） で登録・案件検索が可能です。