「ビジュアルアーツ分野 / オーサリング・プロダクション」 の読み解き
1ヶ月くらい間が空きましたが、CESA ゲーム開発ロードマップの、ビジュアルアーツ分野では最後となる、「オーサリング・プロダクション」の項目を読み解いてみました。
今回読み解いた項目も、説明が少なかったのと、ほとんどプログラマさんの領域じゃないかなぁ？と思う箇所が多かったので、挫折しかけたりしましたが、ひとまず分かる所を押さえてみました。
オーサリング・プロダクション
＜最新＞
- プログラマブルシェーダの要求に応じた抽象データ生成
- ３Dスキャン、３Dブラシツールなどの高効率手法の導入
- 大規模データの効率編集、分散環境
- 高効率なコンテントパイプライン
- アセット管理システムの浸透
＜数年後＞
オーサリング・プロダクション ＜最新＞
プログラマブルシェーダの要求に応じた抽象データ生成
かなり、難航しましたが、結論としては、CEDEC2005で講演された「あなたのゲームにシェーダを組み込むイロハ」に行き着きました。単にいうと、シェーダーを抽象化し、メタデータという形式で、シェーダー作成を簡単にやってしまおうというもののようです。スピーカーの川瀬さんのサイトで詳細な資料を見つけましたので、詳しくはそちらで確認できます。
- CEDEC2005_Kawase.ppt
よく、色々なメイキングで、動的光源の数が変わっただけで、シェーダーを別々で用意しないといけないという話を聞いたりしますが、それを一つ一つカスタムでコーディングしていく作業を緩和する用途で、使わるもののようです。
３D スキャン、３D ブラシツールなどの高効率手法の導入
これはそのままですね。3Dスキャナを導入したり、Zbrush・Mudboxなどのスカルプトツールを、開発パイプラインに導入するって事でしょう。
3Dスキャナについては、導入事例がいくつかあると思いますが、最近で言うと「龍が如く3」で使われていたり、先日セミナーに参加した、UFC2009で使われていたり、主にフォトリアリスティックな世界観で、モデリングのベースとして使用するようです。特に後者のUFC2009では、実際の選手が登場する作品なので、3Dスキャナの利用は必然で、非常に効果的だったと想像できます。
また、3Dブラシツールに関しては、昨今のゲームでは、ノーマルマップを作成するために、必要不可欠な存在となっていますので、そのままの内容ですね。
大規模データの効率編集、分散環境
分散環境は、DCCツールでのレンダリングの分散化(分散レンダリング)、コンパイルコンパイルしリンクするビルド作業の分散化(分散ビルド)って事でしょう。
レンダリングの分散は、ライトマップの生成や、動画のエンコードなど、出来る限り複数のマシンに分散して、処理時間を短縮しようという試みです。ただ、ゲーム開発では、あまり大規模なレンダリングが発生しない傾向にありますので、映像業界のように、レンダーファームが組まれたりする事は稀のようです。
ただし、いくつか大規模に分散レンダリングを行った例があり、SEGAの「ソニックワールドアドベンチャー」や、Bungieの「Halo3」で使われた、Bungie Farmなども有名なようです。
ソニックワールドアドベンチャーでは、ライトマップ（GIテクスチャの焼きこみ)にインハウスツールを使用。BungieFarmでは、ライトマップのレンダリング、ビルド(バイナリ・コンテンツ)などを、ジョブとして投げると分散処理してくれるようです。Bungie Farmについては、非常に興味があるので、また後日詳細を調査してみたいと思います。
高効率なコンテントパイプライン
これはデジタルコンテンツ協会が発行している「デジタルコンテンツ制作の先端技術応用に関する調査研究」に掲載されていました。少し、内容を引用すると、
各コンテンツ制作における(CG・サウンド・2D・メニュー…)データフローを「コンテンツ
・パイプライン」という言葉を使う事にする。〜中略〜
コンテンツ・パイプラインの設計思想の中核は、あらゆる段階における「繰り返し作業」(イレレーション)の時間を最小限にすることにより、制作工手の流れを効率化することにある。
とあるので、言葉通りの内容のようです。また、上記の資料で例に挙げられていました内容を引用すると、
例えば「キャラクターAIのロジックを変更して実機上でチェックを行う」1回の作業が、「プログラムをコンパイルして実機にアップロードしてゲームをスタートさせて、所定のマップまで行ってチェックする」といったように、5分も10分もかかってしまう工程と、リアルタイムにスクリプトで変化させる事が出来る工程では、開発者の試行錯誤のモチベーションと、コンテンツの質において大きな開きが出てくるのである。
とあります。これに関して、CryENGINE 3 に搭載(？)されている、Sandboxエンジンのプレビュー機能が思い出されます。これは地形を変更したり、データを編集した後、その場からゲームがスタート出来、すぐさまテストできてしまう環境です。
※もっとわかりやすい動画があったと思うので、見つけ次第差し替えます。
アセット管理システムの浸透
これは、バージョン管理システムの浸透って事ですね。最近のセミナーで各ゲームの開発環境を紹介する時には、組み込まれていない例が無くなって来ているように思います。
その中でも特によく聞くのが、CVS・Subversion・Alienbrainの3種類で、Perforceがたまに聞くくらいでしょうか。実感としては、もうこれが無いと安心して作業が出来ない状態なんですが、まだまだ、バイナリデータの管理に使うと、動作がとっても重かったりするので、インハウスのツールを作っている会社*1などもあるようです。
また、最近徐々に聞かれ始めてきているのが、Git・Mercurialなどの分散バージョン管理システム。コレによって、通常のバージョン管理でネックになっているLANの帯域不足をある程度軽減できるようです。ちょうど自分も、このあたりを勉強し始めているので、後日もう少し掘り下げてみたいと思います。
オーサリング・プロダクション ＜数年後＞
ここからは、数年後の技術を読み解きます。
多様な色空間・HDRI テクスチャのハンドリング
色空間で検索して出てきたのが、HSV色空間。Wikipediaで調べると下記のとおりでした。
HSVモデル(HSV model)は色相(Hue)、彩度(Saturation・Chroma)、明度(Brightness・Lightness・Value)の三つの成分からなる色空間。
なので、HDRテクスチャの輝度情報などと合わせると色の管理がしやすいって事でしょうか。ただHSVってあまり馴染みが無いですよね。DCCツールのライトの設定時に色相を変更せずに、明度を変えたい時に重宝しますが、それが普及するって事かもしれません。
確かに、ポストエフェクトで行う、カラーコレクションなどでは、意図した色に変更しやすかったり便利かもしれません。そんな気がしてきました。
ファインアート・実在物からのデータ構築
ファインアートは全く分からないので置いておいて…。「実在物からのデータ構築」で思いつくのが、BRDFの測定と、別項目で挙げられていたインバース・レンダリングの事だと思います。
インバース・レンダリングは後述するとして、BRDFとは、ある方向から光が入射したとき、それぞれの方向へ,どれだけの光が反射されるかを表す関数で、現実にある物体のBRDFを計測する事で求められるようです。
BRDFの計測に関しては、「BRDF/BTDF測定システム」なるものを見つけました。こんなもの売ってるんですね…。
また、技術自体は、ハリウッド映画のメイキングなどでよく聞きますが、ゲームではさすがに無いだろなぁ、と思っていたら「真・三國無双 Online」で使用されているようです。下記サイトで、シェーダーの適用の仕方と、パラメータの編集なども動画で見れるようになっていますので、興味があればチェックしてみてください。
- ユーザ事例（真・三國無双 Online） [SOFTIMAGE]
インバースレンダリング
色々調査していると、下記の資料に突き当たりましたのが、そちらで概要は理解できそうでした。
簡単に言うと、一枚もしくは複数枚の写真や絵を基にして、そこに写る形状や質感(反射特性・光源分布)などから、データを生成しましょうという事みたいです。形状を作ってシェーダーを割り当てて、最終結果を求めるのが普通ですが、この工程を「結果から過程」を、逆(インバース)で求めようというのが、インバースレンダリングと呼ばれる所以みたいです。
ファイル操作やバージョン管理を超えた、コンカレントオーサリング
コンカレントオーサリングという言葉自体見つかりませんでした。ただ、ココからは自分の推測なのですが、IT業界に「コンカレント・エンジニアリング」という言葉があります。
- コンカレント・エンジニアリング
狭義には、製品開発において概念設計／詳細設計／生産設計／生産準備など、各種設計および生産計画などの工程を同時並行的に行うこと。設計部門内で複数の設計者が共同作業を効率的に進めることを指す場合もある。広義にはこれを拡張して、企画・開発から販売・廃棄にいたる製品ライフサイクルの全フェイズに関連する部門が、製品の企画や開発、設計などの段階に参加・協働することをいう。
上記のゲーム開発に向けた仕組みが、ここでいう「コンカレントオーサリング」なのではないでしょうか。大規模化するプロジェクトの中で、複数の会社・部署が、一つのデータを同時並行的に扱う事で作業効率を上げようという試み。推論ですが、それがしっくり来るかなと思います。
DCC ツールとゲームランタイムとの相互乗り入れ
物凄く簡単に言うと、DCCツール上で、ゲームがそのまま動かせるという事だと思います。
上記で紹介した「三国無双online」では、Softimage（旧XSI）のカスタムディスプレイホストを使用した例があったり、ALCHEMY（アルケミー）などのミドルウェアで、GameViewerがDCCツールにインテグレーションされていたりするので、それが普及するという事かなと思います。
実際の感覚で言うと、出来たらありがたいけど、開発するのが大変そうな気がするのですが、どうなんでしょうか？MaxとかMayaとか、実機を組み込むのが地獄とかなんとか…。いや、欲しいのは欲しいので、実現できるとありがたい。
オープンコンテンツの積極的な利用
UGCの利用性を指しているんだと思いますが、オーサリング・プロダクションの項目に入っているって事は、ブログ・SNS・ニコニコ動画などのUGCコンテンツではなく、ゲーム内エディタで作成したデータのコミュニティでの共有化や、MODを使用した新たなゲーム性を持つゲームデータを利用していこう。って事でしょうか。
ゲーム内エディタで作成したデータについては「SPORE」のクリーチャークリエイターで作成した、クリーチャーデータの共有が有名ですし、「うごメモ」での作品共有も、良く取り上げられる例です。また、MOD文化については、PC環境では良く聞く話なので、詳しくは追いませんが、それらの利用がより活発化する事かもしれません。
という感じで、「ビジュアルアーツ分野/オーサリング・プロダクション」まとめてみました。
ひとまず、時間をかけてグラフィックデザイン分野は全て読み解けましたが、以前読み解いた項目でも、新たな発見で修正しないといけない所と、その読み解きこうじゃないか？とメールでご指摘いただいた項目がありますので、時間を見て、そちらの補足をしていきたいと思います。
また、今回の記事でも、限られた説明からの推論でもありますので、間違っている場合や、他に有力な見解があるようでしたら、コメントでもメールでもかまいませんので、ドシドシ突っ込んでください。
*1:CEDEC2009の講演で説明があったのですが、WEBにソースが無かったので、会社名は挙げずにおきます。
