WebGLで夢のようなコンテンツを作る

みなさんがWebGLを始めたいと思った理由はなんでしょう？　もしかしたら、「市販のゲームに出て来るような、すごい映像コンテンツを作りたい」という人も多いかもしれません。

ですが、WebGLには、基本的には三角形（ポリゴン）を表示する機能しかありません。テクスチャという画像を三角形に貼り付ける、といった機能もありますが、少なくとも造形的な意味では、WebGLでは三角形を大量に組み合わせて、なんらかの形を表現するほかないのです。これは、WebGLに限らず、そのほかの多くの３D技術でも同じことが言えます。
ですが、実際問題、そんな風に三角形を、自分で位置などプログラムで一つ一つ指定していくわけには、とてもいきませんね。

市販のゲームや映画などでは、あれほどまでにリアルな造形を、どのように実現しているのでしょうか？

いくつかの方法があります。

A. あらかじめ、三角形の組み合わせてで構成された基本形状（立方体、球、円錐、円柱など）をプログラム的に登録しておき、それを必要に応じて呼び出す。
B. ３Dソフトで複雑な形状のモデルを作成し、それをファイルに書き出し、WebGLプログラムで読み込んで表示する。

A. が簡単ではありますが、しかしやはり基本的な形のものしかないので、作れるモデルの複雑さにも限界があります。（というか、人体など複雑なものはまず無理ですね）。
キャラクターや動物などの、複雑な形状のモデルをWebGLで表示したいなら、まず間違いなくBの方法をとることになります（もっとも、３Dソフトで複雑なモデルを作り出す際、その取っ掛かりとしてAの基本形状から作業をスタートさせることも多いようです）。Bの方法でも、ファイル中に記録されているキャラクターや動物の形状は、大量の三角形の集まりとして記録されているのです。

3Dソフトには、たくさんの種類があります。Autodesk社「Maya」などのプロ御用達の何十万もするソフトから、「Blender」などオープンソースの無料で使えるものなど（Blenderは、無料という印象を良い意味で裏切る、素晴らしく高機能な３Dソフトです）、多岐に渡りますが、ここでは３Dソフトで作られたモデルデータが、すでに手元にあるものと仮定して話を進めます。

３Dデータを記録するファイル形式にはたくさんの種類があります。何れにしても、どれか一つ、あなたが使う３Dソフトが出力をサポートしていて、そしてWebGLで表示する際のファイル入力の処理を開発しやすいフォーマットを選ぶと良いです。このページでは、推奨するファイルフォーマットをいくつかご紹介します。

あなたがWebGLを使って作れる世界は、このページのノウハウによって、あなたが本来つくりたい「夢のような３Dコンテンツ」に少しでも近づけるはずです。

WebGLだと、どの程度の表現が可能なのか？

気になるところですね。
結論から言うと、3D APIとしての機能レベルという意味では、「WebGL 2 = PlayStation 3」程度と考えてください（WebGL 1でも、拡張機能を活用することで、それに近いレベルまではいけるかもしれません）。

ちなみに、PlayStation 3の初期〜中期の有名タイトルである「KILLZONE 2」というゲームのリアルタイム映像は、（静止画ですが）こんな感じです（動画もGoogle検索で幾らでも出てきますが、ゲーム内容が過激なので、ここでは載せません）。

ここまでのレベルは、さすがにプログラム技術だけでなく、開発に関わったアーティストたちの芸術センスの賜物でもあるので、直接の比較は難しいものですが、少なくともWebGLにも、少なくともAPIとしての機能性としては、ここまでできうるポテンシャルはあるということです。

※PlayStation3は、WebGLよりも高効率な低レベルAPIや、高性能なCELLプロセッサを有しています。かたやWebGLはJavaScript処理でCPU側が遅くなりがちなど、不利な面があるので、PS3商業タイトル並みの表現はさすがに無理だろう、と感じられる技術通の方もいらっしゃると思います。ですが、WebAssemblyや現在のパソコンGPUの性能はPS3のそれより遥かに世代が新しいことを考えると、いずれは追いつき、追い越すだろうと思います。）

※ちなみに、このKILLZONEシリーズを開発しているゲリラ・ゲームス(Guerrilla Games)社の自社ゲームエンジンである「DECIMAエンジン」は、あの「Metal Gear Solid」シリーズでおなじみ、小島監督が立ち上げた「Kojima Production」が惚れ込み、採用したエンジンでもあります。

 

「WebGLは、こんなことまでできるポテンシャルがあるのか、すごい！」

でも、この域に到達するのは、一朝一夕でできることではありません。ゲーム会社と違い、プロのアーティストにリッチなアート素材の制作を一般市民がそうそうお願いできるわけもないのは仕方がありません。しかし、すごいリッチコンテンツを実現する要素は、アート素材だけではなく、プログラムによる表現力も大きく関わっているのです。

 

例えば、以下の２つのデモを見てください。

http://particle-love.com/

https://paperplanes.world/

どちらも、プロのアーティストによるリッチなキャラクターモデルなどは出てきません。（まぁ、どちらも、特に地球のデモはある意味「美的センス」は必要そうですが・・・）

とはいえ、綺麗に見えたり、リッチな表現に見えるのは、それだけのWebGLを駆使する「プログラムの巧みさ」があるからです。

なお、プロのアーティストによるアート素材が加わると、この域になります。

https://www.clicktorelease.com/code/cruciform/

https://sketchfab.com/models/c9ddda63c5a641b2bb860224a541d4c0

https://sketchfab.com/models/89c45d1d5dfa4876ba353c86007084b8

https://sketchfab.com/models/8b4dfd25277b401f8b132677bc3efc0c

はい。ブラウザで動いています。すごいですね。これがWebGLです。

 

さて、こうした段階までたどり着くには、いくつか達成しなければならない要素があります。それを紐解いて見ましょう。

（以下は、あくまで本サイトの製作者であるemadurandalの個人的な見解です。業界的にこのような切り分けで物事が考えられているわけではありません）

静止画としての追求

1. （３Dソフトで作った）複雑なポリゴンデータの読み込みと表示（または、それに匹敵するほどの印象的なポリゴンデータの動的生成）

これは、あくまで造形面（モデルの形状面）での話です。WebGLは三角形（ポリゴン）の表示をベースに、全てを構築していきます。三角形の中の領域に、画像を貼ったり、素敵な色を生成したり、一部を透明にしたり、といった味付けはできますが、それ以前にまず、望みのモデル形状をWebGLに指示できなければ、当然ながらちゃんとしたコンテンツは作れませんね。そのためには、次のことが必要です。

・３Dソフトで作ったモデルデータのファイルを、ブラウザのJavaScriptからファイルアクセスして、データを解析し、ポリゴンデータを読み込んでメモリ上に保持する。

・メモリ上に保持したポリゴンデータを、WebGLが直接扱えるデータ形式に変換して、WebGL（GPU）に渡す。（その指示までに至る、WebGLの様々な命令の呼び出しを習得する）

・ WebGL（GPU）に対して、描画命令を送る（その指示までに至る、WebGLの様々な命令の呼び出しを習得する）

この過程で、シェーダープログラムというものも作成し、WebGLに渡さなければならないのですが、一旦ここでは脇に置いておきます。

これが、まず基本中の基本です。

2. テクスチャの表示

テクスチャとは、ポリゴンに貼る画像のことです。これもWebGLに適切な命令を出して、画像を指定する必要がありますが、前項に比べてば、そんなに難しくありません。
（むしろ、見栄えのする画像をどう作るかが重要です。これは、知り合いにアーティストがいなければ、素材集に頼ってしまいましょう…）

テクスチャ画像の模様（例えば、木材の模様や人間の地肌模様など）は、CG理論的には「アルベド」といって「光にさらされた時に、どういう色（正確には光の波長）は吸収し、どの色は跳ね返すか）という情報を含んでいます。ただ、純粋なアルベド（物体表面の色）だけでなく、細かい表面の凹凸（例えば、服にはシワがありますよね）などによる自己遮蔽からくる陰影などの色の変化まで描き込まれるケースもあります。

昔は、そうした陰影情報までテクスチャに描き込んでいたものですが、最近のCGでは、陰影はきちんとリアルタイムに光の計算をして導き出すもので、テクスチャにはアルベド（表面本来の色）情報しか含めないケースも多くなっています。

3. ライティング（シェーディング）計算

前項、前々項のポリゴンとテクスチャだけでも、それなりに表現が可能です。日本のゲームなどは、特に陰影にさほどこだわらない（マンガの国ですからね）こともあり、かっこいいポリゴン形状と、腕のいいアーティストが描いたテクスチャ模様があれば、それだけで結構な絵が作れるかもしれません。

ただし、やはりそれでも、「こちらの方向から光が差し込んできたら、このキャラクターのこの部分は明るくなる。この部分は他の部位よりも相対的に暗くなる（いわゆる「陰」）」というのを、リアルタイムに計算できると、より雰囲気が出てきます。特に、光源の方向を変えたりすると、同時にキャラクターの全身の明るさのグラデーションが様変わりするなんてことは、イラストなどの２D表現手段では、まず考えられなかったことです。

さて、このライティング計算をできるようになるには、それなりの勉強が必要になってきます。光の計算です。光の計算には、数学が必要になってきます。

実は、WebGLのベースとなった、OpenGLの初期バージョンでは、この光の計算を（種類は限られていたものの）、パラメーターさえ伝えれば、自動的に計算してくれる時代がありました（業界用語で「固定シェーダー」と呼ばれます）。

残念ながら、現在のOpenGLやWebGL（それどころか、Direct3Dを始めとした、最近の3D API、そしてGPUそのものについても）には、この固定シェーダー機能がありません。機能仕様から取り除かれてしまったのです。

その代わり、「プログラマブルシェーダー」という機能が搭載されました。

一言で言うと、「プログラマーの皆さん。これからはシェーダーというプログラムを書いて、GPUに送ってください。私たちGPUはそれを高速に実行します。固定シェーダー時代と違って、より柔軟な処理（主に光の計算などだが、それだけに留まらない）が可能となり、よりリッチな表現ができます。素晴らしいでしょう？」

というものです。なので、できる表現の幅は広がりましたが、 自分でやらないといけないことが増えた、ということでもあります。

ちなみに、CGの世界においては、日本語としては同じ発音である「陰（シェード）」と「影（シャドウ）」を明確に区別します。以下のサイトの記事に、わかりやすい図解説明が載っています。

http://news.mynavi.jp/column/graphics/020/

一般的に、「シェーディング」というと 「陰（シェード）」の計算はしますが、「影（シャドウ）」の計算は範疇外です。また、「陰」の計算といっても、日本の２Dイラストなどの考え方と大きく異なり、真っ黒のキャンバスに、光を与えていった結果、その与え方に偏りが出て、相対的に他より暗い部分が発生してそれが「陰」となる、という仕組みです。最初全体が明るくて、後から暗い陰を描き込んでいくのではありません。

※余談ですが、実は同じ２Dの絵でも、西洋の絵画は、CGと同じで、暗いキャンバスに光を足していくアプローチらしいです。ここは西洋と東洋の発想の違いなのでしょうか。

また、「影（シャドウ）」の方は、通常の「シェーディング」処理では、作り出すことができません。「影には影のための、専用の処理」というものがあり、その処理を行わないと影を描画することができないのです。

（また、さらにややこしいのですが、この事情はGPUによるいわゆる「リアルタイムCG」（もちろんWebGLはこの範疇）での話です。より時間をかけて計算する「レイトレーシング」と呼ばれる、全く別の光の計算方法では、このような別扱いをしなくても、統一的に影も伴って絵を作り出すことが可能です。「レイトレーシング」については、このサイトでは特に取り上げる予定は今のところありません。）

一方、「ライティング」や「ライティング計算」という言葉の方は、文脈にもよりますが、「影（シャドウ）」の計算も意味として含んでいる場合があります。

ちょっと難しい分野ではありますが、今後はこのライティング計算の部分も、本サイトで情報サポートしていけたら、と考えています。

4. シャドウイング（影）＆物理ベースレンダリング（PBR）＆グローバルイルミネーション（GI）

前項のライティング計算（というか、前項では「シェーディング」（つまり影（シャドウ）抜き）の意味で話していました）。実は、光の計算といっても、その内容の高度さによって、いくつか段階や種類があります。

１つ目は、俗に「古典シェーディング」と呼ばれる、計算は単純だが、現実世界と比べてそこまでリアルな結果にはなってくれない手法です（それでも、パラメーターを巧みに調整すれば、まぁまぁいい感じにはなります）。

２つ目は、「シャドウイング（影計算）」です。前項でも言及した通り、これは「シェーディング」とはまた別に、専用に処理する必要があります。「古典シェーディング」では、描画命令を受けて描画される各３Dモデル、それぞれ単体で（独立して）光（直接光）の計算をすればよかったのです。しかし、シャドウイングは、描画対象となる各３Dモデルたちが、それぞれ「影を落とす側」と「影を落とされる側」に、立場として明確に分かれます。その判断をするに当たり、互いの位置関係などから判定処理をしなくてはいけません。

ところが、GPUによる計算は、基本的には、３Dモデル同士の相互関係を直接は処理できません（無理すればできるのですが、まぁ、いっぺんには難しい、と考えてください）。そのため、影の計算には、特別な方法で、段階的な処理が必要となるのです。

リアルタイムCGにおける「影計算」は、それだけで大量に書籍や論文ができてしまうほどの、深いテーマです。しかし、オーソドックスな方法というものは割と確立されています。今後、そこらへんも機会があれば解説していきましょう。

３つ目は、「物理ベースレンダリング」と呼ばれるものです。これは、現実世界の光学などの物理法則をできるだけ満たすように考慮された手法です。ここまで行けると、局所的には「え、すごい！これ、写真じゃないの？」感を出せるようになります。

４つ目は、「グローバルイルミネーション」というものです。これまでの説明で、なんとなく感じている方もいらっしゃると思いますが、WebGL（他の3D APIもそう）をはじめとするリアルタイムCGでは、基本的には直接光しか計算できません。現実世界の光は、色々な物体にぶつかっては反射して、反射した光がまた他の何かにぶつかり、また反射を繰り返して、私たちのカメラや目に入ってきます）。「これらの光（間接光の影響）を、直接光の計算とは別扱いにはなるが、きちんと考慮しよう」というのがグローバルイルミネーション（GI）になります。

前項の「ライティング（シェーディング）計算」は、実質的に本項の上記１つ目「古典シェーディング」のことを意図して説明していました。
これに加え、シャドウイング（影）を加えることで、より物体の存在感を引き立てることができます。

最新のゲームCGなどでは、さらに「物理ベースレンダリング」や「グローバルイルミネーション」の導入が進んでいます。しかし、「古典シェーディング」や、シャドウイングの基礎までならともかくとして、 この「物理ベースレンダリング」や「グローバルイルミネーション」は、その理論や実装が、かなりの難関と言えます。このレベルができれば、「その人はもう業界人としてどっぷり腰まではまっている」と言ってしまっても良いくらいです。ここまでくると、もはや「WebGLという3D APIの取り扱い」というレイヤーをはるかに超えた、より上層のソリューションを扱っています。とは言え、そうしたことを扱える下地としてのWebGLでもあるのです。

ポストプロセスや、パーティクル、ボリュームなどの特殊表現

ポストプロセスとは、後処理のことです。つまり、全ての３Dモデルの描画（ライティング処理含む）を終えてできた、２Dイメージに対して、後処理を加えることです。２D処理と言いつつも、リアルタイムCGにおいては、深度値（物体の奥行き値）などの情報が自然とGPUに残ったりするので、かなり柔軟な加工が可能です。

具体的には、モーションブラー（高速に動く物体を「表示ブレ」させる効果）、グレア（眩しいくらいに明るい部分に、光が溢れ出す効果を入れる）、被写界深度（カメラで、ピントが合っていない箇所にボケができるあの表現）などがあります。いずれも、より現実感を出すために、必要となる要素です。

パーティクルは、火花や煙などを表現する一手法です。ボリュームは、半透明のモヤモヤしたもの（煙や水蒸気、もや、霧など）を刺しています、これらは光を散乱させる効果があるのですが、それを計算して表示することを、ボリュームレンダリングと呼びます。

このように、CGにおいては（特にリアルタイムCGにおいては）、表現のために、様々な処理アプローチを併用して、リッチかつリアルな表現を作っていきます。奥が深いですね。

動き・インタラクションとしての追求

まだあります。これまでは、あくまで静止画の世界での話です。実際は、CG映像は動きます。動きも考えなければならないわけです。主な要素をあげていきます。

1. ３Dモデルの表示位置の取り扱い

３Dモデルの表示位置を決定するものはなんでしょうか？いくつか要素があります。

・三角形ポリゴンの頂点データの位置座標

・３Dモデルが階層管理（シーングラフと呼ばれます）されていた場合、各階層に設定されている（頂点データの位置座標に対する）変換行列

・シェーダー内での位置座標の動的な変更

主に、この３つでしょう。２つ目については、「平行移動」「回転」「拡大縮小」の３種類の位置変更操作を表現する、４行４列の行列（変換行列）を用います。「三角形ポリゴンの頂点データの位置座標」 は４要素のベクトルで表現され、このベクトルに変換行列 を掛け算することで、頂点位置座標が、そのシーングラフ上の別の階層構造に移動（写像）される（別の階層構造から見た時の、座標値になる）ことになります。ここまでの説明でよくわからなかったとしても、なんとなく「そういうものなのか」と軽く心に留めておいてください。

2. 階層アニメーション

前項の「シーングラフ上の各階層に設定されている変換行列」をそれぞれ変更することで、階層アニメーションを行うことが可能です。

例えば、親階層には物体Aが、子階層には物体BとCが合ったとします。親階層が右に1メートル移動しました。子階層のBは下に１メートル移動しました。子階層のCは特に動きませんでした。この場合、世界全体の視点で見ると、自身としては動いていなかったはずの物体Cも、右に１メートル動いているのです。なぜなら、右に１メートル移動した親階層に自分が属しているからです。物体Bも同じ理由で右に１メートル動いており、その上でさらに、自分自身が下に１メートル動いています。つまり、物体Bは世界全体からすると、斜めに動いていることになりますね。

この仕組みを使えば、かなり凝った動きができることがわかるでしょう。大型の乗り物や、恒星・惑星・衛星の動きなど、様々なことに応用が可能です。

3. スケルタルアニメーション

階層アニメーションを持ってしても、表現できないアニメーション表現があります。それは、人間や動物の柔軟な動きです。一応、人間も骨で動いていますから、単純化すれば階層アニメーションで処理できなくもありません。それをやっていたのが、初代プレイステーション時代の３DCGです。曲がった腕とか、つなぎ目がぶっちり切れていましたね。現実なら、曲げた部分の皮膚が伸びたり縮んだりするはずです。

それを処理するのが、スケルタルアニメーション、別名「スキニング」です。

これは、キャラクターの体にスケルトン（骨階層）を設定し、キャラクターの各ポリゴン頂点に「何番と何番の骨が動いたら、自分はそれぞれこの割合で位置の影響を受ける」というウェイト値という値を設定しておきます（CGアーティストの方、特にモデラーの方はピンとくるかもしれません。３Dソフトで「ウェイト調整」をやると思います。影響度合いをひたすら塗り塗りして調整しますよね。あれです）。

キャラクターモデルの各頂点は、アニメーション時に、自身に設定されたそのウェイト値を考慮して、それら複数の骨の変換行列からの影響の受け方の割合をコントロールしてもらうわけです（大抵、最近だとこの処理はGPUの頂点シェーダーで行われるケースが多いです）。

こうして、腕を曲げても、いい感じに皮膚が伸び縮みする、現実と同じような自然なキャラクターアニメーションが可能となります。これがスケルタルアニメーションです。

WebGLでも、もちろんこのスケルタルアニメーションを実現できます。ただし、スケルタルアニメーションに必要な情報を３Dソフトで作り込み、それを適切なファイルフォーマットで書き出し、ブラウザ側でその情報を正しく解釈し、頂点シェーダーで（別にJavaScriptでやってもいいですが）、適切に計算させなければなりません。慣れないうちは、試行錯誤が続くでしょう。全てのピースがきっちりハマって動作しないと、おかしなぐんにゃりした形に大変形したりして、正常動作にこぎつけるまでに、非常にストレスフルな経験をすることになります。でも、ご心配なく、このサイトでは、いずれglTFファイルフォーマットを利用した、WebGLによるスキニングアニメーションの実装について、解説記事を書く予定です。

4. 物理シミュレーション

高校で物理の授業を受けたことはありますか？　力学という学習分野があったと思います。あんな気が遠くなるような話が、実はCG表現で活用されています（人生、無駄な勉強などないものですね）。

いわゆる力学と言っても、剛体（変形しない硬い物体）の力学と、弾性体（変形する柔らかい物体）の力学だと、計算で考慮すべき事柄のボリュームが結構違います（後者の方が難しく、計算量が増えます）。最近だと流体力学なども入ってきつつあります。そして、最近はより自然なアニメーションにするために、前項のスケルタルアニメーションと物理シミュレーションを組み合わせたりもします。

色々と頭が痛くなってきますね。WebGLという3D APIから、だいぶ遠いところまで来てしまいました。しかし、こうした物理計算の一部は、GPUで計算させることが可能です。そのためには、WebGLの仕様をよく熟知している必要があります。そう、もはや今の最新CGは、あらゆる数学や物理学、コンピューターサイエンスを結集させた、総合芸術と言えるのです。

5. AI（人工知能）

最近、機械学習などの話題が花盛りです。もちろんそういう要素も最近のゲームでは入って来つつありますが、機械学習・深層学習のブームが到来するずっと前から、ゲームの世界では狭義（というかゲーム業界独特の意味での）のAI開発が盛んでした。まず、ゲームの場合、敵キャラが大抵いますね。彼らは、いい感じに主人公たちを追って来たり、武器を投げてこなくてはいけません。主人公を追って来るためには、つまり３D空間上の主人公の位置へ到達するには、どういう経路で、障害物をどう避けて、移動していけばいいのか、そうしたことを敵キャラが考えなければなりません。また、場の条件が変わったら、戦いを放棄して、逃げたりすると、ゲームとしての演出効果があるでしょう。ステート（状態）をもたせ、複数の状態の間を、遷移させたりもします。こうした狭義のゲームAI、群衆AI、そして最近、隆盛している機械学習など、新たな試みが今後もゲームを始めとしたインタラクティブなCGでは、なされていくはずです。

シェーダーで遊ぶ

GPU（グラフィックプロセッサ・いわゆるグラボ）において、それまでハードウェア（回路）実装だった頂点処理とピクセル処理は、ある時期を境に（GPU上の）ソフトウェア処理になり、プログラマブルシェーダーとして3D開発者たちに解放されました。 それ以降、WebGLやOpenGLといった3D APIから少し離れて、それらプログラマブルシェーダーの処理のみに注目した技術ノウハウも確立され、成長してきました。 ここでは、そんなプログラマブルシェーダーに特化した情報を扱います。