はじめに
「ブラウザで動く3DのMMOって、裏側でどういう仕組みになっているんだろう?」
そんな疑問を持ったことがある人向けに、この記事はシリーズ形式で解説していきます。全4回の予定です。
- 本記事:ブラウザで3Dを描く仕組みの全体像(リアルタイムレンダリング vs 映像ストリーミング)
- 3Dアセットの圧縮・配信・ブラウザでのキャッシュ場所
- Unity/Unreal EngineがブラウザでThree.jsのようなJSライブラリを使っているのか?という疑問への回答
- GPUの種類・ドライバによる「相性」問題
前提知識がなくても読めるように、専門用語が出てきたらその都度説明を挟んでいきます。
ブラウザで3Dを描く2つの方式
まず大前提として、ブラウザ上で3Dシーンが動いているとき、その絵はどこで作られているのか、という話から始めます。方式は大きく2つに分かれます。
方式A: クライアント側リアルタイムレンダリング(主流)
これはあなたの手元の端末(PCやスマホ)のGPUが、実際にその場で3Dのポリゴンを描いている方式です。サーバーは3Dのモデルデータやゲームの状態(誰がどこにいるか等)を送るだけで、「絵を描く」作業自体は全部ブラウザ側で行われます。
ほとんどのブラウザ3Dゲームはこちらです。ブラウザにはWebGL、そして近年はWebGPUという「JavaScriptからGPUを操作するための標準API」が備わっており、これを使って3Dシーンをリアルタイムに描画します。
代表的なJavaScriptライブラリ:
- Three.js:最も広く使われているWebGL用ラッパーライブラリ
- Babylon.js:Microsoft主導の3Dエンジン
- PlayCanvas:ブラウザゲーム特化のエンジン
これらはすべて「JavaScriptのコードでGPUに命令を送り、その場で絵を組み立てる」仕組みです。動画ではなく、本当にその場でポリゴンが計算されて描かれています。
方式B: サーバー側レンダリング + 映像ストリーミング(特殊なケース)
もう一つは、実際の3D描画はサーバー側の強力なGPUで行い、その結果を「動画」としてブラウザに配信する方式です。ブラウザ側は動画プレイヤーのようなもので、キー入力やマウス操作をサーバーに送り返すだけです。
イメージとしてはこうなります。
この方式の代表例が、NVIDIAのクラウドゲーミングサービスや、Unreal Engineの「Pixel Streaming」という機能です。
メリット:低スペックの端末でも、サーバー側のハイエンドGPUの性能をそのまま体験できる。
デメリット:サーバー側のGPUコストがプレイヤー1人あたりにかかるため、同時に何千人も遊ぶMMOのような形態には経済的に不向きです。
そのため、MMOのような大人数同時接続が前提のブラウザゲームでは、方式A(クライアント側リアルタイムレンダリング)がほぼ標準になっています。
方式Aの内訳:誰が3Dエンジンを書いているのか
方式Aの中でも、実装のアプローチが大きく2つに分かれます。これは後続の記事(第3回)で詳しく扱いますが、ここで概要だけ触れておきます。
- JavaScriptで直接3Dエンジンを書く/使う(Three.js、Babylon.jsなど)
- UnityやUnreal Engineのような既存のゲームエンジンを、丸ごとブラウザで動く形式に変換する
どちらも最終的にはWebGL(またはWebGPU)を呼び出しますが、そこに至るまでの経路が全く違います。①は「はじめからブラウザ向けに書かれたコード」がWebGLを叩き、②は「本来PC/コンソール向けに書かれたC++やC#のコード」を特殊な変換技術でブラウザ実行可能な形にしてからWebGLを叩きます。
この違いは、ダウンロードサイズや起動速度、開発のしやすさに大きく影響してきます。詳しくは第3回で扱います。
この記事のポイントまとめ
- ブラウザの3Dゲームは、基本的にあなたの端末のGPUがその場でリアルタイムに描画している(動画配信ではない)
- 例外として、サーバー側でレンダリングして映像だけをストリーミングする方式もあるが、GPUコストの問題から大人数同時接続のMMOには不向き
- リアルタイムレンダリングの実装方法にも、「はじめからWeb向けに書く」か「既存エンジンを変換して持ち込む」かの2つのアプローチがある
次回は、「では3Dモデルやテクスチャといったアセットのデータは、具体的にどうやってブラウザに届き、どこに保存されているのか」を掘り下げます。