この記事はGLBoost Advent Calender 2016の２日目の記事です。
はじめに
今日の記事では、GLBoostの現状と今後の設計について書いていきます。
GLBoostの目指すところ
GLBoostは、GithubのREADMEにもある通り、一応「CG技術者やゲームプログラマなどのギーク向け」のライブラリを目指してます。（そう宣うお前は果たしてギークなのか、というツッコミは置いといて…）
なぜそうしたかというと、既存のライブラリは便利で簡単に扱える機能は搭載していても、その反面、柔軟性というかなんというか、利用ユーザーが好き放題やれる感じではなかったからです。
例えば、
- レンダリング方式・パイプラインが固定されており、利用者が介入できない。
- 様々なCG技法がすでに完成された形で実装されており、利用者がライブラリのローレベル機能を使って各種CG技法を独自に実装したり実験できない。
- WebGLのリソースにアクセスできず、隠蔽されている（これについてはライブラリによってはできるものありますが）
GLBoostでは、上記の既存のライブラリが「できない」点をできるようにすることを目的としています。
すなわち、
- レンダリングパイプラインを、ユーザー側がカスタマイズできる
- ユーザー側がライブラリが提供するローレベル機能を使って、様々CG技法を実験・実装できる。
- WebGLのリソースにアクセスできる。
ということです。
とはいえ、こうしたことを実現しようとすると、全体的なAPI設計がローレベルになって、扱いにくいライブラリになるのではないか、という懸念される方もいらっしゃると思います。
そこで、GLBoostではライブラリを３層のレイヤーに分けています。すなわち、最下層のレイヤーでライブラリとして最もローレベルの機能を提供し、中位層でシーングラフ等のミドルレイヤー的な機能を、最上位層でより複雑な応用的CG技法をユーザーがワンタッチで使える高レベルAPIを提供する、というものです。
GLBoostは３つのレイヤーからなる
| Layer | Description | Target Users |
|---|---|---|
| Low | Geometryクラスや数学クラスなど、 3Dプログラミングをする上で車輪の再開発を行いたくない ルーチン処理を代行してくれるクラス群。 これらを使い、ユーザーはレンダリング機構を 独自に作る必要があります。 |
3Dギーク |
| Middle | 中レイヤーでは、シーングラフ機構が提供され、 さらにそれらがレンダラーと協調動作します。 このことにより、シーングラフにMeshやカメラ、 ライトなどを追加するだけで、ほぼ自動的に レンダリング処理が行われます。 RenderPassクラスを使うことで、複雑な マルチパスレンダリングも可能です。 |
3Dギーク/中級者 |
| High (Coming Soon) | 初心者向け。マルチパス技法を使った高度なCG技法を ワンタッチで有効にできます。その詳細について、 ユーザーは何も知る必要はありません。 Unreal EngineやUnity、Three.jsを 使っているのと同じ感覚で使えます。 |
3D初心者 |
ソースディレクトリを見てみると、実際にそれぞれのレベルごとにディレクトリが分かれていたりします。
https://github.com/emadurandal/GLBoost/tree/master/src/js
GLBoostの配布形態も、ローレイヤーのみの機能を提供するglboost_low.jsとミドルレイヤーまでの機能を含むglboost_middle.js、ハイレイヤーまで全ての機能を含むglboost.jsの３バージョンを提供しようと思っています（まぁ、ここまでする必要性はあまりないかもしれせんが）
例えば、ユーザーはローレイヤーやミドルレイヤーのAPIを使って、自分独自のミドルレイヤーやハイレイヤーを作ることが可能です。
実際、そこまでカスタマイズしてくれるユーザーが出てくるほどGLBoostが広まって、信頼されるのか、というとまぁ今のところまだわかりませんけど、方向性としてはそういうところを目指しています。
この３レイヤー階層設計の懸念点
懸念点としては、やはりここまでレイヤーをはっきり分けると、パフォーマンス低下が気になります。他の一般のライブラリでは、こういう考え方は取らずにいることで、より高密度に最適化ができているはずですので、パフォーマンス面は気をつけて実装しないと、他ライブラリに比べて引けをとる恐れがあります。
今後はTypeScriptへの移行を予定
現在は、BabelとRollup.jsを使って、ECMAScript 2015（ES6）でGLBoostのコードを書いています。
しかし、そろそろ型がないと辛くなってきました（笑）
TypeScript2.xで、さらに--strictNullChecks付きでセキュアにコーディングしていきたいですね（TypeScriptでのNull安全なコードを書くのがどれくらいの面倒くささで済むのかはちょっと気になりますが）。