WebGL – HTML5Experts.jp

WebGLの現状と未来を、Grimoire.jsを生んだスーパークリエータに聞いてきた！

白石俊平 — Thu, 02 Nov 2017 01:00:22 +0000

連載： HTML5 Conference 2017特集 (12)

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、東京理科大学4年の石井翔さんです。

石井さんのセッション「WebGLの今とこれから ~今のWeb開発で使うからこそ知っておきたい周辺技術~」に関するスライド資料は、こちらで公開されています。

スライド資料（注: 重いのとモバイルから見えないのはご容赦ください by 石井翔さん）

WebGLの現状

白石: 本日は取材をお受けいただいてありがとうございます！簡単に自己紹介をお願いします。

石井: 東京理科大学4年生の石井翔です。昨年、私が進めているGrimoire.js（注: モバイルからだと多少レイアウトが崩れます by 石井翔さん）というプロジェクトが未踏IT人材発掘・育成事業に採択され、スーパークリエータに認定されました。

白石: Grimoire.jsはWebGLのライブラリですね。Grimoire.jsについてもあとでお聞かせ願いたいのですが、まずはWebGLの概要や現状についてお話いただけますか？

石井: WebGLは、一言で言えばWeb上で3Dコンテンツを扱うための技術です。2010年に仕様が策定されており、既に多くのブラウザで実装されている技術です。ブラウザ上でどの技術が使えるかを測定するCan I Useでの結果を見ても、92%以上のブラウザがサポートしていて、広く使える状態にあると言っていいでしょう。

ただこれは、WebGL 1.0の話です。WebGL 2.0はまだまだですね。ChromeとFirefoxだけが対応しているという状態で、特にiOSで使えないのが厳しいです。「ブラウザを限定すれば使える」という状態です。

白石: WebGL 1.0と2.0って何が違うんですか？…ぼく、3Dプログラミングが全然わかってないので、理解できるか自信がないのですが(笑)

石井: 浮動小数点テクスチャなどがWebGL 2.0の主な機能ですが、3Dプログラミングの知識がない人に向けて話すのはちょっと難しいですね(笑) とりあえず、ライブラリ作者なら知っておくべきですが、ライブラリのユーザーはそれほど気にする必要はないかと思います。ライブラリ作者も、WebGL 2.0が使えない環境では1.0にフォールバックするように実装していることが多いでしょうし。

（筆者注: WebGL 2.0の強化点についてはQiitaで良い記事を見つけました。ぼくにはちんぷんかんぷんですが…）

白石: なるほど、あまり気にしなくていいと(笑) 安心しました。

石井: 3Dをご存じない方にとって大事なのは、そもそもWebGLとはGPUを扱うための技術だということをしっかり理解しておくことです。

CPUは、CPUは複雑な処理を逐次的に処理することを得意としています。CPUの場合はコアの数が4とか8とかに限られていることが普通です。

一方GPUの場合は、「異なるデータに対して同じ処理を施す」のを並列で実行するのに特化しています。なのでGPUは、コアの数が1,000を超えることも普通です。こうした特徴を持つGPUだからこそ、大量の頂点を移動する処理など、3Dプログラミングに必要とされる「単純な処理の並列実行」に向いているんです。

白石: こうした特徴は、最近だと機械学習の分野とかにも活かされているんですよね。単純なベクトル計算とかが多いから。

石井: そうです。で、WebGLってそもそもOpenGL（※）と同じなので、CGの取り扱いに関しては共通している部分がほとんどです。ただ、置かれている環境は、OpenGLネイティブのゲームやアプリとは随分違う。

一番違う点は、WebGLは必要とされるリソースが全部Web上にあって、ダウンロードが必要という点です。モデルデータの読み込みに時間がかかるんですよね。

だから今まではゲームなど、「読み込みに時間がかかりそうだ」とユーザーも了解しているコンテンツが多かったんです。でも、本来使うデータをしっかり選べば短いロード時間で使えるものも多いんですよ。シェーダーアートとか。

※OpenGL（オープンジーエル、Open Graphics Library）は、クロノス・グループ (英: Khronos Group) が策定している、グラフィックスハードウェア向けの2次元/3次元コンピュータグラフィックスAPIである（Wikipediaより引用）

白石: 確かに、WebGLでできたゲームとか、読み込みに数分待たされるものもありましたね。

石井: はい。モデルデータが大きいと、それだけダウンロードやデータ読み込みに時間がかかってしまう。なので、そうしたWebGLの問題を解決すべく、CGの世界にも進化が起きようとしているんです。

ランタイム向け3Dデータフォーマット「glTF」

白石: 具体的にはどのような進化ですか？

石井: 一つはglTF (GL Transmission Format) と言って、汎用的な3Dアセットフォーマットです。ツールに依存しない軽量フォーマットとして、Khronosが普及を進めています。

glTF

白石: ツールに依存しない、というのはどういう意味ですか？

石井: 以前WebGL上でモデルファイルを扱う際には、MayaやBlenderといったツールのファイルをそのまま読み込んで利用することが一般的でした。これは言わば、「Photoshopのpsdファイルはあるけど、jpgやpngなどの汎用的な画像フォーマットがない」という状況です。

白石: そんな状況だったんですね…知りませんでした。ゲームやアプリとしてひとまとめにパッケージングしてしまうから、汎用フォーマットが必要とされなかったんでしょうか。

石井: 概ねそういうところです。そういう状況を変えようと、COLLADAという汎用フォーマットがKhronosによって提案され、一定程度普及はしています。

ただ、COLLADAファイルはCG編集ツール間でデータをやり取りするためのフォーマットとして設計されているため、WebGLアプリケーションが読み込んで利用するには、編集用のパラメーターなど不要な部分も多いんです。また、XML形式だというのも、ファイルサイズや解析速度の点で不利になります。

glTFは、COLLADAファイルから編集用のパラメータを取り除いて、JSON形式にしたものと言ってほぼ差し支えありません。

白石: なるほど。ただ、そういうフォーマットって、普及させるのがなかなか大変な気もしますが、どうなんでしょう？

石井: glTFは既に様々なライブラリにもサポートされていますし、普及は中々順調と言えると思います（参考: glTFのライブラリサポート状況）。

glTFの面白いところは、大手ベンダーの採用意欲が高いというところです。MicrosoftやAutodeskという大手ベンダーが乗っかってきているんですよ。 Khronos自身WebGLの仕様策定元なので、この分野で発言力が強いこともあります。また、最近ではApple WatchのページでglTFが使われてたりもします。

白石: Apple Watchの公式サイトでもですか！それはかなりの人がアクセスしたでしょうね。確かに、これ単なる画像じゃない。スクロールと共に水滴が別々の動きをしてる…！（重いけど）

Apple Watch Series 3のサイト

石井: glTFは「オーディオにおけるMP3, ビデオにおけるH.264、画像におけるJPEG」といったように、「3DといえばglTF」となることを目指しているとのことで、普及にかけるKhronosの意気込みも並々ならぬものがあります。

頂点データ専用の圧縮形式「draco」

石井: もう一つ注目の技術としては、Googleがオープンソースで開発しているdracoという圧縮形式です。頂点データを効率よく圧縮する技術で、元々の頂点データのサイズに比べて4倍から16倍の圧縮率を誇ります。

白石: 先ほどのglTFにしか使えないんですか？

石井: いえ、汎用的なポリゴンデータ形式（.ply）に対応しているので、元のファイルフォーマットは選びません。

白石: ブラウザによる対応も必要なんですか？

石井: いえ、ブラウザがネイティブ対応するというものでもないんです。dracoによって圧縮されたポリゴンデータは、JavaScriptでデコードすることができます。

白石: なるほど、アプリケーションが自前で圧縮データを展開するんですね。でもそれだと、デコード処理にかかる時間がちょっと心配です。

石井: WebAssemblyでできたデコーダーもあるし、Web Workersで展開すればUI処理を阻害することもないので、そこはあまり問題ないと思いますよ。使うブラウザを選ぶということもありませんし、Three.jsのようなライブラリに任せてしまえば、アプリケーションはデコードについて意識する必要もありません。

白石: ほかには、Webだと画像のサイズを結構気にしたりしますが、CGの世界ではどうなんでしょう？

石井: CGだと、テクスチャ画像のサイズを削減するという話になりますね。ただ、単に画像のファイルサイズを小さくするだけでは片手落ちなんです。いくら元画像のファイルサイズを小さくしても、GPUに乗るときにはフルサイズにデコードされてしまうので、メモリ使用量などにすごく影響するんですね。

なので、GPUが直接扱えるテクスチャ圧縮形式というものがありまして、それらを利用すると、GPU上でも圧縮した状態で画像を扱うことができます。DirectXだとS3TCという形式、iOSだとPowerVR Texture Compression (PVRTC) というように、ベンダーごとに異なってくるんですが。

白石: ベンダーごとに異なるんだと、取り扱いが面倒ですね。

石井: はい、なのでこういうフォーマット変換はWebpackなどで自動化されるべきだと思います。このように、今まではエンジンが自動的に行なってきたことも、WebGLの場合はプログラマーが自分で意識しなくてはなりません。

白石: まとめると、3DをWeb上で行うためにはいろいろな課題があって、それが徐々に解決されつつあるということですね。汎用モデルフォーマットが普及しつつあり、頂点データの圧縮ツールも登場した。そして、テクスチャ圧縮も自動化されるだろうと。

石井: そうです。そもそもWebは、多様なデバイスがネットワークで繋がれていることが前提です。そういうユビキタスな環境で、3Dが自由に表現できる世界に向けて、今まさに具体的で重要な進化が起こっているということです。

WebGLの未来

白石: こうした動きを踏まえて、WebGLの未来はどうなると思いますか？

石井: 今のコンピューターの世界は、やはり2Dを前提としているのは間違いありません。3Dが利用されるシーンは、ゲームなど、コンピューティングのごく一部に限られていました。マテリアルデザインなども、3Dの要素をうまく取り入れてはいますが、前提は2Dです。

ただ、今、GoogleやApple、Microsoftなどの強力なベンダーたちが、こぞってARやMRに力を入れています。このまま進めば、映画館や不動産屋さんとか、あらゆるお店の軒先にARのオブジェクトが浮いている…という世界は普通に来るんじゃないかと思っているんです。3Dがより身近になる世界です。

ただ、そういうのを見るために、わざわざアプリをインストールするのは面倒ですよね。近い将来、そういう面倒くささが、AR/MRの普及を妨げる大きな一因になってくるんじゃないかと思うんです。

しかしWebGLがそういう状況を打開できるんじゃないか、と期待しています。WebGLはWebブラウザさえあれば動きます。PCでもスマホでも動く。アプリのインストールが必要ないし、しかも安全なサンドボックス上で動きます。

白石: 確かに！もしかすると、ビーコン技術との組み合わせとか（※）で、アプリのインストールを必要とせず、気軽にバンバンARコンテンツを見るような時代が来るかもしれませんね。

※Webとビーコン技術との組み合わせとして、Eddystoneという仕組みがGoogleから考案されている

石井: 実際、GoogleがWebARという仕様を作ったりもしていますし、ARには各社力を入れているので、Webでも早晩ARが使えるようになるだろうと思います。

白石: でも実際、要素技術が揃っているだけでは世の中変わらない…という現実もあるかと思います。WebGLも、実際には随分前から使えるようになっていたわけですし。こういう「要素技術が揃っているだけでは越えられない壁」は、どうやったら超えられると思いますか？

石井: 難しい問題ですが、一つは3Dコンテンツの制作コストが高いというのも、普及を妨げる要因にはなるのかなと思います。ただそれは、「人が作る」ことを前提とするからコストが高くつくんだと思うんですよね。

そういう点では、2Dに関しては既にPaintsChainer（AI技術を使い、線画を自動で着色するサービス）やMakeGirlsMoe（AIで自動的に萌えキャラを作成するサービス）のようなサービスが出てきています。同様に、自動で3Dコンテンツを生成するようなサービスも近いうちに登場して、コンテンツの制作コストが劇的に下がるんじゃないでしょうか。

白石: AIサービスでコンテンツの制作コストが激減するというのは面白い発想ですね〜

石井: Adobe Senseiも最近話題になっていますし、デザインの一部をAIに任せるというトレンドが来つつあるのは確実かなと思いますね。

Grimoire.jsは、WebGLをWebエンジニアにとっての「筆」にする

白石: では最後に、開発を進めていらっしゃるGrimoire.jsについても、簡単にご紹介頂けますでしょうか？Three.jsなどのライブラリとは何が違うんでしょう？

石井: Grimoire.jsはWeb開発の中でWebGLを扱うためのフレームワークです。Three.jsやBabylon.jsは、発想がCG中心なんですよね。画面全体をCGで構築するようなコンテンツにはいいのですが、Webコンテンツと混在させて、相互がやり取りするようなプログラムを作るには適していないんです。CGとWebには大きな隔たりがある。それに決められた構造を両者に与えて橋をかける必要があった。

この隔たりは、プログラミングスタイルにも大きく表れてきます。

CGの場合は、フレームごとにグラフィックを変更させていく、いわばフレーム指向です。
一方でWebの場合は、イベントに応じて処理を行うのが普通ですよね。いわばイベント指向です。
こうした隔たりがあるせいで、CG側とWeb側が、お互いにどうデータを受け渡しすればいいか、正解がないというのが今の状況です。

Grimoire.jsは、CG側とWeb側の、2つのAPIを提供することで、両者がシームレスに同居するようなアプリケーションを簡単に作ることができるように設計されています。

白石: 具体的にはどのようなコードになるんでしょう？

石井: Grimoire.jsは、GOMLという専用のマークアップ言語でCGを記述することができます。そして、GOMLの要素を変更することで、簡単にCGを変更できるんです。例えば、立方体にテクスチャを貼り付けて、自動的に回転するようなCGは以下のようなマークアップで簡単に実現できます。

そして例えば、マウスが重なった時だけこの立方体が2倍の大きさになる…という処理は、以下のようなJavaScriptで実現できます。

gr(function() {
  var mesh = gr('#simple .canvas')('mesh')
  mesh.on('mouseenter', function () {
    mesh.setAttribute('scale', '2.0')
  })
  mesh.on('mouseleave', function () {
    mesh.setAttribute('scale', '1.0')
  })
})

白石: おお、簡単ですね！これならWebエンジニアでも簡単に扱えそうです。

石井: はい、そうなんです。イベントを受けてパラメーターを書き換えるという流れは、今のWebアプリケーションフレームワークなどの潮流を見れば古い感じを受けるかもしれませんが、結局のところこれだけあればいくらでもラップすることができます。そのようなモダンなWeb開発の環境でもシームレスに環境を選ばず導入できるんです。Grimoire.jsの目標は「WebGLを、Webエンジニアにとっての『筆』にする」ことなんです。

一方で、CG側にはUnityに近いようなインターフェースのAPIが提供されています。TypeScriptで記述できるビルド環境が提供されているので、Webに疎いCGサイドでもすぐにWebエンジニアの使う筆を作ることができます。再利用可能で、最終的なパラメーター調整などをWeb側が簡単に行えるわけです。実際、そのためにChrome拡張でWebGLの空間をそのまま操作できるインスペクタも提供しています。

Grimoire.js Inspector

WebエンジニアにとってCGをより身近にすること、そしてCGがより一般的な世界にすることを目指しています。

白石: とても期待しています！本日はWebGLの基本的な事柄からGrimoire.jsまで、いろいろ教えていただいてありがとうございました。

石井: 1.0リリースを年内に行いたいと思っています。興味がある方がいたら公式サイトから開発チームのSlackなどに入ると新しい様々な情報が拾えるかと思います。またいくつかの例も載っているのでご覧いただけると幸いです。

（撮影：刑部友康写真提供：html5j HTML5 Conference 2017事務局）

Web技術者よ、Unityを始めよう！Unity WebGL入門──HTML5 Conference 2016セッションレポート

池和田有輔 — Fri, 11 Nov 2016 11:15:56 +0000

連載： HTML5 Conference 2016 特集 (9)

HTML5 Conference 2016特集・第5弾は、「Unity WebGL入門」です。WebGL正式対応により、ゲームをはじめとしたブラウザコンテンツ制作ツールとして広く使われるようになったUnityの概要及びWebGLへの書き出しについて解説します。

WebGLにも対応したUnityのいま

Unityは統合的なインタラクティブコンテンツ制作ツールです。

無料で使えるPersonalから文字通りプロフェッショナルのためのProまで3つのサブスクリプション・プランを用意していますが、根幹となるUnityエディタの機能はどのプランも同一のものとなっており、対応プラットフォームにも違いがありません。つまり、Personalでも強力な3D表現が実現できてしまうのです。

そして2015年末にリリースされたバージョン5.3より、Unityは正式にWebGLに対応し、ゲームを始めとしたブラウザ上でのリッチコンテンツの作成環境として広く使われるようになりました。その後も着実に進化を続け、次期バージョンである5.5ではWebAssembly対応による飛躍的なパフォーマンスの向上が見込まれています。本稿ではUnityのWebGLの概要に始まり、実際にコンテンツ開発を始めるにあたって注意すべき点などを紹介します。

パフォーマンス

Unityをコンテンツ開発の選択肢に挙げるにあたりユーザー最も気にするのは「どの程度のものが作れるのか」という話ではないでしょうか。結論から言うと、iOSやAndoriodなどのUnity製のモバイルネイティブアプリと概ね近しいクオリティが得られます。

特にグラフィックの表現力はWebGL2.0をブラウザでの正式対応に先んじてサポートしており、Unity内で一般的な3Dオブジェクトに使われるStandard Shaderでの描画能力はモバイルよりもデスクトップに近く、ソフトシャドウを使うことも可能です。

反面、マルチスレッド非対応やヒープ領域の制限、ファイルシステムを持たないなどの理由によりCPUとメモリはボトルネックになりやすく、パフォーマンスを引き出すためにはそれらを考慮した実装を考える必要があります。

また、スマートフォンなどのモバイル版ブラウザは現在のところ未対応となっており対応時期も未定です。シンプルなプロジェクトであれば大きな支障なく動作することもありますが、「まあ動くこともある」程度に捉えていただくのが無難です。

Unity WebGLを支える技術

WebGLで実行するためにはコードがJavascriptで書かれている必要がありますが、UnityはEmscripten コンパイラーツールチェーンを使用し、CおよびC++で記述されているUnityのランタイムコードをビルド時にasm.js JavaScript にクロスコンパイルしています。

ams.jsとは高速化を目的としたJavaScript言語仕様のサブセットであり、事前コンパイル（AOT）された形で実行されます。過去にはFireFoxのみに対応していたこの技術も今や多くの主要ブラウザが対応しており、ブラウザ間でのパフォーマンスの差は徐々に埋まりつつあります。また非対応のIEではパフォーマンスに大きな難を抱えています。

では、開発者が記述することになるユーザーコードはどうでしょうか。Unityは.Net互換のMono環境で実行されるので、ユーザーはC#あるいはUnity独自の言語であるUnity Scriptでの開発がメインとなります。

Unityはビルドする際、通常は書き出されたCIL（中間言語）をmonoのランタイムにより各プラットフォームのネイティブコードに変換するわけですが、WebGLをターゲットとした場合はUnityの独自技術であるIL2CPPにより一旦C++に変換し、その後はUnityのランタイムコードと概ね同じ手順でJavascriptに変換されます。

IL2CPPはUnityが多くのプラットフォームに展開、そして最適化するための重要な技術です。

Unityでの設定のポイント

WEBコンテンツである以上、ビルドサイズを少しでも削減することは大きな課題と言えるでしょう。

エンジンコード、及びユーザーの記述したコードについてはリリースビルドとして書き出すことで縮小化、gzip圧縮され、ダウンロード後にブラウザ上で解凍、及びパージングして実行されます。さらにStrip Engine Codeオプションにより使用しないエンジンの機能をあらかじめ削除しておくことができます。

シーンファイル及びシーン内で使用されるアセットはアーカイブデータとして通常1ファイルにまとめられます。

サーバからは上記同様gzip圧縮したものをブラウザ上で展開し、得られたファイルはさらにLZ4形式で圧縮されています。ブラウザのタブを閉じるまでメモリ内にストックされ、使用すべきアセットがロードするときだけ解凍される仕様です。

しかし2種類の圧縮がかかっているとはいえ大量のテクスチャやサウンドを含むデータをコンテンツ開始時に一度にロードさせ、メモリ内に保持し続けることは得策ではありません。ダウンロード時間とメモリ使用量の削減を両立させるためにはhtmlから直接参照されるアセットを最小限に留め、それ以外をAsset Bundleで提供することが望ましいと言えます。

Asset Bundleは簡単に言うとアセットをシリアライズしたアーカイブファイルです。実行時にサーバからダウンロードして利用するため読み込みのタイミングを管理し、必要なくなったタイミングで破棄し、メモリを解放することができます。使用の際は通常アセット同様にチャンクベースの圧縮形式LZ4が多くのケースで有用です。

Unityの提供するサービスとの連携

前述した通り、WebGLへのビルドは複雑な手順で行われており、他のプラットフォームに比べ時間を要します。CIサーバを用意して自動化するという解決法もありますが、もっと手軽な方法としてUnityはクラウド上でビルドを行うサービスを提供しており、サービス内容に差はあるものの全てのプランで無料提供されています。

GitやSubversionなど広く使われるソースコントロールであればリポジトリを更新するだけで自動的に行われ、書き出されたURLを伝えればどこからでも確認できるようになります。またAssetBandleのビルドもサポートしており、開発効率を上げるためには欠かせないサービスとなっています。

その他にもユーザーの環境や動向を分析するUnityアナリティクスや、Unityエディタに統合された簡易的なソースコンントロールであるUnityコラボレイトなど、Unityの提供するサービスは広がり続けています。

まとめ

冒頭でも述べましたが、Unityは統合的なインタラクティブコンテンツ制作ツールであり、WebGLを構築するためのJSライブラリ等とはアプローチが大きく異なります。

特に3Dビューに慣れていない方は最初は戸惑われるかもしれません。しかしユーザー数やコミュニティに後押しされる形で多くの情報をWebで手軽に入手できるほか、チュートリアルや入門書籍なども充実しています。一度是非お試しください。

Unity – Game Engine

当日の資料と動画は下記で公開されていますので、こちらも参照してください。

講演資料

VR成功の鍵はWebVRにあり！？ ── HTML5 Conference 2016セッションレポート

比留間和也 — Thu, 20 Oct 2016 00:00:07 +0000

連載： HTML5 Conference 2016 特集 (3)

セッション内容を講演者自らが解説するという「HTML5 Conference 2016特集」の第三弾。今回のテーマは「Webのグラフィックス後編: WebGL2、そしてWebVR」。
すでに策定が始まっている次期バージョンWebGL2.0のお話や、WebでVRを実現する「WebVR API」を用いてVRコンテンツの実装の仕方を解説します。

VRとは？

今年、2016年はVR元年と言われ、様々なVRデバイス、VR関連ガジェット、VRコンテンツが世に生み出されています。しかし、VR発祥は意外と古く、遡ること1960年代にVRの基礎となる理論、デバイスが発表されています。

ただ当時は個人で手が出るものではなく、体験自体はデパートのアトラクションとして登場するなど、体験は限定的でした。

参考

時を戻して2016年。世界が動き出します。
2016年6月時点のGoogle検索トレンドでは、検索回数が飛躍的に伸びているのが見てとれます。

きっとこれを読まれている方も、周りで「VR」というワードを聞くことが増えてきたのではないでしょうか。そしてこの波に乗るように、VRについてもWebでの体験を可能にする技術が公開されています。

WebVRは体験の話ではない

WebでのVR技術、それが「WebVR」です。
取りざたされているVRを手軽にWebで体験できるもの。それが「WebVR」。

…ではなく。
あくまでWebVRはイチ仕様に過ぎません。
つまり、WebVRに対応したからといって、即座にWeb上でVRコンテンツを提供できる、という類のものではないということです。

WebVRはAPIの仕様

誤解を恐れずに言えば、WebVRはセンサーからの情報を扱うためだけのAPIです。
要は、HMD（ヘッドマウントディスプレイ）からの位置、回転、視野情報など様々な、ハードウェアの情報を取り扱うAPIということです。もっと言ってしまえば、モバイルで利用しているジャイロセンサーとなんら変わることはない、ということです。

事実、WebGLの仕様と比べると格段に少ない内容の仕様となっています。（仕様はこちら）

VRコンテンツの構築

Webで手軽に体験できるVRコンテンツ、と書きましたが提供する側が同じく手軽であるとは限りません。
（とはいえ、その他のネイティブなVRコンテンツと比較すると格段に手軽だと思いますが）

WebVRはただのAPIだと書きました。
つまり、VRコンテンツ自体は別のAPI、具体的にはWebGLを利用して3Dコンテンツを制作する必要があります。事実、VRコンテンツの制作について既存の3Dコンテンツの制作と違いはほとんどありません。

WebGLコンテンツでは通常、requestAnimationFrameなどを利用して、一定時間置きに画面を更新しアニメーションやインタラクションを実現します。ジャイロセンサーを使ったコンテンツの制作を行ったことがある方であれば、どういったコンテンツが制作できるのかのイメージがわくでしょう。

そして上でも書いたように、ジャイロセンサーで行っていたような処理をWebVR APIに替えて画面を更新してやればいいのです。

ただし、（当然ではありますが）通常のWebGLコンテンツとWebVRコンテンツでは決定的に違うところがあります。それは「VR体験を作り上げる必要がある」という点です。

具体例を上げましょう。
今までの3Dコンテンツはカメラの位置は製作者側で制御可能でした。
ということはつまり、都合の悪い、カメラの後ろ側を映さないようにカメラを制御することができた、ということです。しかし、VRコンテンツはそのカメラの操作はユーザーの視点という形で使われるため、当然、その後ろ側を見られる可能性があります。
（というより、ほとんどの場合、ユーザーはあたりを見渡すでしょう）

このように、裏側が見られてしまうということは、悪く言えば手抜き、よく言えば無駄を省いた部分までもしっかりと作り込まないとならないということを意味しています。

基本的なセットアップ方法

さて、それではざっくりとですが、WebVR APIを使ったセットアップのコードを紹介しましょう。
本コードはこちらのサイトのサンプルを引用させていただいています。

▼ HMDハードウェアの参照を取得する

navigator.getVRDisplay().then(function (displays) { if (!displays.length) { return; }



vrDisplay = displays.length[0];

}).catch(function (err) { console.error('Could not get VRDisplay', err.stack); };

▼ 描画対象として必要なサイズを取得する

var eyeParameter = vrDisplay.getEyeParameters('left'); var width = eyeParameter.renderWidth; var height = eyeParameter.renderHeight;

▼ WebGLのCanvasおよびVRモード移行のための処理を記述 var webglCanvas = document.querySelector('#webglcanvas'); var enterVRBtn = document.querySelector('#entervr');



enterVRBtn.addEventListener('click', function () {
    vrDisplay.requestPresent({source:webglCanvas});
}, false);

vrDisplay.exitPresent();

▼ 画面のアニメーションループを処理する var id = vrDisplay.requestAnimationFrame(onAnimationFrame);



function onAnimationFrame() {
    id = vrDisplay.requestAnimationFrame(onAnimationFrame);
}

vrDisplay.cancelRequestAnimationFrame(id);

▼ HMDのセンサーからの値を取り出す var pose = vrDisplay.getPose();



var orientation = pose.orientation;

var position = pose.position;

▼ ハードウェアに設定された個々の設定を読み取る（瞳孔間距離など） var eyeParameters = vrDisplay.getEyeParameter('left');



var eyeOffset = eyeParameters.offset;

var eyeMatrix = makeProjectionMatrix(vrDisplay, eyeParameters);

▼ 取得した情報から、プロジェクション行列を生成する function fieldOfViewToProjectionMatrix (fov, zNear, zFar) { var upTan = Math.tan(fov.upDegrees * Math.PI / 180.0); var downTan = Math.tan(fov.downDegrees * Math.PI / 180.0); var leftTan = Math.tan(fov.leftDegrees * Math.PI / 180.0); var rightTan = Math.tan(fov.rightDegrees * Math.PI / 180.0); var xScale = 2.0 / (leftTan + rightTan); var yScale = 2.0 / (upTan + downTan);



var out = new Float32Array(16);
out[0] = xScale;
out[1] = 0.0;
out[2] = 0.0;
out[3] = 0.0;
out[4] = 0.0;
out[5] = yScale;
out[6] = 0.0;
out[7] = 0.0;
out[8] = -((leftTan - rightTan) * xScale * 0.5);
out[9] = ((upTan - downTan) * yScale * 0.5);
out[10] = -(zNear + zFar) / (zFar - zNear);
out[11] = -1.0;
out[12] = 0.0;
out[13] = 0.0;
out[14] = -(2.0 * zFar * zNear) / (zFar - zNear);
out[15] = 0.0;

return out;

}

Three.jsを使えばお手軽

WebGLといえばThree.js、というくらいデファクトスタンダードなライブラリとなったThree.js。
実はThree.jsのリポジトリにはWebVRに対応するためのプラグインがすでに存在しています。

それは VRControl.js と VREffect.js の2種類です。
これはどちらもThree.jsでVRを実現するのを手助けしてくれるプラグインです。
VRControl がHMDのセンサーの処理を、 VREffect.js がフルスクリーンモードへの移行や、VRモードの表示を手助けしてくれます。

基本的に、Three.jsを使った3Dコンテンツ制作の方法はVR化すると言っても大きな違いはありません。
その証拠に、VR化するためのコード断片は以下のようにとても短いものとなります。

var controls = new THREE.VRControls(camera); var effect = new THREE.VREffect(renderer);

// clickイベントなどのユーザ操作のタイミングで実行される関数 function toVRMode() { effect.requestPresent(); }

対応ブラウザ

対応ブラウザは、執筆時点（2016/09/28）ではまだ限定的にしか存在していません。
安定版で動作するものは今のところないのが現状です。

対応状況は以下のサイトから確認することができます。
Is WebVR Ready?

VR成功の鍵を握るのはWebVR

個人的な見解ですが、VR成功の鍵をにぎるのはWebVRにあると思っています。
その理由はいくつかあります。

一つ目が、プラットフォーム（Oculus Rift、HTC Viveなど）に依存しないこと。
つまり今までのWebアプリと同様に、モバイル、PCなどのプラットフォームに依存しないコンテンツ展開ができることです。

二つ目に、インストールが不要なこと。ネイティブアプリにしてしまうとどうしてもこの「インストール」という手順が必要になってしまいます。しかし、WebVRであればWebサイトに訪れたユーザが、VRモードの開始ボタンを押すだけでVR体験をすることが可能になります。

そして最後の三つ目として、「ちょっとだけVR」が使えること。
例えばECサイトの商品をVRで見てみる、例えば不動産サイトの部屋の感じをVRで体験してみる、などなど、VRが活用できればユーザの利便性が上がることはたくさんあります。

しかし、例えばこれらを、アプリをインストールしたのちにしか行えないとしたら大部分の人はそれを倦厭するでしょう。

またコンテンツ制作側からしても、そんなちょっとしたVRアプリだけをプラットフォームに載せて配信する、というハードルの高さも出てくるでしょう。

こうしたように、今までの「Webならではの良さ」がそのままVRにも当てはめることができると考えています。そしてこれが結局、VRとユーザの接点となり、より多くの人にVRとはなにか、VRでどんなことができるかを広める機会になると考えています。

まとめ

まとめると、

WebVRはAPIの名称
WebVR APIがやってくれるのはセンサーの値を取るなどの最低限の処理のみ
Three.jsを使えば手軽にVRコンテンツの制作が可能
とはいえまだサポートブラウザが（ほぼ）ない
しかし、Webでの活用はまだまだ（いい意味で）未知数

ということです。
詳細についてはカンファレンスで使用したスライドがアップされているので、そちらを参照ください。

当日の動画は下記で公開されていますので、こちらも参照してください。（編集部注：動画は3：26：10あたりから比留間さんの講演となります）

HTML5の技術だけで実装！「YouTubeみたいなWebGLプレーヤー」とは？

松田光秀 — Tue, 09 Sep 2014 23:50:15 +0000

連載： HTML5 Japan Cup 特集 (7)

この記事では、HTML5 Japan Cup 2014で優秀賞を頂いた「YouTubeみたいなWebGLプレーヤー」で利用されている技術を解説します。

はじめに

「YouTubeみたいなWebGLプレーヤー」はコンテンツそのものとは分離された、オープンソースJavaScriptライブラリ「jThree」のプラグインです。オープンソースとして公開していますので、誰でも自身の作品に差し替えてブログなどに掲載することができます。WebGLの描画部分は全てjThreeで管理しています。この記事では、プレーヤーで採用している2つのHTML5 APIとjThreeの概要をご紹介します。

プレーヤーの機能

このプレーヤーは、まるで動画のごとくWebGLコンテンツを楽曲付きで再生できます。動画との違いはコンテンツ内のオブジェクトを自由に操作できることです。私が作ったものはカメラのアングルを操作するだけですがJavaScriptでできることなら実装可能です。 Oculus Rift表示に切り替えるボタンが標準搭載されておりVR体験を楽しむこともできます。

SVGで作成した再生ボタン

プレーヤーの中央に表示される赤い再生ボタンは、インラインSVGで描画しています。CSSを合わせても600バイト以下で画像よりデータ量を抑えられたのがポイントでした。WebGLに対応しているブラウザは、全てSVGをサポートしているので惜しみなく使うことができます。

再生ボタンのHTMLは以下の通りです。

Fullscreen APIで全画面表示機能を実現

プレーヤー右下の全画面表示ボタンを押すと、Fullscreen APIによってブラウザの枠も越えて、PC画面いっぱいにコンテンツが表示されます。プレーヤーはVRデバイスのOculus Riftにも対応しているため、より高い没入感を得るために必須の機能です。

全画面表示を切り替えるJavaScriptのコードは以下のとおりです。

function requestFullscreen( target ) {

	if (target.webkitRequestFullscreen) {
		target.webkitRequestFullscreen(); //Chrome15+, Safari5.1+, Opera15+
	} else if (target.mozRequestFullScreen) {
		target.mozRequestFullScreen(); //FF10+
	} else if (target.msRequestFullscreen) {
		target.msRequestFullscreen(); //IE11+
	} else if (target.requestFullscreen) {
		target.requestFullscreen(); // HTML5 Fullscreen API仕様
	} else {
		alert("ご利用のブラウザはフルスクリーン操作に対応していません");
		return;
	}

}

function exitFullscreen() {

	if ( document.exitFullscreen ) {
		document.exitFullscreen(); //HTML5 Fullscreen API仕様
	} else if ( document.cancelFullScreen ) {
		document.cancelFullScreen(); //Gecko:FullScreenAPI仕様
	} else if ( document.webkitCancelFullScreen ) {
		document.webkitCancelFullScreen(); //Chrome, Safari, Opera
	} else if ( document.mozCancelFullScreen ) {
		document.mozCancelFullScreen(); //Firefox
	} else {
		document.msExitFullscreen();
	}

}

オープンソースJavaScriptライブラリ「jThree」

今回の作品のベースとなっているオープンソースJavaScriptライブラリ「jThree」についてご紹介します。今回紹介したプレーヤーとそれで再生するコンテンツ（WebGL）は「jThree」を使うことで、jQueryによく似た記法で操作・作成することができます。

「jThree」は8/31に「jThree v2」をリリースしました。これまで外部XMLファイルに記述していたWebGL描画タグをHTMLに埋め込めるようになりました。つまり、jThree v2は「インラインWebGL」を実現したのです。外部ファイルに頼らずHTMLファイル1つだけで描画することが可能で、当然アニメーションさせる前段階の静的な描画処理にはJavaScriptを一行も書く必要がありません。

jQuery関数の代わりにjThree関数を使ってDOMを操作することにより、動的な描画処理ができる点は従来通りです。さらに、これまでjThreeはMMD（.pmx/.vmd）のデータにしか対応していませんでしたが、v2からはプラグインによってあらゆるファイル形式を読み込めるようにもなりました。

jThree v2公開と同時にthree.js用JSON（.json/.js）・DirectX（.x）・Collada（.dae）・STL（.stl）の各ファイルに対応したプラグインを公式で用意しています。OBJ（.obj）とMTL（.mtl）ファイルにも順次対応予定です。

詳しい「jThree」の解説は、私が執筆したCodezineさんの記事をご覧ください。

※ jThree v2に対応したプレーヤーはありません。公式サイトでの配布も終了するのでプレーヤーを使ってみたい方はCodezineさんの第6回記事からサンプルファイルをDLしてお使いください。 jThreeプレーヤープラグインの使い方

最後に

今回は、「jThree」のプラグインとして開発した「YouTubeみたいなWebGLプレーヤー」の要素技術について解説しましたしました。最優秀賞を獲れなかったことは非常に残念ですが、誰もがこのプレーヤーのように手軽にWebで3DCGを楽しめる世界を実現することを目指し、開発を続けていきます。

WebGLとWebSocketによる3Dオンラインレースゲーム「JS-Racing」の全て！（前編）

西田慎吾 — Fri, 29 Aug 2014 00:00:58 +0000

連載： HTML5 Japan Cup 特集 (5)

今回はHTML5JapanCup2014にてWebGL賞と優秀賞を受賞したオンラインレースゲーム、JS-Racingの技術解説を書かせていただきます。

このコンテンツはWebGLの3D表現を活かした3Dレースゲームです。
また、WebSocketを使用しサーバを介して、複数のクライアントでの同時走行が可能なオンラインゲームになっています。同時に、ソケット通信時に発行されるソケットIDをPCとスマートフォンで共有することで、スマートフォンからPC上の車を操作することも可能です。

クライアントサイドの使用技術

クライアントサイドの構築において、目的・用途に応じて使用した言語やライブラリに関して解説します。

TypeScriptによるクラス設計

クライアントサイドのメインとなるロジックをTypeScriptを使用して設計しました。TypeScriptはマイクロソフトによって開発されたフリーでオープンソースのプログラミング言語です。大規模JavaScriptアプリケーションに向けて開発されたTypeScriptは、これまでのJavaScriptにはない以下の機能を有しています。

型注釈とコンパイル時の型チェック
クラス
インターフェイス
モジュール

TypeScriptはコンパイルして最終的にJavaScriptに出力することができます。今回のように多くの機能の実装が必要になるWebアプリケーションでは、クラスベースのオブジェクト指向言語的な特徴を持つTypeScriptは、設計しやすく非常に有効なものになります。

ActionScript3と同じように、1つのTSファイル（TypeScriptファイル）にクラスを1つだけ記述して、ファイル名とクラス名を一致させました。また、モジュール毎にディレクトリを作成して、クラスを格納しています。これにより機能毎にモジュールとクラスを整理する事ができ、再利用しやすく見やすいコードになりました。最終的には、クラス毎に作成したTSファイルを、クラス毎のJavaScriptファイルに出力（コンパイル）し、Gruntで結合、圧縮して、実際に読み込むJavaScriptファイルにしています。

今回の場合、モジュールの分け方は、まず表示要素とロジックにモジュールを分けました。表示要素はゲームの各シーンや、3D描画、画面下部のランキング表示というように、表示要素単位でさらにモジュールを細分化していきます。ロジックは、イベントや値管理、定数、ユーティリティ、コースデータ管理、物理演算、リアルタイム通信といった、機能単位でモジュールを細分化していきます。このようにモジュールを分けていくことで、大規模なコンテンツ開発の際には、各クラスの責任範囲が明確化でき、バグが発生した際にも、原因を特定しやすく、さらには仕様変更にも強くなります。

TypeScriptは大規模開発においては、非常に設計しやすく、クラスベースのオブジェクト指向言語のメリットを最大限に享受できるものだと思います。ただその分、設計における手間と、なによりコード記述量が多くなります。中規模以下の案件では、最低限の設計で手軽に構築できるCoffeeScriptも、よい選択肢ではないかと思います。

Box2DJSを使った2D物理演算

車を走らせたり、障害物と衝突したりといった、ゲームの中核となるロジックはBox2DJSを使用しています。Box2DJSは、質量・速度・摩擦をシミュレーションするJavaScriptの2D物理演算エンジンです。

表現方法自体は3Dですが、物理演算エンジンは2Dを使用しました。今回のようなシンプルなゲームを作るには、3Dの物理演算エンジンより、2Dの物理演算エンジンの方が、ゲームバランスや操作感において向いていると感じます。コンシューマーゲームなどの本格的なゲームとなると、3D物理演算エンジンによる処理は、必要不可欠なものだとは思いますが、その分、マシンへの負荷も高くなります。

物理演算に関しては、別途サンプルを作成して、チューニングしていきました。ゲームの中核となる部分ですので、まずこのサンプルで楽しいと思えるかどうかで、最終的なゲームのゴールが見えてくると思います。可能な限りゲーム性向上のためのチューニングしていくことが大切です。

初期段階のモックアップのイメージですが、まずはこのようにBox2Dを使って、2Dレースゲームを構築しました。この2Dレースゲームの情報を3D表示部分や情報部分（スピードメーター等）やコースデータ管理ロジック、リアルタイム通信ロジックに渡します。

物理演算クラスimjcart.logic.physics.Physicsにて、マップ情報を元にnew Carで車インスタンスを生成し、車の状態が変更したイベントCHANGE_CAR_CONDITION_EVENTをキャッチして、イベントを発行します。

public createCar() {
    // マップ情報を元に車を生成
    var x = 0;
    var y = 0;
    var i, j, max, max2;
    for (i = 0, max = imjcart.logic.map.value.MapConst.MAP.length; i &amp;lt; max; i = i + 1) {
        for (j = 0, max2 = imjcart.logic.map.value.MapConst.MAP[i].length; j &amp;lt; max2; j = j + 1) {
            if (imjcart.logic.map.value.MapConst.MAP[i][j] == imjcart.logic.map.value.MapConst.MAP_KEY_CAR_START_POSITION) {
                y = imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE * i;
                x = imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE * j;
                break;
            }
        }
    }
    this._car = new Car(this._context, this._world, x, y);
    // 車状態変更イベント
    this._car.addEventListener(event.PhysicsEvent.CHANGE_CAR_CONDITION_EVENT, (evt) =&amp;gt; {
        this.dispatchEvent(imjcart.logic.physics.event.PhysicsEvent.CHANGE_CAR_CONDITION_EVENT, {
            x: evt.x,
            y: evt.y,
            bodyAngle: evt.bodyAngle,
            wheelAngle: evt.wheelAngle,
            speed: evt.speed,
            power: evt.power,
            gear: evt.gear,
            direction: evt.direction
        });
    });
}

imjcart.logic.physics.Carクラスでは、update関数が実行されると、入力されている値をホイールに反映し、車の状態に変化を与えます。変化した車の情報を付加して、車の状態が変更したイベントCHANGE_CAR_CONDITION_EVENTを発行します。

public update() {
    // ホイールに力を適応
    var i = 0, max;
    for (i = 0, max = this._frontWheels.length; i < max; i = i + 1) {
        var wheel = this._frontWheels[i];
        var direction = wheel.GetTransform().R.col2.Copy();
        direction.Multiply(this._enginePower);
        wheel.ApplyForce(direction, wheel.GetPosition());
    }
    // ホイールと車をつなぐジョイント部分に角度を適応
    for (i = 0, max = this._frontWheelJoints.length; i < max; i = i + 1) {
        var wheelJoint = this._frontWheelJoints[i];
        var angleDiff = this._steeringAngle - wheelJoint.GetJointAngle();
        wheelJoint.SetMotorSpeed(angleDiff * this._steerSpeed);
    }
    // 車状態変更イベントの発行
    var position = this._body.GetPosition();
    var velocity = this._body.GetLinearVelocity();
    var speedX = Math.abs(velocity.x);
    var speedY = Math.abs(velocity.y);
    var speed = 0;
    if (speedX < speedY) {
        speed = speedY;
    } else {
        speed = speedX;
    }
    this.dispatchEvent(imjcart.logic.physics.event.PhysicsEvent.CHANGE_CAR_CONDITION_EVENT, {
        x: position.x,
        y: position.y,
        bodyAngle: this._body.GetAngle(),
        wheelAngle: this._frontWheelJoints[0].GetJointAngle(),
        speed: speed,
        power: this._enginePower,
        gear: this._gear,
        direction: this._engineDirection
    });
}

dispatchEventメソッドは、イベントを発行するlib.event.EventDispacherクラス（オリジナルで作成）に定義されたメソッドです。表示要素のクラスはこのlib.event.EventDispacherクラスを継承しています。

three.jsの3D表現

WebGLを使った3D表示部分にはthree.jsを使用しています。three.jsは、WebGLを扱うライブラリとしては、最もよく使われているJavaScriptライブラリです。

Blenderというオープンソースの3次元コンピュータグラフィックスソフトウェアを使って、3Dモデルの作成を作成し、three.jsで読み込んで表示しています。Blenderで作成する3Dモデルデータ（今回のモデルデータはOBJ形式）は、ジオメトリ（形状）とUVテクスチャのみで、three.jsを使って、質感などの調整をしています。

また、今回のように実行環境が制限しづらいWebアプリケーションでは、なるべく多くのユーザーが利用できるように、マシンへの負荷は極力減らさないといけません。特にレースゲームは、現在走っているコースの先が見える必要があり、視野を広くしなければならないために、処理するデータ量が増え、より負荷がかかってしまいます。この負荷軽減のために、以下のことを考慮しています。

ポリゴンが少なくても成り立つデザイン
影をつけない
ジオメトリ（形状）の結合
負荷の少ないマテリアル（質感）を選択

1つめのポリゴンが少なくても成り立つデザインに関しては、下のタイヤのサンプルで、左のタイヤはポリゴン数を極端に減らしていますので、光や深度の計算が少なくなり、マシンへの負荷も小さくなります。右のタイヤはリアルなタイヤを再現したために、ポリゴン数も多く、マシンへの負荷も大きくなります。配置する量が少数ならそれほど問題になりませんが、コースデータに沿って多数配置する障害物ですので、マシン負荷は大きくなります。ただ、ポリゴン数が少ない分、リアルな表現からは遠く離れてしまっています。コース全体のデザインも含めてですが、リアルな表現を求めないポップなデザインを採用することで、低ポリゴンでも違和感のないようにしています。

2つめの影をつけないですが、下のキャプチャを見ていただければ、影がない左側のキャプチャと影がある右側のキャプチャでは、3D空間としての説得力にだいぶ違いが出てしまっているかと思います。ここは苦渋の決断ですが、影をつけることはthree.jsではとても負荷のかかる処理なので、より多くのユーザにストレスなく遊んでもらうためにも影をつけない方を採用しました。

ちなみに影を出すには、レンダラーのshadowMapEnabledをtrueにして、光源のcastShadowをtrueにします。そして影を作る側の物体のcastShadowをtrueにして、影を受ける側の物体のreceiveShadowをtrueにします。デフォルトではfalseのため影が出ません。

// レンダラー
renderer.shadowMapEnabled = true;
// 光源
light.castShadow = true;
// 影を作る側
mesh.castShadow = true;
// 影を受ける側
mesh.receiveShadow = true;

3つめのジオメトリの結合に関してですが、WebGLコンテンツの様にGPUを使用するコンテンツは、ジオメトリの数だけGPUに対してドローコール（描画命令）をします。このドローコールの回数はパフォーマンスに大きく影響します。ジオメトリをTHREE.GeometryUtils.merge(geometry, mesh)メソッドで結合することで、不要なドローコールの発生を少なくすることができます。注意点としては、結合したものは個別に動かすことや、マテリアルを個別に設定することはできませんので、今回は壁やコースなど、個別に動くことのない、大量に描画する必要のある要素に対してジオメトリの結合をしています。

var geometry = new THREE.Geometry(); // 空のジオメトリを作成
var meshArr = [];
// モデルデータとマテリアルを読み込む
var loader = new THREE.OBJMTLLoader();
loader.load("models/block03/block03.obj", "models/block03/block03.mtl", (object) => {
    object.traverse(function (child) {
        if (child instanceof THREE.Mesh) {
            child.material = new THREE.MeshLambertMaterial(child.material);
            child.material.ambient = new THREE.Color(imjcart.display.main.view3d.value.View3dConst.AMBIENT_COLOR);
            meshArr.push({
                mesh: child,
                material: child.material
            });
        }
    });
    // 読み込んだモデルデータをマップデータに沿って、クローンして配置。
    var i, j, max, max2;
    for (i = 0, max = imjcart.logic.map.value.MapConst.MAP.length; i < max; i = i + 1) {
        for (j = 0, max2 = imjcart.logic.map.value.MapConst.MAP[i].length; j < max2; j = j + 1) {
            if (imjcart.logic.map.value.MapConst.MAP[i][j] == imjcart.logic.map.value.MapConst.MAP_KEY_BLOCK) {
                var tagX = imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE * j + (imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE / 2);
                var tagY = 1;
                var tagZ = imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE * i + (imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE / 2);
                var mesh = meshArr[1].mesh.clone();
                mesh.position.set(tagX, tagY, tagZ);
                THREE.GeometryUtils.merge(geometry, mesh); // 空のジオメトリにマージして結合していく
            }
        }
    }
    this._block = new THREE.Mesh(geometry, meshArr[1].material);
    this._scene.add(this._block);
});

最後に4つめの負荷の少ないマテリアル（質感）の選択は、表面の質感を上げるマテリアルを選択すると、その分マシンへの負荷が上がるということです。マテリアルの種類は代表的なもので、以下のメリットがあります。

MeshBasicMaterial : 光の影響を受けない
MeshLambertMaterial : 影や光の反射などを描画できる（ランバート反射モデル）
MeshPhongMaterial : 影や光の反射などをより綺麗に描画できる（フォンシェーディング）

マシンへの負荷に関しては1、2、3の順に次第に高くなります。選択したマテリアルの違いもマシン負荷への影響は大きいですが、マテリアルにバンプマップを使うかどうかもマシン負荷への影響は大きくなります。バンプマップは表面に細かな凹凸を表現します。下のキャプチャはアスファルトにバンプマップを適応したもの（右）と、適応していないもの（左）の違いです。表現力を上げるためには、バンプマップを採用したいところですが、ここでもマシン負荷を考慮してバンプマップを使っていません。

リアルな表現に近づければ近づけるほど、マシンへの負荷が増えてしまいます。ある程度の表現力は確保しながら、どれだけ負荷を減らせるかの調整は、これくらいのスペックなら問題なく表示できるようにしたいというターゲットとなるマシンを決めて、そのマシンで最低限確保したいフレームレートを決めます。あとは都度、フレームレートを確認しながら調整するということの繰り返しになります。マシンスペックだけでなく、ブラウザによっても表示速度に差異があることを意識していなければなりません。

HTML5のAPIによる新しい表現力

WebGL以外のHTML5の要素も、それぞれの特徴にあわせて適宜使用しています。

Canvas：コースマップ（コース縮尺図）
SVG：スピードメーター
WebFont：タイトルやテキスト全般
CSS3：角丸やドロップシャドウやボタンデザイン

WebGLによる3D表示をしているCanvasの上に、各要素を配置していますが、上に乗っかっている要素を動かしたり、形状を変更させる場合には、背景に不透明な物を敷くなどの工夫が必要になります。そうしないと上に乗っかっている要素に変更があるたびに、下のCanvas全体まで、不要な再描画処理がかかってしまい、描画のパフォーマンスを著しく低下させてしまいます。

まとめ

以上が今回作成したJS-Racingで利用した、主なクライアントサイド技術になります。

3D表現として利用したWebGLは、IE11の対応によって最新のモダンブラウザでは、ほぼ実行可能な環境が揃ってきていると思います。

ユーザーのマシンスペックや、WebGL対応ブラウザの普及率を考えると、まだある程度ユーザーをしぼる必要がありますが、最近では話題を呼んでいる3Dコンテンツも次第に増えてきたように感じます。

次回はサーバサイドの使用技術と、その他の技術トピックに関して解説する予定です。

WebGLを活用した3D Web ゲーム『翠星のガルガンティア～キミと届けるメッセージ～』

春日井良隆 — Tue, 01 Jul 2014 04:00:20 +0000

Production I.Gと日本マイクロソフトのコラボレーションによる3D Webゲーム『翠星のガルガンティア　～キミと届けるメッセージ～』が、Internet Explorerのデモサイト「Rethink」シリーズの日本発コンテンツとして、6月18日に公開されました。

このゲームはアニメ『翠星のガルガンティア』から生まれたスカイアクションゲームで、この作品のためにシナリオを書き下ろし、アニメ本編の声優はフルボイスで出演、そして世界中のファンが楽しめるように、日本語と英語のキャプションを用意するなど、ゲームそのものに気合いが入っているだけでなく、開発者向けにはソースコードの一部と3Dモデルを公開し、WebGLの裾野を広げることも目的にしています。

Web 表現の限界に挑戦

大いに自慢したいのが、そのWebGLの表現力と応答性です。大きな入道雲や飛行ルートを邪魔する気流、すれ違うカモメの群れ。いずれもリアルタイムに美しく描画しているだけでなく、ゲームの爽快感を損なわないように滑らかに軽快にレンダリングされています。

このゲームはInternet Explorer 11のタッチ操作に最適化されていますが、マウスとキーボードでも遊ぶことができます。さらにGamepad APIにも対応。ゲームパッドコントローラでも遊べます。また、レスポンシブWebデザインを反映して、プレイできるエリアはディスプレイの解像度に合わせて自動的に調整されるようになっています。

オープンソースのTurbulenzエンジンで構築

ガルガンティアでは、開発者がより効率的に3DのWebコンテンツが作れるようなリファレンスになることも目標の一つです。今回はイギリスに本拠地を置くゲームデベロッパー、Turbulenzと連携し、オープンソースのTurbulenz Engineを使って開発しています。

Turbulenz EngineはJavaScriptとTypeScriptで実装された2D/3Dゲーム開発エンジンです。ハイパフォーマンスな物理エンジン、高品質なビジュアルエフェクト、パーティクルシミューレション、アニメーションエンジンといった豊富な機能を提供し、ゲーム技術の広い範囲をカバーしています。

Turbulenz Engineは無料でGitHubからダウンロードできます。

さらに、ゲームの一部のソースコードと3Dモデルも公開しています（アドベンチャーパート、ボイスデータ、BGMデータは含まれません）。こちらもGitHubからダウンロードできますので、読者の皆さんもぜひお試し下さい。ソースの入手とWebサーバーへの配置については、弊社のエバンジェリスト物江がブログ「ゲーム『翠星のガルガンティア』のソースの入手とIISへの配置方法」で紹介しています。

IE9で掲げた「Same Markup」と同様に、いまもIEの開発ではWeb標準への準拠をなによりも大切にしています。この『翠星のガルガンティア　～キミと届けるメッセージ～』もWebGLに対応したほかのブラウザでもお楽しみいただけます。今後、新しい面が追加されていきます。お楽しみに！

初心者でも絶対わかる、WebGLプログラミング＜three.js最初の一歩＞

小山田晃浩 — Fri, 07 Feb 2014 02:00:07 +0000

連載： WebGLプログラミング (2)

WebGLはとても高度な技術である一方、APIは低レベルであるためそのまま使うにはどうしても冗長な準備を行う必要があります。一方で、JavaScriptライブラリーを通して高レベルなAPIとしてWebGLを利用する方法があります。こうしたJavaScriptライブラリーとしてはthree.js、Away3D.js、Babylon.jsなどが有名です。その中でも特に人気があるthree.jsを通して、WebGLを利用する方法を解説します。(three.jsのリビジョンは執筆現在の最新であるr65を利用します)

three.jsを手に入れる

three.jsはhttp://threejs.org/から手に入れることができます。downloadから、zipファイルを手に入れましょう。

ダウンロードしたファイルを展開すると多くのファイルが格納されていますが、必要なライブラリー本体はbuildフォルダ内にthree.min.jsとして配置されています。three.min.jsのみを取り出しましょう。three.min.js以外のファイルは不要です。

three.jsにおける抽象化された概念

まずは、基本的なコードを書きながらthree.jsにおける概念を知りましょう。ここでは皆さんの理解が深まるように図を見ながらコードの解説を進めます。

コードを書き始める

HTMLファイルを新規作成し、three.min.jsを読み込みます。合わせて、あなたがコードを書いていく場所も用意しましょう。今回はこれをmainという名前の関数とし、DOM構築完了を待ってから実行します。





get started with three.js

シーンを作る

まずはシーンを作ります。シーンはこれからあなたが作る3Dの世界となります。ただし、この段階ではシーンの内容は空の状態です。

var main = function () {
  var scene = new THREE.Scene();
};

カメラを作る

シーンの状態を撮影するカメラを作ります。カメラに写った内容が最終的にブラウザー上で表示されることになります。

var main = function () {
  var scene = new THREE.Scene();

  var width  = 600;
  var height = 400;
  var fov    = 60;
  var aspect = width / height;
  var near   = 1;
  var far    = 1000;
  var camera = new THREE.PerspectiveCamera( fov, aspect, near, far );
  camera.position.set( 0, 0, 50 );
};

PerspectiveCameraは4つの引数が必要です。これらは、カメラが写す範囲を示しています。

fovは画角を示します。
aspectは撮影結果の縦横比を示します。
nearはニアークリップの距離を示します。nearより近い領域は表示されません。
farはファークリップの距離を示します。farより遠い領域は表示されません。

つまり、指定した画角と縦横比によって作られる四角錐の内、nearからfarまでの間が表示されるわけです。

このあと3Dオブジェクトを追加することを考え、カメラの位置を中心から少し手前に引いておきます。カメラインスタンスはpositionという位置を示すプロパティーがあり、positionはx、y、zの3つのプロパティーを持っています。初期ではx、y、zの値は全て0です。この値を変更するにはsetメソッドを利用します。setメソッドの引数はx, y, zの3つを順に渡します。上記のコードではset( 0, 0, 50 )としているので、カメラはzの正方向、つまり手前に50の位置に設置されるわけです。

※ 古いリビジョンのthree.jsでは、作成したカメラインスタンスをscene内に追加する必要がありましたが、現在はその必要がありません。

レンダラーをDOM上に設置する

ここまでで基本状態が用意できました。ただし、この状態ではHTMLと紐づいておらず表示結果を求めることができません。three.jsでは、レンダラーをDOMに設置することでこれを実現します。

var main = function () {
  //ここまでの内容は省略

  var renderer = new THREE.WebGLRenderer();
  renderer.setSize( width, height );
  document.body.appendChild( renderer.domElement );
};

レンダラーのサイズとして渡しているwidthとheightは、先ほどカメラのアスペクトを求める際に利用した値を流用します。これでbody要素内に、横600px縦400pxのレンダラーを展開することができます。

光源を追加する

ここまでのコードでは空（から）のシーンとそれを写すカメラを用意できています。ここに光源を追加してみましょう。three.jsでは様々なタイプの光源を利用できますが、今回は平行光源を追加します。

平行光源はインスタンスを作る際に2つの引数を渡します。第一引数は光の色、第二引数はオプションで光の強さを渡します。この例では第一引数に0xffffffを渡し、白色の光としています。

var main = function () {
  //ここまでの内容は省略

  var directionalLight = new THREE.DirectionalLight( 0xffffff );
  directionalLight.position.set( 0, 0.7, 0.7 );
  scene.add( directionalLight );
};

平行光源は光の角度を変えることができます。その場合、positionプロパティーで光源の角度を決定します。directionalLight.position.set( 0, 0.7, 0.7 )であれば上方向と手前方向、つまり斜め上前からの光となるわけです。

物体を追加する

物体を追加してみましょう。今回は箱を設置します。three.jsでは、原始的な図形を作成するためのクラスがいくつか用意されています。もちろん、3Dモデリングツールでつくった3Dモデルを読み込むこともできますが、自作のモデルを読み込む方法はまたの機会に解説します。

three.jsではジオメトリー(形状)とマテリアル(表面素材)を用意した上で、メッシュ(物体)を作成するという手順が必要です。

var main = function () {
  //ここまでの内容は省略

  var geometry = new THREE.CubeGeometry( 30, 30, 30 );
  var material = new THREE.MeshPhongMaterial( { color: 0xff0000 } );
  var mesh = new THREE.Mesh( geometry, material );
  scene.add( mesh );
};

まずはジオメトリーを作ります。箱型のジオメトリーはCubeGeometryクラスで作成可能です。横幅、高さ、奥行きの順に数値で引数を渡します。

次に、マテリアルを作ります。three.jsでは様々なタイプのマテリアルが用意されていますが、今回はフォンシェーディングで表示できるMeshLambertMaterialを利用します。引数には色やカラーテクスチャ、光沢などをオブジェクトで指定することができます。今回は赤色（0xff0000）のカラーのみを指定します。

そして、ジオメトリーとマテリアルからメッシュを作成し、メッシュをシーンに追加します。

表示する

これで、シーン、カメラ、レンダラーを用意しシーンの中には光源と物体がある状態ができました。これをレンダリング（表示）してみましょう。

レンダラーインスタンスはrenderというメソッドを持っており、ここに任意のシーンとカメラを渡すことで、該当のシーンをレンダリングします。

var main = function () {
  //ここまでの内容は省略

  renderer.render( scene, camera );
};

レンダリング結果は次の通りです。

(invalid jsdo.it code)

これを見ただけでは3Dには感じられないかもしれませんね。しかし、この状態でしっかりと3Dで赤色の箱が真正面から静止した状態で表示されています。

回転アニメーション

止まった状態で正面からレンダリングしても面白い結果にはなりませんでした。3Dのよさを引き出すために、箱を少しずつ回転させながら、レンダリングを繰り返してみましょう。こうすることでアニメーションで表示されます。

(invalid jsdo.it code)

var main = function () {
  //ここまでの内容は省略

  ( function renderLoop () {
    requestAnimationFrame( renderLoop );
    mesh.rotation.set(
      0,
      mesh.rotation.y + 0.01,
      mesh.rotation.z + 0.01
    )
    renderer.render( scene, camera );
  } )();
};

名前付きの即時実行関数を用意し、requestAnimationFrameで自分自身を呼び出し続けることで、レンダリングを繰り返すことができます。

関数内部ではmesh、つまり箱のrotationプロパティーの値を少しずつ変え、直後にレンダリングを行います。これにより箱が回転するアニメーションとなるわけです。rotationプロパティーはpositionプロパティーと同様にsetメソッドで内容を変更することができます。

まとめ

最後にコード全文を示します。





get started with three.js

three.jsでは、今回解説した流れが最も基本であり、お決まりです。この抽象化された概念とシーン構築から表示までの流れを覚えておきましょう。

初心者でも絶対わかる、WebGLプログラミング＜基礎知識編＞

小山田晃浩 — Tue, 15 Oct 2013 22:00:12 +0000

連載： WebGLプログラミング (1)

HTML5に関連する技術のひとつに、WebGLがあります。WebGLは、ブラウザー上で3DCGプログラミングを実現できる技術です。今回のレポートでは、WebGLプログラミングの基礎知識についてご紹介します。

WebGLって？

WebGLでどんなことができるのか──百聞は一見にしかず。まずは例を見てみましょう。demo内のスライダー部分をドラッグすることでカメラの位置などを任意に変更できますので、リアルタイムでレンダリングされていることがわかるでしょう。

(invalid jsdo.it code)

このように、ブラウザー上でプラグインに頼ることなく、なめらかな表面、自然な影、高FPSでのリアルタイムレンダリング（アニメーション）など、まるで最近の家庭用ゲーム機にも匹敵する高度な3DCG表現ができるわけです。

WebGLは2013年10月現在、Chrome、Firefox、Operaで標準対応されており、加えてIE11でも対応される予定です。また、Safariも現状では設定が必要なものの、WebGLを利用する準備は整っており、WebGLは多くの環境で利用できるようになりつつあります。

Can I use WebGL?より

WebGLの仕様自体は、クロノスグループからWebGL 1.0が2011年3月に正式リリース（W3Cでいう勧告）されています。従って今後APIが変更されることはなく、またWebGLのAPIはブラウザ上で「WebKit」や「Moz」といったような接頭辞なしで利用することができます。さらに2013年9月にはWebGL 2.0の仕様策定が開始されています。

【コラム】WindowsなのにOpenGL系?

WebGLはその名前の通り、OpenGL由来のAPIです。一方で、Windowsの一般的なグラフィックAPIはOpenGLではなく、DirectXです。しかし安心してください。Windows上でのWebGLは、最終的にDirectXに自動翻訳されて実現しています。つまり、WindowsでもMacでもAndroidでも、WebGLはプラットフォームの垣根を気にせず利用できる、共通のグラフィックAPIというわけです。

例えば、以下はWindows IE11におけるWebGLの仕組みです。なお、Windows用のChromeやFirefoxでも、ブラウザー内部に組み込まれたANGLEというライブラリにより、IE11と似た仕組みでWindows上のWebGLを実現しています。

Hyper-Fast Web Graphics with WebGLより

WebGLプログラミングで実現できること

WebGLはJavaScriptから利用するAPIです。Web開発者はJavaScriptを書くことで、閲覧者のOSに関係なくブラウザーを通してデバイスのGPU（CPUと対となる、描画処理を専門に行うためのハードウェア）にアクセスすることができます。これによりWebGLは高度な3DCG表現を実現できるわけです。

筆者のPC内に搭載されているGPU、Geforce GTX 760。ノートPCなどではGPUがCPUに内蔵されている場合も多い。

さて、WebGLはGPUにアクセスできるという点に少し注目してみましょう。非Web技術の話になりますが、PCで動作する3Dのオンラインゲームなどは、ネイティブのグラフィックAPIを通して、GPUでその描画を行っています。一方で、ブラウザー上で動くWebGLも同様にGPUでその描画を行います。つまりデバイスのGPUの性能にも依存しますが、WebGLは近年のPC用3Dオンラインゲームと同じレベルの描画ができるということになります。

例えば以下は2013年5月に公開されたEpic Citadel HTML5というデモで、WebGLで動いています。( 「Firefoxに最適化されている」と表示されますが、Chromeでも問題なく動作します)

もし今あなたがモバイル端末などでこの記事を読んでいてWebGLを再生できない場合は、以下の動画を見てみるといいでしょう。

また、WebGLの実態はJavaScriptと先に少し触れましたが、これはWebGLが他のWeb標準技術との相性がいいということを意味します。XHRでデータを取得したり、HTMLで用意したボタンやinput要素で3Dモデルを操作したり、JavaScriptのイベントを利用したり、といった応用が可能なのです。これにより、ただ表示するだけではなく、さまざまなWebアプリケーションへの応用も期待できます。

例えば、地図に利用したり、教育目的に利用したり、あるいはWebの技術でゲームを作ったりすることも可能です。

現在プレビュー版として提供中の新しいGoogleマップでもWebGLが使われている。東京都庁周辺の様子を見ると、高層ビル群が立体的に表示されている。

ロンドンの地下鉄マップ。3Dで表現するなら、複雑な立体構造の情報も提供しやすい

銀河の観察。WebGLは、教育目的のWebアプリケーションにも応用できるだろう

WebGLは難しい？

ここまで「WebGLはJavaScript」と繰り返しましたから、Web制作者にとって、WebGLを利用するための敷居が低く感じるかもしれませんね。しかし実際のところ、WebGLを利用するにはとても冗長な手順を踏む必要があります。さらに加えて、3DCGプログラミング（OpenGLやDirectX）の基礎知識、行列やベクトルといった線形代数学の知識、GLSLという言語の知識など、これまでWeb制作者にとってほとんど馴染みがなく、かつ学習コストの高いさまざまな知識を要します。

WebGLを利用する手順を図にしてみました。これを見るとWebGLの冗長さがわかるでしょう。

しかし安心してください。こうした、手間のかかるところ、難しいところを吸収し、より直感的にJavaScriptでWebGLを扱うためのライブラリーがあります。

WebGLのラッパーライブラリー「three.js」

three.jsは、現在最も有名なWebGLのラッパーライブラリーです。WebGL界のjQueryのような存在です。WebGLを採用した多くのプロジェクトは、既に当たり前のようにthree.jsを利用しています。

three.jsの事例

Web制作者は、OpenGLのお作法、GLSLという未知の言語、線形代数学などのWebGLのための学習コストが高い関連知識がなかったとしても、JavaScriptと、わずかな3Dの基礎知識さえあればthree.jsを利用し、WebGLをコントロールすることができます。もしあなたがWebGL初心者であるならば、three.jsを利用してみるといいでしょう。

three.jsはWebGL上級者にも愛されているライブラリーです。行列計算のためのAPI、自身で用意した頂点データをVBOに適用するAPI、自作のGLSLをシェーダーに適用するAPIなども備えています。

また、海外のWebGL関連のジョブボードを見てみても、three.jsがWebGL界のディファクトスタンダードライブラリーという裏付けにもなります。いくつかのWebGL関連の求人では、three.jsの経験が求められています。

three.js本体の開発はGitHubで管理されており、three.js制作者であるMr.doob氏が中心となり、世界中の多くのコミッターに支えられています。このこともthree.jsがディファクトスタンダードなライブラリーとして支持される理由でしょう。

こうしたさまざまな背景もあるので、もしあなたがWebGLに興味を持ったのなら、まずはthree.jsを使ってみることをおすすめします。

まとめ

今回はWebGLがいかに汎用的であるか、そしてそのWebGLをより簡単に利用するための手段となる、three.jsの存在についてレポートしました。また近いうちに、three.jsの実際の利用方法についてご紹介していきます。

ブラウザで3Dグラフィックを扱うWebGL、最新版 2.0のドラフト版が公開

増井雄一郎 — Tue, 17 Sep 2013 10:57:11 +0000

2013/9/16、WebGL Working Groupはブラウザで3Dグラフィックを扱うWebGLの最新版 WebGL 2.0のドラフト版が公開しました。

WebGL 2 Specification

WebGL 2の最大の特徴は、2012年10月に標準化された組み込み向け3DグラフィックAPIのOpenGL ES 3.0の機能をベースにしているところです。

OpenGL ESは3DグラフィックをサポートするためのAPIで、WebGLではこの機能をブラウザ内で使えるようにすることで、ゲーム機の3Dグラフィックのような高度な3D表現をJavascriptから操作することが可能になります。

既に多くのブラウザではWebGL 1をサポートしており、すでにゲームを中心に使われる様になってきました。ChromeのCMでも使われていたChrome World Wide Mazeで使われていたので、実はWebGLを見たことがある人は多いと思います。(本記事ではWebGL 1.0をWebGL 1と表記します)

WebGL 2では、WebGL 1をベースに上位互換性を保ちつつ、さらなるパフォーマンス向上と多くの機能強化を行ってきました。

WebGL 2の特徴

WebGL 2はOpenGL ES 3.0をベースとしているため、その特徴をそのまま引き継いでいます。大きな特徴は、陰影処理やマッピングなどの高度な表現の最適化です。3Dグラフィックでもリアリティある表現が多く求められるようになり、そのような複雑な処理を行いやすくする機能が充実しています。

Brandon Jones氏は、TojiCode: What’s coming in WebGL 2.0にて、WebGL 2の特徴と新機能を次のようにまとめています。各項目の詳細については元記事を参照してください

特徴

Multiple Render Targets – 陰影処理などの遅延を行うDeferred Shadingの基礎技術
Instancing – 同じオブジェクトが沢山ある処理を早くする
Vertex Array Objects – 頂点計算の処理をまとめて行う
Fragment Depth – フラグメントのデプス値をサポート

新機能

Multisampled Renderbuffers
3D Texture
Sampler Objects
Uniform Buffer Objects
Sync Objects
Query Objects
Transform Feedback

実装状況

WebGL 2は、Firefoxで実装が進められており、現在公開されているNightly buildで動かすことができます。

Mozilla WikiのWebGL2ページでは、サンプルコードも掲載されており、自分で試すことができます。

まとまったデモのソースコードなどはまだ公開されていませんが、下記の多くのオブジェクトを影付きで動かすデモがYoutubeで公開されています。

今後、Web上でも3D表現を使ったゲームやコンテンツが増えていくと予想されます。

WebGLの最大の問題は、Internet Explorerではサポートされていないことだと言われてきましたが、現在ベータ版のInternet Explorer 11からWebGL 1のサポートを開始しました。これによりさらにWebGLによる開発が活発化していくでしょう。

3Dグラフィックの分野は、まだまだ発展中の分野で新機能やパフォーマンスの向上が継続的に行われています。

WebGL 2はOpenGL ES 3.0という最新の3Dグラフィック環境を、ブラウザとJavascriptで試すことができるため、3Dプログラミングに興味のある方は注目してみると面白いのではないでしょうか。

斉藤祐也の海外WEBテク定点観測＜Issue.5: 2013/08/31-2013/09/13＞

斉藤祐也 — Mon, 16 Sep 2013 22:00:17 +0000

プログレッシブ・エンハンスメントに対する熱い議論、Steve Losh氏による技術文書の正しい書き方、JavaScript本の名著であるEloquent JavaScript2版のクラウドファンディングなど、14日間（8/31～9/13）のWeb開発最新ニュース合計18件を紹介します！

注目ニュースピックアップ

プログレッシブ・エンハンスメントはもう過去の話なのか?

この14日間はプログレッシブ・エンハンスメントについて多くの議論が行われた。

事の発端はDaniel Mall氏が始めたSigh, JavaScriptという様々なWebサイトで、JavaScriptをオフにした際の状態をキャプチャしてリストするというTumblr。
それに対して、Ember.jsのメンテナーであるTom Dale氏がProgressive Enhancement: Zed’s Dead, Babyと題した記事で「プログレッシブ・エンハンスメントはもう終わったアプローチである」と宣言した。
そのTom Dale氏の記事に、Jake Archibald氏がProgressive enhancement is fasterにて反論。そして、Daniel Mall氏も“Progressive Enhancement. Still Alive & Kickin’.でSign, JavaScriptを始めた理由を説明した。これらの反論に対して、Tom Dale氏はMaybe Progressive Enhancement is the Wrong Termにてプログレッシブ・エンハンスメントという言葉の意味は範囲を再確認している。技術者的な視点だけではなく、デザイナからの視点でもこのトピックに対して様々な記事があがったりと、プログレッシブ・エンハンスメントそのものに対する興味関心の高さが分かるすばらしい議論となった。

効果的なドキュメンテーションの作り方について – Steve Losh

原題: Teach, Don’t Tell

Steve Losh氏によるテクニカル文書、主にプログラミング言語やライブラリなどのドキュメンテーションの書き方について、7つのアンチパターンを通して、よりよいドキュメントを書くために覚えておきたいことをまとめている。
自分でオープンソースとしてライブラリなどを公開している方はもちろん、会社やチームのガイドラインを作成している人にも、勉強会などでプレゼンをする人にもおすすめできるすばらしいアドバイス。

Eloquent JavaScript 第二版 – Marijn Haverbeke

原題: Eloquent JavaScript second edition

JavaScriptを学ぶ上で読んでおくべき書籍は?という質問には確実に名を連ねてくるのがMarijn Haverbeke氏による「Eloquent JavaScript」。解説だけではなく、実際に手を動かすエクササイズがあったりと、当時としては画期的な書籍で、さらにクリエイティブ・コモンライセンスでオンライン版は無料で公開されている。
2007年に執筆されたこの本は、現在第二版に向けて執筆を始めている。筆者はその執筆のためにクラウド・ファンディングをしているので、興味がある方はぜひファンドに協力してみてはいかがだろう。

すばらしいデザインは常にすばらしいスタイルである – MISC Magazine

原題: Great Design Always Means Great Style

Don Norman氏によるよいデザイン、よいスタイルについてのこの記事では、そもそもデザインにおけるスタイルとは単純な見た目のファッションではなく、パーソナリティのようなものではないかと説明。パーソナリティとは車でいうところのポルシェやBMV、メルセデス・ベンツのようなブランドに抱くイメージを分かりやすい例として紹介している。
氏は記事を以下のように締めくくっている。『すばらしいデザインとは常にすばらしいスタイルを意味する。正直で、理路整然としていて、一貫性があるものだ。』

リソース・プライオリティ – W3C

原題: Resource Priorities

パフォーマンスは今ではインフラ担当の人間だけの問題ではなく、もちろんフロントエンド開発者だけの問題でもなく、全員の問題だ。
その全員にはもちろんW3Cも含まれる。
Resource Prioritiesという仕様はまだドラフト段階ではあるが、画像やスクリプト、ビデオやオーディオに対して、lazyloadやpostponeという属性を追加できるようにするものだ。
これらの属性はJavaScriptを使ってすでに解決されつつある問題ではあるが、仕様として存在する意義は大きい。

海外トレンドコラム

ECMAScript 6のArrowファンクションについて – NCZOnline

原題: Understanding ECMAScript 6 arrow functions

ECMAScript 6で追加される予定のArrowファンクションについてNicolas Zakas氏による解説。
Arrowファンクションはその名前の通り、関数のシンタックスを => このような矢印を使って置き換えることができるようになる。
ただそれだけではなく、newができない、thisのバインディングが違うなどの点が異なる。

テスト駆動開発とはなにか、そしてどんなものなのか

原題: 30 Days of TDD: Day One – What is TDD and Why Should I Use It?

テスト駆動開発にについて、30日間連続で書き続けるチャレンジの1日目。第一回目は、そもそもテスト駆動開発とはどんなものか、そして、その開発ワークフローをどうして利用するべきなのかを解説。

ドメイン・シャーディングをもう一度振り返ってみよう – High Performance Web Sites

原題: Domain Sharding revisited

パフォーマンスにおいて、SPDYやHTTP 2.0の時代が来るとアンチパターンになると言われている。だが、ドメイン・シャーディングというテクニックについて、スティーブ・サウダー氏は、そうとも言えないのではないかと話し、大抵のウェブサイトにおいては次の時代でも活用できるとしている。

レスポンシブ・イメージ会議メモ – Shane Hudson Dot Net

原題: Responsive Images Meeting Notes

9/10にパリで開かれたレスポンシブ・イメージに関する会議のメモ。若干散文的ではあるが、会議で話された内容について大事なポイントをおさえているので、非常に参考になる。先日、webkitにてsrcsetが実装されたが、レスポンシブな環境における画像の取り扱いについて、まだまだ課題は多い。今後も目が話せないトピックだ。

いまさら聞けないHTTP

原題: Know Your HTTP Well

もう本当にいまさら聞けないHTTPにまつわる話を、仕様やヘッダ、メディアタイプ(今後追加される様子)、メソッド、ステータスコードなどのように区分し、それぞれ詳しく解説している。あっという間に1000スターという人気のほどなので、いまさら聞けないのは私だけではなかったようです。

Mutation Observersの使い方 – Dev.Opera

原題: Getting to know mutation observers

JavaScriptが多く利用されるプロダクトの制作を行っているとあるDOMノードツリーが変わったタイミングを知りたいということはよくある。
この記事で紹介をしているDOMレベル4仕様で定義されたMutation Observersは、これまで抱えてきた問題を解決してくれる。これまで利用してきたMutationEventとの違いを踏まえて、利用方法を解説。

CoffeeScriptに未来はあるのか?

原題: Does CoffeeScript Have a Future?

CoffeeScriptはどんな役割を持った言語なのか、JavaScriptに変換される言語としてはよく使われる言語ではあるが、もしかするとJavaScriptそのものの変化にしたがって、もう必要がなくなるかも知れない。CoffeeScriptを愛してやまない著者のゆらぎを感じる非常にすばらしい記事。

クローズアップ“ビデオ/スライド”

WebGLの基礎と応用 – Steven Wittens

原題: Making WebGL Dance

前回の本連載にてピックアップしたActo.netのSteve Wittens氏による、WebGLのイントロダクションビデオ。非常にベーシックな三角形から描画し、アンチエイリアスなどから始め、徐々に3Dの世界へ導いていく。数学的なアプローチは難しい部分も多いが、最終的なアウトプットを見ると、チャレンジする価値があると思わせるプレゼンテーション。

ジャンク・バスターズ: Google Chromeにおけるレンダリングパフォーマンスについて – Nat Duca & Tom Wiltzius

原題: Jank Busters – Chrome Rendering Performance

GoogleのNat Duca氏とTom Wiltzius氏によるJank Bustersシリーズのアップデート版。これまで両氏は何回か同じトピックでプレゼンテーションを行ってきているが、最新版にアップデートされたもの。アニメーションだけではなく、レンダリングプロセスを最適化するために知っておいたほうがよいことばかりをコンパクトに解説している。

一歩先行く“コード”

animo.js

jQuery依存が気にならない、ことはないが、Dan Eden氏作のanimation.cssをベースに、連続したアニメーションを行うのに非常にシンプルなシンタックスで可能にしている。

JavaScriptでJPEG画像を壊してみよう

原題: Image Glitch Experiment

正直なところ何の役に立つのかはわからないが、JavaScriptを使ってJPEG画像を破壊するツール。こういった実験的な実装は見ていて楽しいが、作るとより楽しいはず。

Paul Irishおすすめ。フロントエンド開発者のためのフィード

原題: Frontend Feeds

私自身にとって、貴重な情報源であるGoogleのPaul Irish氏がまとめたフロントエンドデベロッパのためのフィード。
以前にも彼はこの形式でフィードを共有していたが、今回はGitHub。Paulチョイスだけあって、非常にクオリティが高いのでおすすめ。

海外で話題の“ツール”

Custom Element: モダンなWebアプリのためのWeb Componentsギャラリー

原題: Custom Elements – A Web Components Gallery for Modern Web Apps

まだまだ登録数は少ないが、Web ComponentsをGitHubのリポジトリから登録でき、検索可能にするギャラリーサイト。
今後はコンポーネント数が増え、欠かすことができないツールになりえるかもしれない。

★次回の「斉藤祐也の海外WEBテク定点観測」は、9月30日にお届け予定です。★