【WebGL】WebGLの基本、知っておいた方が良い「CPU」と「GPU」の知識

WebGLとは？

ブラウザにある高度なCG表現をするため(GPUを使ってブラウザにレンダリングするため)のAPI。モダンなブラウザではほぼ十分に動きます。

なぜGPUを使うのか？

CPUで高解像度画像や3Dモデルを処理するのは処理負荷が高いため。

バージョン

1.0

ほぼどんなブラウザでもOK。世界で97%(2017年時点）

2.0

まだまだこれから。世界で31%(2017年時点）、なおデスクトップでは50%は超えている。モバイルがまだ。

歴史

年月	出来事
2011年3月	Firefoxが1.0をサポートして始まった。
2013年	IEが1.0をサポートした。2.0が議論され始めた。
2014年	Safariが1.0をサポートされた。
2017年1月	Firefoxに2.0がサポートされた。

実用例

ゲームが一番有名だがゲーム業界以外の利用も見られるようになりつつある。

Webゲーム

マインクラフト

不動産内覧

ソーシャルメディア

3Dモデルをアップロードできる。URLだけでシェアできるのでTwitterで他の人に自分の作品を共有できたりする。

CAD

このようなものも全てWeb上で実行できてしまう時代になりつつある。AutoCADから出力したデータをWeb上にアップロードすることによって閲覧できたりする。この用途の場合、第三者にCADのビューアーをインストールしてもらわなくても閲覧が可能なのが利点。

WebGLがそもそも必要かまず考える

意味のないWebGLはサイトの動きがもっさりするだけなので迷惑。

当然ネイティブに実装されているタグのが早い。
Webでできる必要があるか。
既存のHTML/CSSでまず同じことができないか。
そもそもその3D表現に意味があるか。

基礎

フレーム

ゲームなら60フレーム出るのが当たり前。VRなら120フレーム出るのが当たり前。モバイルの充電の持ちにもつながるので下げられるなら下げた方が良い。

モデル

以下のような多くの情報を持っています。

頂点座標、法線、テクスチャ座標（画像なので重い）など各点ごとに記録した頂点情報
どの頂点同士を繋いで面を作るかのインデックス情報
どのシェーダー、どのパラメーターで描画するかのマテリアル情報
ボーン(骨)の情報：人の形の場合はこの情報が入っていたりします。

場合によっては持ちうる情報

物理演算の剛体情報
編集時に必要なデータ
アニメーションデータ
CADなどはより細かい物性のデータ

モデルファイルの種類

適切なモデルファイルを採用しなければ無駄なデータが多くなってしまいます。モデルファイルは何を使っているかを意識することは重要です。基本的にはglTFが良いみたいです。(Dracoを使えばもっと軽くなります。）

FBX
COLLADA
glTF

WebGLの問題点

すぐに重くなる

重くなるのにも二つの要素がある。ゲームと同じですね。

「ページの読み込み」が重い

CADでは大丈夫だが、メディアとかでは致命的になる。

表示まで何秒かけられるか。
プログレスバーで誤魔化せないか。

「操作やフレームがカクつく」重い

1秒に何フレーム欲しいか。
余分な呼び出しをしていないか。（Spector.jsで調べれる）
HTML/CSSの併用も考える。

読み込み速度問題の対策

モデルを使わない

一番重いのはモデルのため。

コンテンツごとに異なりうる（キャッシュの効果が低そう）

Webエンジニアのノウハウが少ない

連携できそうな技術

PWA(Progressive Web Apps)

単純なゲームならWebでプレイさせて必要ならアプリとして入れられる。

WebGLでゲームをさせることができるなら無駄にアプリを作らなくても良くなりそう。その際はLocalStorageなどにモデルデータをキャッシュする形になるか。Webなら手軽にできるため間口が広がりユニークユーザーの獲得につながる可能性が上がる。

WebVR

HMDだけでなくルームスケールなものやコントローラも対応可能

VRコンテンツがURLひとつでシェアできる。

WebGPU/NXT

平たく言えば「ブラウザからより柔軟にGPUを使得るようにした仕組み」、従来のGLSL経由でGPUを操作するのではなく、JavaScriptから呼んでGPUを処理できるようにできる。

次期WebGLとされる仕様。WebGLより低レイヤかつ高速
WebGLより難解。
Safariではすでに使える。
機械学習目的での利用を想定。学習したモデルを計算するのはクライアント側でもできる。

dracoとは？

Googleが公開している頂点情報の圧縮用フォーマットです。これを使うとさらにWebGLで使われているモデルデータを圧縮することが可能です。

特徴

4-12枚程度に圧縮できる。

最大で12枚程度に圧縮が可能です。アニメーションなどは圧縮できずあくまでモデルの頂点データなどを圧縮できます。

動画で言えば、MP4(glTF)とH.264(draco)のような関係です。

glTFにdracoの拡張仕様があります。

デコーダー(JavaScriptファイル)が公開されているが1MB近くあります。

なお、WASM版はもっと小さいです。なお、JavaScriptなのでCDNなどを使えばある程度キャッシュは効いたりします。

具体的にどれくらい圧縮されるのか

1.8MB程度のモデルデータがdracoを使うことによって230KB程度には圧縮されたりします。(8倍程度の圧縮）

頂点の数の多さによって圧縮率は異なります。（頂点の数が多いほど圧縮率は高まります。）

GLSLとは？

GPUを直接こねくり回せる低水準言語

問題点

正直、GLSLを使うのは辛い。職人芸だし、デバッグも辛い。数学に強くないと戦えない世界（いわゆる変態）

WebGPUが今後次世代技術としてくる予定なので、くれば脱GLSLはできる予定だが、まだきていない。

なので、現状GLSLを直接触るよりはラッパーライブラリ(Three.jsやBabylon.jsなど)を使うのが丸い。

シェーダー

GPUは基本的に単純作業しかできない。単純作業の受け口的な役割

VertexSharder

座標の計算、JavaScriptから指示を出すと3Dオブジェクトが回転したりする。

PixcelSharder

カメラの位置からのライトの入射角や質感などの2次元平面へのピクセルの計算

ラッパーライブラリ

Three.js

2010年以降
OSS
採用実績が多い。
ノウハウも多い。

Babylon.js

2013年以降
MicrosoftのOSS
開発も最近は盛ん
公式のチュートリアルなどの学習リソースがしっかりしている。

CPU

イメージ的には有能なおじさんが一人いる感じ。
大抵の処理はこちらで処理される。
割り込みなども許可していて優先度を決めて処理できる。
基本はシングルスレッド
JavaScript(TypeScript)で記述する。
一人でやるので大量のオブジェクトの処理が辛い。

GPU

単純できるおじさんが数千人いるイメージ
なのでできる仕事は限定的
頼んだ仕事が終わるまでは何もできない。
GLSLという言語で記述する。(JavaScriptからこの処理を呼ぶ）

クロック数

一人が処理できる速度のこと。(1秒間に処理できる回数のこと）、CPUの方がやはりかなり速い。

CPU

4GHz回処理できる。

GPU

1.6GHz回処理できる。

コア数

同時に処理できる人数。

CPU

8コア〜64コア（ただJavaScriptはシングルスレッドでしか動かないので、基本はシングルスレッドなので1コアしか使えない。）

GPU

4352コア

スループット

CPUは4GHz×1コアだが、GPUは1.6GHz×4352コアなのでできるだけGPU側に処理を寄せた方が効率的です。

モバイル

SoC(システムオブチップ）にGPUが実装されているのでCPU負荷を下げるためにGPUを最適化するのが良い。

将来的にも

WebGPU、推論コア、レイトレーシングコアなどのGPU技術も出てくるのでできるだけCPU外に処理を寄せていきたい。

プログラミング

イベント処理

JavaScriptで行う。(Webからマウスやキーボード操作を受け取るなど）

各フレームで実行する処理

JSがGLSLのシェーダーを呼び出して計算させる。
次のフレームを呼び出す。