「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
講師
- 株式会社SEGA
- チーフデザイナー
- 築島智之
レジュメ
- iPhone4で3Dを快適に動かす方法
- iPhone4の特徴
- 最適化の方法
- シーンの管理方法
- ゲームエンジンとコンテンツ工学
環境
- Maya 2012
- Unity3.5
- iPhone4(4Sではない)
- 4で30fpsを保てれば、4S・iPad2では60fps出るくらいの感覚
はじめに
- Unityのマニュアルに書いてある事は正しい
- ただし具体例がちょっと少ない
- マニュアル自体、iPhone3をベースに書かれているので少し古い
iPhone4の特徴
大きなサイズのテクスチャが使える！沢山？
- ライトマップが普通に使える
- むしろ頂点カラーに焼くのが駄目
- 頂点カラーのシェーダ自体が無い
- しかも作っても遅かった
- レイヤーテクスチャよりも1枚のテクスチャ
- テクスチャ設定のAniso Level(異方性フィルタ)を上げても、ほとんどコストがかからない
- そもそもMipmapの設定が無いのでAniso Levelで調整
- ライトマップを焼くと、デフォルトで「3」が入る。
- 「6」くらいにしてもほとんど描画コストが変わらない
Retinaディスプレイ
- アンチエイリアシングしなくても綺麗
- ほとんどドットがわからない
- Unity上でちょっとボケたテクスチャでも、iPhone4上では綺麗に見えるレベル
- 逆に言うと、Unity上で綺麗に見えているテクスチャは豪華すぎる可能性もある
最適化
- 注意すべきはDraw Call数
- マテリアル数を少なくする
- テクスチャ数を少なくする
- アトラス
- テクスチャをまとめる
- Batch数
- メッシュの確認方法
- Unity上でオブジェクトメッシュを選択すると、オブジェクト毎の形状がサムネイル（右下）で見れる
- ゲームを再生した状態で同じ項目を見ると「Combined Mesh」となり、実際にまとめられたオブジェクトが確認できる
- 「In Summary Combine, Combine, Combine…」
- マニュアルの中で太字で書かれている一文
- ハイエンド向けのTipsとして書かれているが、まとめればまとめるだけiPhone4上でも速くなる
- Draw Callが減る
- ただし、アーティストが管理しにくくなってしまうと問題
- 従来通りMayaでレイアウトする方が良いかも
- 頂点数
- マニュアル通り、50000頂点くらいが望ましい
- "Tris(ポリゴン)"ではなく、"Verts(頂点数)"が重要
- Hard Edgeを使うと、ポリゴンが分けられ、頂点数が増えてしまう
- Normal Mapを利用するモデルならば法線の情報が焼かれているので、全てソフトエッジにした方が良い
- またライトマップを焼き付けた後のポリゴンメッシュは”Normal”のパラメータを"None"にして法線を破棄すると、少しパフォーマンスが上がる
何が処理を重くするのか？
- リアルタイムライティング
- 描画面積が小さければ問題ない
- 多くのテクスチャを参照している
- 3枚以上は重い
- レイヤーテクスチャより、むしろ大きい1枚テクスチャ
- カラー・スペキュラなどを分けて使うとパフォーマンスが下がる
- Unityの標準のテクスチャでは、カラーのα成分にスペキュラが入っている
- 極力枚数を減らす
- フォグは重くなる？
- 使っても問題ない
- iPhone3時代の話？iPhone4では問題にならない
- それよりも、無いと絵作りが破綻する
- またフォグを利用しつつ、距離でカリングをする事も重要
- フィルレートが低い
- フィルレートが高かったハードには出会った事ないが・・・。
- 半透明は相変わらず危険！
- 面積がそれほど大きくなければ、エフェクトは結構出る
- パンチスルー(cut out シェーダー)が重い
- アルファテスト苦手
処理を速くするための対処
- まずはカリング
- スキニングオブジェクトを少なく
- ジョイント数も少なく
- ただし、動く親子構造のメッシュより、スキニングのメッシュが良い事もある
- 例：クレーンなどの機械的なオブジェクトで、土台・アーム１・アーム２・爪本体・爪（右）・爪（左）などを分けてアニメーションさせると、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モデルを表示してしまう
- 最適化は常識的な範囲で行えば十分！
- テクスチャを大きくできる点を活かす
ドンドン出してみれば良いのだ
エディター・エンジンとは何なのか？
- 効率アップには絶対に重要な事
- 繰り返し試せる
- 作業中と最終結果の見た目が同じであればあるほど良い
- 似た作業は同じ様に出来る
- これらの事はコンテンツ工学で決まっている
コンテンツ工学の現状
- 日本の開発には、コンテンツ工学の部分が抜けている
- なんとなくツールを使ってそれなりのデータを作成は出来るが、効率的ではない
コンテンツ工学
おすすめ書籍
- 映像コンテンツの作り方：コンテンツ工学の基礎
- 作者: 金子満
- 出版社/メーカー: ボーンデジタル
- 発売日: 2007/04/01
- メディア: 単行本
- 購入: 16人 クリック: 223回
- この商品を含むブログ (5件) を見る
餅は餅屋で
- Unityには様々なミドルウェアが内包されている
- 専門部分は専門家に任せて、日本人には日本人の得意分野で戦えば、まだまだいけるはず
以上。
AUJ2011 Dragon's Dogma ゲーム開発事例 レポート
昨日に続いて Doragon's Dogma ( 以下 DD )の開発事例のレポートです。講演冒頭 TGS2011 で発表されたティザームービーが流されました。
2011/09/20 09:00
- 4Gamerにも記事がアップされました。ツール画像も掲載されていますので、あわせて御覧ください。
概要
講師
- 株式会社カプコン
- ディレクティング室 ディレクター
- 柳原 孝安 氏
インゲームでのキャラクタエディット説明
MTフレームワーク上でのキャラクターエディットツールの紹介。
下記動画はインゲームのものですが、編集イメージは近いと思います。体型
- 身長
- 頭の大きさ
- 手・足・胴体の長さ
- 手・足・胴体の太さ
- スケール XYZ
- 足の幅(付け根)
- 特定部位の誇張
- 腹を出す・胸を大きく
- 胸位置の変更
- 乳首の位置を左右に広げたり
エディット出来る範囲は、ストッパーが設けられており制限がある
顔
- 眉毛
- 移動
- テクスチャのUV値の変更
- 目
- 目全体の大きさ・角度
- 黒目の大きさは別で調整
- 左右別々にカラー変更 ( オッドアイも可能 )
- 肌
- カラー変更
- まつげ
- 長さ
- 口
- 顎( アゴ )
- 細い・太いあご
- ケツあごも可能
- 頭
- 大きさ
- その他
- 顔の下半分を伸ばしたり・縮めたり
- イメージ的には、クシャおじさん・帝都大戦：加藤
- 髪型
- 数十種類のパーツを用意
- シミュレーション用の骨仕込み済み
- パーツ毎の大きな変更はできない
- カラー変更
- エディットした頭の形に沿う
- ヒゲ
- パーツ
- カラーエディット
- 顎のエディットに沿う
- 傷・ホクロ
- テクスチャのパターンを用意
- テクスチャデカール
- 顔にも体にも貼れる
- 化粧・タトゥー・民族的なボディペイント
- テクスチャのパターンを用意
- アイライン
- カラーエディット
- パターンを選んだ後色替え
- エディット補助機能
- 顔の骨 : 70〜80本
- それらを一つずつ動かして、顔の編集を行うのは困難
- 補助機能 : ミラーリング
- 左右別々でも可能。
- 独眼なども作れる
- 補助機能 : 簡易リグ
- 骨を動かしたら、周りの骨も動く
- 唇をいじると、頬の肉も連動
- 目をいじると、頬骨が連動など
ノーマルマップのブレンド
- 筋肉質 <-> 凹凸が無い ( 脂肪が乗っている )
- ボディのノーマルマップの強弱で調整
- 若い <-> 老いている
- 顔のノーマルマップの強弱で調整
- 顔は年齢。体は筋肉量。
- メモリの関係上割り切ったが、必要十分だと考えている
エディット後のキャラクターにも使い回せる、アニメーションの管理方法
- 体・顔とも、標準体型( 標準くん )でアニメーションを制作
- エディット( 体型・フェイシャル )キャラでも使い回しできる
- 標準体型より目が細いキャラクタにエディットしても、まぶた同士がめり込まない
- 元の標準顔からの変形値を常に持っており、アニメーションデータに掛け算して再計算
- キャラクターデザインが決まらず、アニメーションがつけれない状態がなくなる
- 標準体型でアニメーションを制作すれば、エディット後の動きは保証する
- DDに登場する主人公・NPCは全て標準体型でアニメーション制作されている
フェイシャルキャプチャ
- カットインイベントにおいて、フェイシャルキャプチャを使用
- フェイシャルキャプチャーデータを標準顔にセットアップ
- そのままでは、アクターと、インゲームキャラの顔の形状が違いすぎる
- 初期位置の差分をオフセット
- マーカのトランスレーションだけを利用する
- アクターの表情の強弱については、顔の部位毎に係数を掛け算
- 強弱をコントロール ( FaceRobot の Tune のイメージ)
NPC の膨大な数のリップシンクデータの自動生成
- 今回のセリフ量は150万文字
- 全てをフェイシャルキャプチャー不可能
- MTフレームワーク上で音声ファイルからアニメーション作成
- BATファイルでの処理が可能。帰宅時に走らせておけば、翌日出来ている
アニメーションの使い回し
- 歩いているアニメーション中に、スケールをかけるデモ
- スケールしても足がすべらない
- 大きいキャラは歩幅が大きいので移動距離が長い。逆も然り。
以上。
AUJ2011「Transformers Prime」制作事例 レポート
2011/09/16 22:00
- 書き忘れていた「Asset と Shot」という考えを追記
本日、Autodesk University 2011に参加してきました。
そこでポリゴン・ピクチュアズ(以下、PPI)さんが講演された社内制作環境の考え方が学ぶ所が多かったのでレポートします。
PPI
- 1983年設立
- 350名前後 ( 60人強が外国人 )
- 映画・TVシリーズ・ゲームのティザー映像などを制作している
- 基本、分業制。
- 分業制はメリット・デメリットあるが、規模を活かす動きを取りやすい
- 国際的。日本のみならず、海外からの受注も多い
- 売り上げは、国内が3割、海外が7割
- タイ・マレーシア・中国にもAsset制作を依頼している。
- インドも少し。
Transformers Prime とは
- インターナショナルな配信を前提とした、大型TVシリーズ
- フルCG
- 第一シリーズ 26話 x 22分
- 制作会社 Husbro Studio
- Hub チャンネルで放映
Asset と Shot という考え
Asset
- シリーズ全体を創り上げるために必要な、基本的な素材
- Model・Texture・Shader・Rig・Display
Shot
- エピソードを創り上げるための専用素材
- Layout・Animation・Effect・Lighting・Composite
- 使い回しは難しい
外部・内部での膨大なトラフィック
- 情報共有フローの改善
- メールによるコミュニケーション
- Excelによる情報集約からの脱却
プロジェクトWiki
- 静的な情報共有の場。既に決まっているものを集約する場所
- 今までは口伝でやっていた所
- プロダクションの情報をまとめる。
制作管理データベース
- 動的な情報の蓄積
- 制作したAsset / Shotの情報を集約
- このAssetは誰が作った・何処で使われている
- このShotで使われているAsset
- 最初は評判が悪かったが、バージョンアップを繰り返し現在はかなりの信頼を得ている。
- もうTransformer Primeシリーズでは無くてはならない
タスク受発注チケットシステム : Redmine
スーパーバイザー・ディレクターによるレビューの高速化
- 作業の中で"画"を作っている時間は短い
- 一番時間を取られるのが、チェックでのやり取り。
- PPIテイクサブミッションツールの開発
- チェック用のAEで作って、スーパーバイザーにお伺いを立ててチェックしてもらう工程をなくす。
- 所定のスレッドへジョブをなげ、データベースにその旨を記入。
- レビュー用に "RV"という再生ツールで行われる
大量生産可能な制作体制
ディレクトリ構造の改革
- 大元のフォルダをユーザーで分けるのでは無く「Asset」と「Shot」で分ける
大別層 エピソード・カテゴリ シークエンス ショット 目的別 デパートメント ユーザ アプリケーション アプリプロジェクト層
ルックデブ (Look Dev) ステージの導入
- 今まではシェーダを作る人が居なかった
- ライティングの過程で、シェーダとライティングが調整されていた
- 結果、ショット毎にシェーダが変わっていた
- Look Devでのシェーダー管理の一元化
Beauty Pass方式
- 一発レンダー。
- マルチパスに分け、コンポジットでの合成をやめる
- 素材管理の手間と、品質のばらつきを抑える
- ショット毎のバラつきを無くす
- 見た目は、Look Devが保証したものがでる
PPI レンダーシーンマネージャの導入
- 新しいShotシーンを始める時に、モデルを読み込んで、ライトを読み込んで・・・、という手間を省く
- Mayaシーンのテンプレート化・アラカルト化
- Mayaライティングシーンセットアップ時間を短縮
コンポジットを After Effects から NUKE へ移行
- NUKEを使えば素晴らしいクオリティが！ではなく、効率化のため。
- ノードベースのコンポジット
- テンプレート化しやすい
- 一目でわかる
- テンプレートとギズモ、をスクリプティングでゴニョゴニョしている(書き取れませんでした・・・。）
- 「他人の作った After Effets シーンを渡されて、パッとみてわかります？」
マットペイントの最大活用
- 今までの PPI ではあまりなかった。
- 今回からマットペイントデパートメントを作って、メンバーを集めた。
- マットペイントに置き換える所
- 3Dで作っても費用対効果に見合わない遠景
- 一瞬しか映らないもの
- 背景制作にかかるコストを削減
SMOKEによる、ポストプロセスの高速化・高度化
- リテイクを3Dステージに戻さないために導入
- 3Dのメンバーは次の作業を行っているので、そのまま戻すとボトルネックになる
- SMOKEをいれて、期待以上の効果が出た
- 現状はSMOKE使いは一人。それでも回っている。
- 今後アシスタントを一人増やそうかと検討している。
- 「お金があるなら入れた方が良い。非常にオススメ！」
ステージの完全分業
- ステージの完全分業ということで、モデラー・アニメータ・リガーなどをステージ(セクション)で分かれている。
- その中でも、特に特殊なステージ「Electric Display」「変形」の紹介
Electric Display
- SF世界・基地に登場するモニターに映る映像を制作するメンバー
- 現状：3人
所感
業界も会社の文化も違うので、そのまま取り入れて効果が出る部分は少ない。ただ、自社の環境と作るタイトルから導き出した制作環境を作るまでの道のりは学ばないといけない所。早速自プロジェクトでも、再度非効率な点を洗い出し、改善に向けて動いてみる。(会社のレポートみたいな…。)
CEDEC 2010「ネットワークゲーム開発における構成管理ソフトの活用方法」
今回はSEGAさんのPERFORCEの導入事例のセッションをレポートします。
ネットワークゲームのデータ管理の複雑さと、PERFORCEとその他のソフト(静的解析・BTS・自動ビルド)との連携などなかなか興味深かったです。
ではレポートです。
なぜ構成管理ソフトを導入するのか？
導入のきっかけ
- セガ・マークIII、メガドライブなどで発売されたファンタシスターシリーズ
- 2006年に運営が開始された PHANTASY STAR UNIVERSEで起きたトラブルから導入が検討
- 以降のソフトで採用されることとなった
構成管理ソフトとは？
- バージョン管理ソフトと、構成管理ソフトとどこが違うのか？
- 成果物の制御や変更管理・ワークフロー管理なども行う
- ビルド環境の構築のコアとなるツール
- プログラムのソース・デザインデータ・企画パラメーターなども一括管理
- デイリービルドも行える
- 成果物の状態を把握し、任意のバージョンを再現可能とする
- 日付を指定しての再現・バグのない状態への巻き戻りも容易にできる
通常のゲームのタイムライン
ネットワーク開発において
- ゴールは一つではない(運営が終了するまで)
- しかも同時に別の道を走らなければならない
- しかも、同時に別の道を走らなければ
- それも"全力疾走で"
ネットワークゲームのタイムライン
構成管理ソフトの再検討
- 継続的なインテグレーション環境
- ビルドとテストを自動で行う環境の構築
- バグを減らすためのツールの導入
- 作業タスクの把握と変更管理
- チェック体制の見直しとツールでの補完
要求
- ブランチとマージ機能の充実
- 修正項目の把握と管理ができる
- 速くて軽くて簡単に扱える
- 他のツールとの連動ができる
- BTS・静的解析・タスク管理ソフトとの連携
選定候補
- PERFORCE
- AlienBrain
- データが大きくなりがち
- 全体的に処理が重い
- ブランチ・マージの機能が求めるレベルではなかった
- アーティストが使うデータ(画像など)のビューアが充実している
- アーティスト間のデータのやり取りには使われている
- Subversion
- データが増えると重くなる
- バイナリデータの扱いが苦手
- ブランチの機能が弱い
- ファイルを丸々コピーしてしまう
- ".svn"フォルダが生成されてしまう
- そのまま360のデータフォルダに入って問題になったことも
- ※セッション後に聞いた話では、Gitなどでもビューアや、GUIツールが対応されれば、全然使えるような事も言われていました。
PERFORCE 決定理由
- 軽い・速い
- 採用理由の大半がここ
- 40GBのデータを1回でコミット出来たのは、PERFORCEだけ
- 他のソフトは途中で止まる
- 分割してコミットするなどして、対応しないといけない
- Linuxでも、Windowsでも使える
- サーバのセッティングと管理が楽
- ブランチの機能が強力
- GUIのクライアントが存在する
- ソースとデータを同一に管理できる
- 日本語対応されている
- サポートが受けられる
- 社内でサポートする必要が減る
運用
活用
- 並列作業となるパッチ作成に活用
- ローカライズ対応
- 他機種への移植
- ゲームショーなどのプレゼンROMの対応
Tips
- サブミットする単位は一つの変更毎に行う
- サブミットコメントのフォーマットを揃える
- ブランチするタイミングを見極める
- ブランチのブランチは作らない(メインラインパターン)
- Excelとの差分が取れないので、インハウスツールを作って対応する
利点
要望
開発環境の紹介
- Hudsonを使って、継続的インテグレーション環境の構築
- 日本語環境に対応している
- PERFORCEのプラグインがあった
- 常時サブミットを監視してビルドを行う
- 専用PCを設置、自動ビルドを行う
- 出来たものは成果物として、サーバにアップする
- バージョンを指定しての成果物作成が可能
- 以前のバージョン・日付を指定して再現することが出来る
- IRCを使ってビルドの要求と結果の通知
- 静的解析ツールとの連動
- 毎晩、静的解析ツールを回している
- 毎朝、引っかかった部分は各自の所に結果が届く
- タスク管理システムやBTSとの連動
まとめ
- リリースに必要なファイルは全て管理しよう
- アーティスト・プランナにも使いやすい環境を整備しよう
- 変更管理をしっかりしよう
- 様々なツールを連動させよう
- より良い環境になるように、みんなで工夫しよう
ひとまず、これでニュースサイトに上がっていないセッションのレポートは、いくつか補完できたでしょうか。もうそろそろCEDECアーカイブが公開されるはず(?)なので、それまでの繋ぎ情報になると思いますが、活用していただけるとありがたいです。
あとマズい情報など載っけてしまった時は、お手数ですがご連絡ください。すぐに対処させていただきます。
では。
CEDEC 2010「Q-Games流アジャイル開発手法：PixelJunk での実践例を紹介」
今回はQ-Gamesさんのアジャイル開発手法のセッションまとめます。
このセッションでは、Q-Gamesさんが開発手法としてアジャイルを取り入れた経緯と、取り入れた後の問題点を紹介しており、その変遷での試行錯誤の内容に共感出来るところが多かったです。う〜ん、うちもあるなぁと…。
ではレポートです。
概要
Q-gamesの開発スタイル
問題点
- 当初の仕様や計画通りには進みにくい？
- ただし、実際に遊んで感じた結果の方が重要
- 無駄な実装が多くなる傾向？
- 面白くなるためには、無駄も必要なプロセス
アジャイル開発の試みと必然性
→元々アジャイルを導入する土壌があった
Mantisの特徴
- 無料
- 処理が高速
- 検索条件が多様(絞り込み)
- セキュリティが高い
- ロードマップが定義しやすい
- マイルストーンの管理に重宝
- タスクの親子関係・関連付けがしやすい
- ツール自体のカスタマイズがしやすい
- 社長のディラン自ら、カスタマイズしている
Shooter2以前の課題点
- マイルストーン式なので、最終チェックまでのスパンが長い
- タスクの割り振りが外部依存になりがち
- Q-Gamesではプランナーがほぼ全てのタスク入力を行う
- タスクが多すぎて、精神的プレッシャーが大きくなった
- 管理側がスペックの実装漏れに気づきにくい
- 調子にのって入力していると、管理側が見落とす事があった
→そこで、Q-Gamesなりにスプリントを導入スプリント導入意図
- 2週間分のタスクだけに集中出来るので、タスク過多による精神的プレッシャーが減る
- 2週間ごとに成果物が出来上がるので、イテレーションが早くなる
- 開発の軌道修正がしやすい
→クオリティと、作業効率アップが期待できる
Shooter2のスプリントタスク
- 現在、16スプリント経過したShooter2での3つのフェーズ
スプリント運用で発生した問題点
- タスクをこなす事に慣れ常態化
- スプリントの定義を混同
- 達成すべきタスク = ゲームの目的になってしまった
→本来は品質的要求仕様(Quality)をスプリントの目的として設定するべき
Q-Gamesさんのレポートは以上です。
次は、セガさんのファンタシースターシリーズでのPERFORCE導入事例を書こうかと思います。あのセッションもタメになりました。
