ブログトップ 記事一覧 ログイン 無料ブログ開設

ゲームの花園 このページをアンテナに追加 RSSフィード

2012-06-22

再現:スタジオジブリさんの水彩コンポジット

7,8年前、スタジオジブリさんがWEB上で解説していた水彩コンポジットを再現してみました。当時、その解説を見ながら再現を試みたのですが、コンポジットの熟練度が低かったので完全再現出来ず放置していました。

そのシーンを久しぶりに発掘してみたら、 何となく再現が出来たので解説してみます。(当時はギブリーズ episode2公開前後で、FxTreeの前身である、Avid Media Illusionという独立したソフトを使って解説されていましたので、Avid時代のユーザー事例とかだったかな?と思います。)

この手法を使うと、普通のSphereオブジェクトが下記の様なタッチになります。

f:id:Aqu:20120619234222p:image:w640

用意する素材

今回は効果がわかりやすいように、Sphereをベースにコンポジットしていきます。まず、SphereをDiffuse・Specular・Shadow・Depth・Normal・Outlineの計6種類の要素でレンダリングします。

f:id:Aqu:20120619233712p:image:w640

水彩コンポジットの基本となる処理

次に上記の画像にエフェクトをかけては合成を繰り返し、水彩の特徴である滲みや、アウトラインから色がはみ出る表現を2D的に再現していきます。今回は、Sphere本体と影部分に色をつけたいので、下記の様なFxTreeを組みました。

f:id:Aqu:20120621233453p:image:w640

上記のレンダリング素材を使用し、基本となるコンポジットを行っていきます。今回はSphereの下地部分のコンポジットを例に手順を追っていきます。

f:id:Aqu:20120620180056p:image:w180

1, ColorCorrect(Diffuseをコントラストアップ)

f:id:Aqu:20120620145052j:image:w320

2, MathComposite(1の結果 x Specular。必要なスペキュラ要素だけ取り出す)

f:id:Aqu:20120620145054j:image:w320

3, ColorCorrect(コントラストアップ)

f:id:Aqu:20120620145055j:image:w320

4, Invert

f:id:Aqu:20120620145056j:image:w360

5, ColorCorrect(ノーマル素材のコントラストアップ)

f:id:Aqu:20120620150255p:image:w360

6, MathComposite(4の結果 x 5の結果)

f:id:Aqu:20120620145057j:image:w360

7, TurbDistor(歪める)

f:id:Aqu:20120620145058j:image:w360

8, MedianFilter(ノイズ除去目的ですが、Sphereみたいに面積が広いとあまり効果はわからないですね)

f:id:Aqu:20120620145100j:image:w360

9, Resize(スケールとポジションオフセットを行い、枠からハミ出す処理) 【素材A】

f:id:Aqu:20120620145101j:image:w360

10, FastBlur(今回は720pで30pixel位)

f:id:Aqu:20120620145102j:image:w360

11, Noise

f:id:Aqu:20120620145103j:image:w360

12, FastBlur

f:id:Aqu:20120620145105j:image:w360

13, ColorCorrect(彩度を0に)

f:id:Aqu:20120620145106j:image:w360

14, Resize(17で行う合成の目的である、光源方向の滲み表現のためのリサイズ)

f:id:Aqu:20120620145107j:image:w360

15, MathComposite(素材Aと、差で合成)

f:id:Aqu:20120620145108j:image:w360

16, Invert【素材B】

f:id:Aqu:20120620145109j:image:w360

17, MathComposite(colorと素材Aを乗算)【素材C】

f:id:Aqu:20120620145110j:image:w360

18, Composite(背景素材に対して、素材Cを、素材Dのマスクで合成)

f:id:Aqu:20120620145111j:image:w360

これで、Sphereの下地部分の完成となります。


できあがり

これらのコンポジットの流れを、Sphereの下地部分以外にも処理します。(各部位でのパラメータのバラツキは、見ながら調整)

Sphere・下地

f:id:Aqu:20120621091946p:image:w360

Sphere・液溜まり

f:id:Aqu:20120621091947p:image:w360

Sphereの影・下地

f:id:Aqu:20120621091948p:image:w360

Sphereの影・液溜まり

f:id:Aqu:20120621091949p:image:w360

そして、背景に上記素材をコンポジットしていくと完成となります。

完成した動画がこちら。

D

水彩コンポジットの応用

せっかくなのでSphereだけでなく、キャラクターにも応用してみました。

f:id:Aqu:20120622091600p:image:w640

ジブリといえば、トトロ

D

ジブリさんのコンセプトアートによる水彩画は、影部分にタッチが入っている事が多いので、よりそれっぽくするなら、タッチ表現を詰めても良いかもですね。


まとめ

今回の水彩コンポジットでポイントとなるのは、2Dベースのコンポジットで絵作りを行うということです。ゲームのキャラクターを絵的な表現を行う場合、どうしても個々のオブジェクトに割り当てるシェーダーに頼りがちですが、そうすると水彩のタッチが出せたとしても結局フィギュアの表面に、水彩絵の具で色づけしただけの表現になってしまい、画面全体で見るとどうしても絵的な見た目にはならない問題がありました。

このコンポジットの考え方を利用すると、水彩以外の絵の要素でも特性を分解し、それぞれをコンポジットで積み重ねていくと言った表現が出来るようになるかもしれません。

今年のE3を見ていると、次世代のゲームグラフィックはフォトリアルな方向に爆進中ですが、これらのNPR(スタイライズド)表現に力を入れるタイトルが出てきても面白いと思うので、その辺り期待したいですねぇ〜。

あと、上記のメイキング動画を作ろうと思ったのですが、慣れて無いこともあり挫折してしまいました…。また再挑戦してうまく出来れば公開したいと思います。それでは〜。

2012-03-11

スクリプト処理速度比較「VBS・JS・Python・C++」

先日Softimageのスクリプトの事で調べ物をしていたら、Softimageのスクリプト言語での処理速度を比較するという面白い記事を見つけました。(myaraさんのサイト、他のスクリプト記事も濃くて面白いです^^)

今までスクリプトの処理速度は気にした事が無かったので「VBS、意外と速いんやなぁ〜」と興味深く読んでました。ただこの2年間くらいはPython縛りでプラグイン作成を統一していた自分にとっては、Pythonの速度比較が気になるところです。という訳で、今回は上記記事を参考にSoftimageのスクリプト言語での速度比較をしてみました。

はじめに

題材にしたのは、上記記事にあったXSIBaseのスクリプト。処理の内容はというと、

・選択しているポリゴンオブジェクトを取得

ポリゴンオブジェクトのエッジを取得

・全てのエッジを検証。エッジに隣接しているポリゴン(neighbor polygon)が2つ以上あるか判定

・2つ以上あれば、各ポリゴンの法線ベクトルを取得

・2つのポリゴンの法線ベクトルの差が、指定した値以上であればエッジを選択

というような感じです。今回の速度計測で使用したオブジェクトは、恒例のスタンフォードドラゴンをリダクションしたものを利用しています。(そのままだと処理時間がかかりすぎたので…。)

f:id:Aqu:20120312011922p:image:w360

まずはこれをmyaraさんの記事に基づいて最適化したものをベースで利用しています。最適化の概要は「option explicitを利用した宣言の徹底」と「特定のエッジを発見した時に、その都度選択を行う処理を止め、一旦配列に保存して最後に一括選択」が大きなところです。このスクリプトで、処理時間的には下記の通りとなりました。

f:id:Aqu:20120312083941p:image:w360

スクリプト処理時間(秒)
VBScript593.6172
VBScript(最適化)7.1118

確かに速くなりました。しかもかなり!書き方でこんなに変わるものなんですね。


スクリプト毎の比較

さて、上記で最適化したVBスクリプトを他の言語にも移植していきます。今回はJスクリプトPython、あとC++dll化したものも用意してみました。どれも処理内容は同じものです。で、結果はこちら。

f:id:Aqu:20120312011924p:image:w360

スクリプト処理時間(秒)
VBScript7.1118
JScript8.7450
Python100.1579
C++1.8930

Python遅いっ!圧倒的に処理時間がかかっています。これはどういうことなんでしょう…。処理の流れは同じはずなんですが…。

そういえばC++で作ったdllプラグイン形式で、他の言語はスクリプトの直接実行なので、その辺りが影響しているのかなと思い、他の言語もプラグイン化してみました。

そして結果はこちら。

f:id:Aqu:20120312083037p:image:w360

スクリプト処理時間(秒)
VBScript7.1118 (秒)
VBScript(Plugin化)6.8593 (秒)
JScript8.7450 (秒)
JScript(Plugin化)8.5820 (秒)
Python100.1579 (秒)
Python(Plugin化)99.3639 (秒)
C++1.8930 (秒)

うぅん速くなっているようですが、体感速度的には誤差程度の差しか無かったですね・・・。(マクロ的な使い方をしていれば、体感的に速くなる印象があるので、今回みたいなエッジをforでループと言う処理内容では結果が出にくいのかもしれません。)


まとめ

というわけで、今回の比較ではPythonが遅くて、VBスクリプトが速いという結果になりました。

最近は時流に乗ってプラグイン制作では全てPythonで統一を考えていましたが、VBスクリプトを見直しました。よくよく考えるとSoftimage自体に入っているプラグイン自体の大半がVBスクリプトで書かれているので、そこで気づくべきでしたね。

Pythonの構文はシンプルで行数も少なく、アーティストには優しい言語だと思っているので、今後も使用を継続していくと思いますが、処理速度を求めるところはVBスクリプトで書くという選択肢は考えた方が良いかもですね。

あと最後に、今回使ったスクリプトC++のソースはダウンロードできる形にしています。もし「Pythonはこう書いたら速くなるよ〜。」とかヒントがあれば、ぜひコメントいただければと思います。自分もその方が助かるので…。

VBS_JS_PY_CPP.zip 直

では!

2012-02-26

「Ragdoll」開発事例〜MayaからUnityへのアプローチ〜 レポート

先日参加した「3DCGツールとUnityによるゲーム開発実践セミナー」のレポート、2つ目です。先日のSEGAさんのレポート同様、実践的で非常に濃い内容でした。こちらのレポートもGamewatchさんの記事と合わせてご覧いただくと、セミナー内容がうまく補完できるかと思います。

追記:2012年2月28日(08:00)

講師

  • 株式会社マトリックス
    • コンテンツ事業部デザイン開発
    • 主任
    • 高崎奈美

概要

2010年末からUnityを使用し開発を続けてきたノウハウと、Androidアプリ「RagDoll」開発事例

レジュメ

プロジェクト概要

  • スケジュール
    • 2010年末 企画提案
    • 2011年1月 開発スタート
  • 目標:短期間・低コスト・成果
    • 早い・安い・うまいを目指したプロジェクト

ゲームの内容

チームの目標

  • 早い
    • 早く結果を見てもらえる
    • 自社ブランドでの開発となったので、短期的に成果を見せる必要があった
  • 安い
    • 予算が少ない
  • うまい
    • やりたい事が実現できる

初期メンバー

f:id:Aqu:20120226220709j:image

※D = ディレクター、PL = プランナ、PG = プログラマGD = グラフィックデザイナー、TA = テクニカルアーティスト。

(2012年3月4日 22:40コメント欄で頂いた内容を元に修正しました。)

必要要件

  • リアルに見える
    • 編みぐるみ・ぬいぐるみを実際に触っているように感じる質感表現
  • リアルに揺れる
    • ラグドール演算
  • 自由に作れる
  • かわいい(必須

開発環境

Unityを選択した理由

  • ”速い”が実現できる
  • 予算
  • やりたい事が出来る
    • リアルに見えるという用件から、シェーダーがカスタマイズできる必要があった
    • もう一つの候補はシェーダのひな形を選択する事しか出来なかった
  • DCCツールに似たGUI
    • アーティストにも敷居が高くない

モデリング

  • Nurbsでのモデリング
    • 均一なUV
      • 編み目・縫い目が同じ幅で入り均等に表現できる
    • 版権キャラの丸みの表現
      • リテイク時の容易な対応
    • 最終的にはポリゴンに変換しエクスポート

モデルパーツの作り方

  • 全てYupで制作
    • ゲーム中に編みぐるみをエディットするため
    • 手・足などのパーツは、胴体パーツの各頂点の法線方向に向く仕組み

マテリアル

  • 全てのマテリアル設定はUnity上で行った
    • Mayaで設定したマテリアルの詳細な情報はFBXでは転送できなかった
    • Mayaではマテリアル数に分けるのみ(クラスター分け)
    • モデリングも仮のマテリアルで行った

リグ

  • キャラクター毎にカスタマイズ
    • 版権キャラクターなどの特徴的な動きを再現
    • ラグドール演算のためのデフォルトポーズが変わる場合もあるため

UI

  • 通常のUIはEZGUI、リッチなUIはMayaで制作
  • なぜEZGUIなのか?
  • Unity標準のGUIテクスチャーでの不都合
    • 複数の画面解像度・縦横比に対応が困難
      • 表示が崩れる
    • マテリアルがまとまらない
      • 同じテクスチャを利用していてもDynamic Batchingが働かずDraw Call数が増える
  • EZGUIの利点
    • オブジェクトが3D座標上にセットされる
      • 解像度・縦横比に依存されない
    • マテリアルをまとめるとDynamic Batching が働く
      • Draw Call 数軽減

テクスチャの容量削減

  • Asset Bundlesの使用
    • 特定のデータをアプリ内に持つのではなく、サーバーなどに置いておく
    • 実行中にデータをサーバに読みに行く
  • Ragdollではシーン毎にAsset Bundles を作成
    • ダウンロードしたAsset Bundles はローカルに保存
    • アプリの起動時に更新を確認し、更新があればそのデータだけをダウンロード
  • アプリの更新をする事なくデータ更新が出来る

シーン分け

  • Unityを使った共同開発ではシーンの競合が問題になる事が多い
    • Ragdollでは開発初期から気をつけていたので、大きな問題にはならなかった
  • 各場面毎に2つのシーンを用意
  • シーンを読み込んだ時に、別のシーンを追加で読み込む機能がある
    • プログラマが使うシーンに、アーティストのシーンを追加読み込みする

f:id:Aqu:20120226221005j:image:w360

  • 対策
    • アーティストはPrefabをシーンに置くのをやめる
      • Prefabの用意までをアーティストの作業とする
    • プログラマはシーンの追加読み込みではなく、Prefabを直に読み込むように変更

f:id:Aqu:20120226221442j:image:w360

ライティング

  • Unityスマートフォンでは、シャドウマップをサポートしていない
    • Blob Shadow Projector での丸影実装が現実的
    • パフォーマンスも申し分ない
  • Pixel Light Count の最適化
    • ライティングの負荷が高い場合Pixel Light Count を減らす
      • 大幅な処理負荷減
    • Rag Dollでは、ノーマルマップの見え方の違いもほとんど影響なし

MayaからUnityへのデータ渡し

モデル・アニメーションデータの持ち方

  • アニメーションデータにメッシュを持っていると、うまく行かなかった
    • メッシュを付けず、Locatorをつけると解決できた

f:id:Aqu:20120226220822j:image:w360

アニメーションデータの容量削減

※Gamewatchの記事のプレゼン資料が詳しいです

  • データを更新する毎に上記作業をするのは面倒
    • Asset Post Processorクラスの関数を利用し自動化した

MayaUnity以外のツール

  • パラメータの編集にExcelを使用
    • プランナーはUnityを使用していなかったため
      • プランナーがUnityを使う場合は、パラメータを拡張して使ってもらう方が良いと思う
      • Unityだけで完結できるし
  • バージョン管理はSubversion
    • 1.6以前
      • 各フォルダに隠しフォルダで管理フォルダが作られる
      • Unity上でフォルダを複製すると、管理フォルダ毎に複製され不具合が発生する
    • 1.7以降
      • チェックアウトフォルダのみに管理フォルダが作られるようになった
      • Unityでも使いやすくなった

UnityMayaへの要望(Ragdoll開発で感じた両ソフトの強化要望)

  • 受け渡しフォーマットの強化
  • Asset Bundlesのバージョン互換性
    • Unityのバージョン違いでAsset Bundlesが読めない問題を解決
    • Ragdoll開発中に何度か泣かされた
      • 3.5から機能が拡張されたが、モバイルプラットフォームでは利用できない

Unityを使って良かったところ

  • 開発力・チーム力の向上
    • すぐに絵が出るので、レビューを受けやすくなった
    • ゲームを見ながら、あーでもないこーでもないと意見を交わせる
  • 実装までの速度UP
  • コミュニティ
    • コンシューマー開発環境に比べると、開発環境・ノウハウについての情報が多い
    • FacebookのUnity助け合い所に業務中に書き込んで、解決する事もあった

Unityを使って良くなかったところ

  • Unityで何でも出来るわけではない
    • 自動化ゆえの不具合
    • Unity自身の向き・不向き
      • プロジェクトに必要な遊び・表現ができない事も
  • お金を動かす人は「すぐできるんでしょ?」「お安く買えるんでしょ?」と言いがち
    • それを開発側はそのまま受け入れるのではなく、やりたい事とUnityを使う事の相性は見極めないとダメ
  • Ragdollでは早い・安い・うまいを全て達成できていない
    • 特に早いに関しては達成できていない
    • プロトタイプまでは早かった
    • ただプロトタイプからリリースまでにはバグ対応・やりたい事が出来ないなど、いくつか障害があった

まとめ

  • Unityは画材。作りたいものが明確でUnityに最適な内容であれば問題なく使っても良いと思う

FAQ

Q,他のセミナーに参加時に聞いた話で、EZGUIの中にバグ(ボタンの押下時のタイミング)があるらしいがRagdollではその辺りどうだったか?そのセミナーでの解決法はEZGUIの中身を見て、バグ取りをしたという事だった。
  • A,同様のバグが出て、一部中身を編集して直した。
    • ただ大きな問題にはならなかった。
Q,EZGUIで制作したGUIと、Mayaで制作したGUIの切り分けはどのようにやっていたか?

以上。

2012-02-23

「UnityでiPhone向け3Dゲームを作る」レポート

本日「3DCGツールとUnityによるゲーム開発実践セミナー」に参加してきました。

そこで講演されたセガさんのUnityを使ったiPhoneアプリのグラフィックの最適化の話が、大変濃かったのでレポートします。

2012 / 02 / 24 07:40 追記

Game Watchさんにレポートが上がりました。写真が豊富でわかりやすいです!

http://game.watch.impress.co.jp/docs/news/20120223_514183.html


講師

概要

  • セガさんで走っている、Unityを使ったiPhoneアプリのプロジェクトから出てきた、グラフィック最適化のノウハウの総括

レジュメ

環境

  • Maya 2012
  • Unity3.5
  • iPhone4(4Sではない)
    • 4で30fpsを保てれば、4S・iPad2では60fps出るくらいの感覚

はじめに

  • Unityのマニュアルに書いてある事は正しい
    • ただし具体例がちょっと少ない
    • マニュアル自体、iPhone3をベースに書かれているので少し古い

iPhone4の特徴

大きなサイズのテクスチャが使える!沢山?
  • ライトマップが普通に使える
  • むしろ頂点カラーに焼くのが駄目
    • 頂点カラーのシェーダ自体が無い
    • しかも作っても遅かった
  • レイヤーテクスチャよりも1枚のテクスチャ
  • テクスチャ設定のAniso Level(異方性フィルタ)を上げても、ほとんどコストがかからない
    • そもそもMipmapの設定が無いのでAniso Levelで調整
    • ライトマップを焼くと、デフォルトで「3」が入る。
    • 「6」くらいにしてもほとんど描画コストが変わらない
Retinaディスプレイ

最適化

  • どのくらい重い?
    • Draw Call : 200以上
      • 15fps 近辺
    • Draw Call : 100以上
      • 30fps
    • Draw Call : 50あたり
      • 60fps
  • メッシュの確認方法
  • 「In Summary Combine, Combine, Combine…」
    • マニュアルの中で太字で書かれている一文
    • ハイエンド向けのTipsとして書かれているが、まとめればまとめるだけiPhone4上でも速くなる
      • Draw Callが減る
  • ただし、アーティストが管理しにくくなってしまうと問題
  • 頂点数
    • マニュアル通り、50000頂点くらいが望ましい
    • "Tris(ポリゴン)"ではなく、"Verts(頂点数)"が重要
    • Hard Edgeを使うと、ポリゴンが分けられ、頂点数が増えてしまう
    • Normal Mapを利用するモデルならば法線の情報が焼かれているので、全てソフトエッジにした方が良い
  • またライトマップを焼き付けた後のポリゴンメッシュは”Normal”のパラメータを"None"にして法線を破棄すると、少しパフォーマンスが上がる
何が処理を重くするのか?
  • リアルタイムライティング
    • 描画面積が小さければ問題ない
  • フォグは重くなる?
    • 使っても問題ない
    • iPhone3時代の話?iPhone4では問題にならない
    • それよりも、無いと絵作りが破綻する
      • またフォグを利用しつつ、距離でカリングをする事も重要
  • フィルレートが低い
    • フィルレートが高かったハードには出会った事ないが・・・。
    • 半透明は相変わらず危険!
    • 面積がそれほど大きくなければ、エフェクトは結構出る
    • パンチスルー(cut out シェーダー)が重い
    • アルファテスト苦手
処理を速くするための対処
  • まずはカリング
    • 表示しないのが一番
    • カメラの視錐体でカリング
    • 3.5から入ったLODも使える
    • 距離に応じてカリングする処理をスクリプトで実装
    • ゲームデザインでの工夫
      • 一直線で遠方まで見渡せる地形を極力避ける
      • 壁を設け、視線を遮る
  • スキニングオブジェクトを少なく
    • ジョイント数も少なく
    • ただし、動く親子構造のメッシュより、スキニングのメッシュが良い事もある
    • 例:クレーンなどの機械的なオブジェクトで、土台・アーム1・アーム2・爪本体・爪(右)・爪(左)などを分けてアニメーションさせると、Draw Callが「6」かかる
    • Draw Call 100以下を目指す時に「6」取られるのは危険。10個配置すると「60
    • そういう場合はスキニングして1メッシュ化する方が高速。Draw Callが「1
  • 1Skin Cluster, 1マテリアルが理想
    • コンバイン、コンバイン、コンバイン
  • ライトマップは低ポリゴンに都合が良い
    • 地形(Terrain)に家などをブッ刺しても、ライトマップは良い感じに焼けてくれる
      • 頂点カラーに焼く場合は、頂点の流れを考慮しないと行けなかったが
    • 大きなテクスチャが使える事と相性が良い
  • Unity標準のスカイボックスに問題がある
    • テクスチャの圧縮が汚い
    • 立方体でレンダリングするのでDraw Call が「」かかる
    • 従来ながらの半球(全球)が効率が良い
      • Far Clip問題
      • 半球用のカメラを用意し、半球を写しておけば、Far Clipで消え無いようにできる
  • 出来るだけまとめる
    • 配置されている同一オブジェクトは出来る限りまとめる
    • 半透明を使っているオブジェクトは、ソートで問題が出る場合がある
      • ソートはオブジェクトのセンターから行われる
      • レイヤーが見ない方向に留意しセンター位置を編集
      • 360度見る可能性があればまとめないのも手
iPhone4を大まかにまとめる
  • iPhone4以降のモデルなら、ひとまず3Dモデルを表示してしまう
  • 最適化は常識的な範囲で行えば十分!

ドンドン出してみれば良いのだ

シーンの管理

f:id:Aqu:20120224003138j:image:w360

エディター・エンジンとは何なのか?

  • 効率アップには絶対に重要な事
    • 繰り返し試せる
    • 作業中と最終結果の見た目が同じであればあるほど良い
    • 似た作業は同じ様に出来る
  • これらの事はコンテンツ工学で決まっている
コンテンツ工学の現状

f:id:Aqu:20120224005034j:image:w360

  • 日本の開発には、コンテンツ工学の部分が抜けている
    • なんとなくツールを使ってそれなりのデータを作成は出来るが、効率的ではない

コンテンツ工学

    • 職人技を一般化。誰でも出来るように
      • 勘に頼る部分を数値化
      • 実際にどういうテクノロジーなのか、どういう手順なのか調べる
      • 客観的な分析
      • 学びやすいように体系的な情報にする
    • これらを工学面でまとめ、コンテンツに応用したもの
  • ゲームに置けるアーティストやプログラマの行っている作業をどうしたら効率が良くなるかを考えて、考えて、考えたものがゲームエンジン

おすすめ書籍

  • 映像コンテンツの作り方:コンテンツ工学の基礎
映像コンテンツの作り方―コンテンツ工学の基礎

映像コンテンツの作り方―コンテンツ工学の基礎

餅は餅屋で

  • Unityには様々なミドルウェアが内包されている
  • 専門部分は専門家に任せて、日本人には日本人の得意分野で戦えば、まだまだいけるはず

以上。

2011-09-16

AUJ2011 Dragon's Dogma ゲーム開発事例 レポート

昨日に続いて Doragon's Dogma ( 以下 DD )の開発事例のレポートです。講演冒頭 TGS2011 で発表されたティザームービーが流されました。

2011/09/20 09:00

D

概要

  • DD 内のアニメーションは、標準体型( 男・女 )のキャラクターで全て制作されている
    • 主人公キャラのエディットへの対応・400種類を越えるNPCへの対応
    • フェイシャル・ボディとも標準体型からの、リターゲッティング
    • Softimage上で組んだエディットシステムをベースに、実機へ移植している

講師

  • 株式会社カプコン
    • ディレクティング室 ディレクター
    • 柳原 孝安 氏

セッションサイト


インゲームでのキャラクタエディット説明

MTフレームワーク上でのキャラクターエディットツールの紹介。

下記動画はインゲームのものですが、編集イメージは近いと思います。

D


体型
  • 身長
  • 頭の大きさ
  • 手・足・胴体の長さ
  • 手・足・胴体の太さ
    • スケール XYZ
  • 足の幅(付け根)
  • 特定部位の誇張
    • 腹を出す・胸を大きく
  • 胸位置の変更
    • 乳首の位置を左右に広げたり

エディット出来る範囲は、ストッパーが設けられており制限がある

    • 目全体の大きさ・角度
    • 黒目の大きさは別で調整
    • 左右別々にカラー変更 ( オッドアイも可能 )
    • カラー変更

  • まつげ
    • 長さ
  • 顎( アゴ )
    • 細い・太いあご
    • ケツあごも可能
    • 大きさ
  • その他
    • 顔の下半分を伸ばしたり・縮めたり
      • イメージ的には、クシャおじさん・帝都大戦:加藤
  • 髪型
    • 数十種類のパーツを用意
    • カラー変更
    • エディットした頭の形に沿う
  • ヒゲ
    • パーツ
    • カラーエディット
    • 顎のエディットに沿う
  • 化粧・タトゥー・民族的なボディペイント
    • テクスチャのパターンを用意
    • アイライン
    • カラーエディット
      • パターンを選んだ後色替え
  • エディット補助機能
    • 顔の骨 : 70〜80本
      • それらを一つずつ動かして、顔の編集を行うのは困難
    • 補助機能 : ミラーリング
      • 左右別々でも可能。
      • 独眼なども作れる
    • 補助機能 : 簡易リグ
      • 骨を動かしたら、周りの骨も動く
      • 唇をいじると、頬の肉も連動
      • 目をいじると、頬骨が連動など

ノーマルマップのブレンド
  • 筋肉質 <-> 凹凸が無い ( 脂肪が乗っている )
    • ボディのノーマルマップの強弱で調整
  • 若い <-> 老いている
    • 顔のノーマルマップの強弱で調整
  • 顔は年齢。体は筋肉量。
    • メモリの関係上割り切ったが、必要十分だと考えている
エンベロープの最適化
  • 全ての編集を終え"決定"ボタンを押すと、エンベロープを一体化する
    • エディット専用骨を削減:250本 → 170本
    • 実機上で行う (PS3 / XBOX360)
      • 上記動画(1分50秒辺り)のエディット決定後に行っているものと思われます。

Softimage と 実機へのエディットデータの相互利用について

  • MTフレームワーク上で動作する、キャラクターエディットツールの試作はまずSoftimage上で行った。
    • Softimage上でシミュレートした計算式を、MTフレームワーク上に移植
    • 実機ではIKを使っているので、肘・膝の位置変更はしなかった
  • Softimageでエディットしたものと、MTフレームワークでエディットしたものは同じ結果になる
    • 編集したファイルは .xml ファイルで保存しておく
    • 作業がプランナでも行えるようになった

f:id:Aqu:20110917013302p:image


エディット後のキャラクターにも使い回せる、アニメーションの管理方法

  • 体・顔とも、標準体型( 標準くん )でアニメーションを制作
    • エディット( 体型・フェイシャル )キャラでも使い回しできる
    • 標準体型より目が細いキャラクタにエディットしても、まぶた同士がめり込まない
      • 元の標準顔からの変形値を常に持っており、アニメーションデータに掛け算して再計算


フェイシャルキャプチャ
  • カットインイベントにおいて、フェイシャルキャプチャを使用
    • フェイシャルキャプチャーデータを標準顔にセットアップ
    • そのままでは、アクターと、インゲームキャラの顔の形状が違いすぎる
      • 初期位置の差分をオフセット
      • マーカのトランスレーションだけを利用する
    • アクターの表情の強弱については、顔の部位毎に係数を掛け算
      • 強弱をコントロール ( FaceRobot の Tune のイメージ)

NPC の膨大な数のリップシンクデータの自動生成

  • 今回のセリフ量は150万文字
    • 全てをフェイシャルキャプチャー不可能
  • MTフレームワーク上で音声ファイルからアニメーション作成
    • BATファイルでの処理が可能。帰宅時に走らせておけば、翌日出来ている

アニメーションの使い回し
  • 歩いているアニメーション中に、スケールをかけるデモ
    • スケールしても足がすべらない
    • 大きいキャラは歩幅が大きいので移動距離が長い。逆も然り。

モーションフィルタ
  • 一つのモーションにバリエーションをつける計算式を開発
    • 男らしい <---> 女らしい
    • 猫背 <---> 背を逸らす ( 太った人 )
    • 疲れた <---> 元気
      • これらをパラメトリックに変更できる
  • 男らしさ・女らしさとは?
    • 単純にガニ股・内股にしても違和感が残る
    • 男らしさとは、任侠映画のイメージ
      • 上半身の動きを抑える
      • 腕の振りを大きくする
      • 腰を落とす
    • 女らしさとは、スーパーモデルのイメージ
      • 鎖骨の動きを大きくする
      • 腰のひねり・横移動を大きくする
  • イメージ優先!

  • モーションブレンドでも同じ事が出来るじゃないか。と言われた事があった
    • 確かに、参照するデータを用意すれば可能ではある
    • ただ、参照するデータ全ての準備・調整などを考えると作業があふれる
  • またベースモーションに変更が生じたら、全てモーションを修正しないといけない
    • アクションゲームなので「ジャンプまで、3f伸ばして」などは開発終盤まで起こる
    • モーションブレンドでは、修正作業が膨大になる

キャラクターエディットできる主人公の体型変更による特殊なイベントツールの説明

  • 注視点と、カメラの位置を変える
    • キャラクターエディットしたキャラクターでも見きれない・めり込まない
      • 注視点は極力ターゲットを見たまま
      • カメラの位置はキャラのエディットを反映
  • 210cmのキャラならカメラも見下ろす。140cmなら見上げるなど大きさにあった演出となる

以上。