Unity Asia Bootcamp Tour　Tokyo レポート その３：Lighting worlds in Unity / Unity のライティングを極める

http://unity3d.co.jp/asiabootcamp/

講演内容３つ目です。これがきつかった…。内容難しいわ。スピーチ速いわで。
「ライティング」と銘打っていますので、より専門的な内容になっています。

                                                  • -

#B122:
Lighting worlds in Unity / Unity のライティングを極める
Kuba Cupisz 様(Unity Technologies)


■概要

  • Unityのライティングは柔軟性を重視。様々なゲームの種類に対応。構築できる。
  • ハイエンド、モバイル双方で幅広く実行できるライティング
  • リアルタイムライト、ベイクライト双方を使用可能。

TIPS：スポットライト、ディレクショナルライトなどに、テクスチャの投影が出来るらしい。

  • -

■ポイントシャドウ

  • シャドウマップの場合、ピンホールカメラのような投影。
    • ６回描画するので推奨しない。
  • ポイントライトは、フィル（シャドウなし）として使用して欲しい。
  • -

■スポットシャドウ

ポイントより少し負荷が低い

  • -

■ディレクショナルシャドウ

  • -

■シャドウマップ

  • メモリ制約で大きなテクスチャが使えない。
    • カスケードシャドウマップを使う。カメラ近いと高解像度に。
    • マップ間の移行を見えないようにするのが重要。
    • 多くのエリアに影がかかるものに注意。処理負荷が大きくなる。
  • -

■シャドウプロジェクション

  • クローズフィット
    • 動的なものに使える。
    • 影の境界部分で画像が変わる？←よく分からなかったね。
    • 解像度が高ければいいが・・・
  • ステイブルフィット
    • 静的なものに。
    • ライトの方向、カメラの画角が変わらなければ使える。
  • カメラや画角が動かなければ、ステーブルフィットをおすすめする
  • -

■レンダリング

  • -

■フォワードレンダリング

  • メリット
    • 柔軟性が高い。
  • デメリット
    • ライトの数に応じて、レンダリングが高負荷になる。
    • 高速化に制約が生まれる。
    • 事実上、シャドウはディレクショナルに限られる。
  • 近いライトはピクセルシェーダで、他のライトはバーテックスで計算するとよい？
    • 最後にSH（球面調和関数）の処理?←SHをどう使うのかくわかんない。
    • フォワードレンダリングでは、途中バーテックス／ピクセル／SHをブレンドさせるために、各セクションに重複箇所がある。
  • -

■デファードライティング

  • シーンジオメトリとライティングを切り離す
    • ジオメトリをレンダリングして格納。
    • 法線、スペキュラ、Z深度はG-Bufferに格納。
  • ２回目のレンダリングで、前のレンダリング情報を利用してライティング
  • メリット
    • 小型のライトに向いている
    • ライトが隠れてる場合も低負荷。
    • G-Bufferの情報を再利用できる。
  • デメリット
    • ２回レンダリングの負荷。ジオメトリに依存。ライトに依存しない。←これはメリットでもあるんじゃない？
    • 帯域が必要。テクスチャがシーンにたくさんあると問題。
    • シャドウキャスティングは高負荷。
    • 制約：ライティングモデルは、全て同じ設定にしなければならない。
  • 透明なオブジェクトは、フォワードレンダリングで処理することになる。
    • Unity側で自動的に処理。
    • ライトの数に応じてレンダリングが発生する。

※アルベドってちょいちょい話には出てくるんだけど、仕事では具体的に使ったことないなあ。
たぶんカラーとかテクスチャだけのレンダリングだと思うのだけど。イマイチ詳細な情報が無い。
こんなん
↓

参考→VRay MentalRay Lighting Demoreel 2011 - アルベドマップも確認出来て、ライティングの重要性が伝わるリール！

  • -

■異なるアプローチ…ライトマップ

  • Beastでライトマップ出力←先の講演内容とかぶるね。
  • ライトマップはディフューズの情報しかない。
    • スペキュラ、ノーマルは？→別のDirectionalライトで。
  • -

■デュアルライトマップ

  • ２つのライトマップを使用
  • ニアライトマップ
    • 間接光、スカイライト（GI）を使用
    • Directionalライト使って、スペくキュラ、バンプ、シャドウを表現
  • ファーライトマップ
    • GIのみ
  • メリット
    • ベイク（ライトマップ）、スペキュラ、バンプ、シャドウが使える。高解像度のマップが使える。
    • 遠くは低い解像度ですむ。低負荷。
    • 近い部分のライトは３回書き換えられる。→インテンシティを替えられる←イマイチ意味分かんないね。
  • デメリット
    • メモリ負荷高い。
  • -

■シングルライトマップ

  • シンプル。
  • 静的ライトからのスペキュラがない。
    • バンプなどのライトは別に用意する必要がある。
  • ダブルシャドウ（ベイクシャドウとリアルタイムシャドウのブレンド）の問題が発生する
    • 影をなじませる部分が課題
  • -

■ディレクショナルライトマップ

  • バンプ、スペキュラの情報を格納
  • メリット
    • 法線マップが使える。
    • ライトマップのサンプリングが１回で済む。←どういうことだろうか？
  • デメリット
    • 平面であれば問題ないけど、球とかだと問題がでる？
  • -

■ライトプローブ

  • あくまでも近似の方法
  • プローブ同士の補間は？
    • ４頂点のテトラで補間。Unity上で可視化出来る。
    • 長めの四面体はうまくいかない。大きさ揃える。
  • プローブ配置はマニュアルでやったほうがいい。
    • 重要なところに配置する。
  • -

■レンダリングコスト

  • フォワード
    • オブジェクトは毎回描画。負荷はライトの数に応じる
    • シンプルなライト環境であれば使える。
  • デファード
    • 事前に負荷がわかる。
    • それぞれのライトのシェイプを描画できる。
    • 限られたピクセルに対してライトを与えられる
  • -

■シャドウパフォーマンス

  • レンダリングの２つのフラグでコントロール可能。
  • シャドウがいらなければ、外していけばいい。
  • シャドウディスタンスの微調整。
    • スタックウィンドウで確認し、数値を押さえる。
  • -

■シャドウのクオリティ

  • 距離（ディスタンス）がクオリティに関わる。
    • あまり遠い距離にしない。近めに保っておく。
  • デフォルトシャドウはハード。くっきり
    • できるだけソフトにする。自然に見えるように。
  • ブラーをかける
    • シャドウの境界線に自然なフェード付けられる
    • Radiusを大きくし過ぎないように。
  • -

■ライトマップのこつ

  • ライトマップのスイッチ
    • ムードによって変える
    • ３、４つのセットを用意して切り替える。
  • ポップしてしまう時の対応は？スムーズなトランジションは可能？
    • ライトマップのセットをフェードさせる
  • -

■ライトプルーブ（SH）の再利用

  • マズルフラッシュとか
  • 方向性、精度が気にならない場合は使える。
  • -

■質疑応答

  • ライトマップ計算のスピードアップのコツは？
    • スピードは設定に依存するため、クオリティ、サンプルの数値を減らす。
    • シーンを抽出。小さな部分に注目してやっていく。
  • ライトプローブのライティングは、モバイルではハードスペックに依存する？
    • SHの情報をデコード出来ないデバイスではムリ
    • 現実的な対処法として、動的なライティングは諦めたほうがいいのか？
      • スペックによるが、デバイスを選べば大丈夫。
                                            • -

…以上で本日僕が参加した講演は終了。あと２コマづつくらいありましたが、仕事があったので帰りました。

あとは金曜に参加したセミナー２つ。残りはまた後で更新します。

2012/02/23「3DCGツールとUnityによるゲーム開発実践セミナー」レポート　その３：セガ開発事例

もうセミナーから１ヶ月ほどたってしまいましたが、なんとか、最後の記事が書けそうです。
第３部は、セガでの事例。

Autodesk Areaのmayaコラムも連載されている、セガの築島様の講演です。
読んで触ってよくわかる！Mayaを使いこなす為のAtoZ


※参考記事。こっちのほうがわかりやすいかも。


■UnityでiPhone向けゲームを作る！

  • iPhone4で3D・・・特徴、最適化の方法
    • maya2012＋Unity3.5 → iPhone4
      • iPhone4で25〜45fps出るゲーム
      • iPhone4S、iPad2では45〜60fps
    • トーンマップ、ブルームなどのエフェクトも入れる。
  • シーン管理
  • ゲームエンジンとコンテンツ工学

→トーンマッピング参考
→ブルーム参考


■サンプルゲーム

FPS。maya→iPhone4用に最適化してある。

  • カメラに近い腕、ウクレレ（武器）には法線マップ。
  • ライトはUnityのライトマップ焼きこみ。非常に綺麗。
    • ライトマップは、リアルタイムに切り替えている。ライトプルーブ使用。
  • フォグ、水が流れるなどの表現
  • 地面のモデルをそのままコリジョンとして使用。

→ライトマップ参考
ライトプルーブはこのセミナーの第1回記事で触れてます。
武器がウクレレとかどんなゲームだよと思いますが（セガらしい）・・・画面写真ないとよくわかんないですね。

最適化は、Unityのマニュアルに書いてあることが正しい。

  • ただし具体例が少ない。
  • iPhone3Gあたりをベースにしてる風なので、今となってはスペックが低い機種向けの最適化方法かも。


■iPhone4の特徴

  • テクスチャが大きく使える！
  • Unityのライトマップが有効。綺麗！
    • サンプルゲームのシーンだと、1024×1024を5枚使用。
  • むしろ、頂点カラーが使えない。
    • Unityにシェーダが無い。
  • レイヤー化されたテクスチャよりも、大きな1枚のテクスチャが有効。
    • 同様にタイリングよりも、ベタッと貼るのが有効。（サンプルの地面では2048×2048）
    • ライトが焼きこまれたカラーテクスチャ1枚が最高！！
  • UnityのAnisoLevelを上げてもコストが無い。
    • 異方性フィルタリングの値？みたいですが。
  • 頂点法線もいじらないほうがいい。
  • ミップマップの設定項目が無い。
    • 代わりに、前述のAnisoLevelを6くらいに上げてもOK。
    • ライトマップの数値はデフォルトで3とか。

→参考：異方性フィルタリング
→参考：ミップマップ
全て重要な情報！
AnisoLevelとか、どんな変化が出るのかよくわかってないですが
（たぶんテクスチャのフィルタリングのかかり具合だと思うのだけど）
実際数値入れて試してみないといけませんね。

Retinaディスプレイは、高解像度のためアンチかけなくても綺麗。
（RetinaはiPhone4以降採用されているディスプレイ方式。新しいiPadでも）

  • Unityのエディタでくっきりと見えるテクスチャは、むしろサイズが大きいかも。
    • →１段階大きさを下げたほうがいい。


■最適化で注目する点

  • DrawCall数・・・少ないほどいい！
                                  • -

200以上→15fps
100→30fps
50→60fps

                                  • -
    • マテリアルの数を少なく！→Unityのstutsで情報見れる。
    • テクスチャの数も少なく！→流用を増やす。
      • ライトマップを使えば、そんなに気にならない。
    • アトラス（テクスチャをまとめる！）

DrawCall数は描画の回数だと思うのですが、これは減らせば単純に軽くなります。
テクスチャまとめることアトラスって呼ぶのね。まあマップだしね。

  • Batch数
    • Unityで自動的にまとめられたオブジェクトの数
      • 動かないものはStaticにしておくと、まとめられる。
    • 実行時に、ConvinedMeshとして数を確認できる。
      • Batch数が多ければ、よくまとまっている良いデータ。→DrawCallが減る！
      • 逆に多すぎても重くなる。→50以下がよい。数100とかは多すぎる。

Unityのマニュアルにも、「In Summary, Convine!」（とにかくまとめろ！）と書いてあるそうですww

  • サンプルデータでは…
    • 1500〜4000ポリくらいの単位でまとめている？
    • まとめたら早くなった。
      • DrawCallが減る。Batchも減る。
    • ただしデザイナーが管理しやすいように、全部まとめる必要はない。
    • 従来通り、mayaでレイアウトした。
      • Unityでプレハブ化して配置するのは、iPhone向けではないかも？

→Unityのプレハブについてはこちら。


■頂点数

  • ポリゴン数よりも、頂点数が重要
  • 50000頂点くらいで（これはマップ単体の話だと思う。）
  • 法線も少なく。ソフトエッジが有効。
  • UV頂点もなるべくくっつける。
  • ライトマップを焼き付けた後は、法線を捨てればよい。
    • Normalize〜のチェックを「None」にする。

このへんは、僕が今別件でやってる携帯機のスペックとほぼ同等ですね。ポリゴン数よりも頂点数。
UVも法線も切れ目があるとそこで頂点が増えてしまうので、それを避けるデータ作りが必要。


■何が重いのか？

  • リアルタイムライティング
    • ライトマップを焼き付けたほうがいい。
    • 描画面積が小さければ、リアルタイムでも有効。画面近くに来ないように。
  • （おそらく同一マテリアルに）3枚以上のテクスチャを貼ると重い。
    • カラー、法線、スペキュラーのセットですでに重い。
      • スペキュラはカラーマップのアルファ値に入れるとかで解決できる。
  • フォグは？
    • そうでもないが、カリングは必要。
  • 半透明は（相変わらず）危険！
    • フィルレートが低い。
    • 面積や重ね合わせを小さくすると、結構行ける。大きくなければ。
  • パンチスルー（CutOut）は重い！

→カリングについて。最近は、遮蔽を自動的に検出するOcclusion Cullingなんて手法もありますが、基本は手動設定です。
→フィルレート参考記事：ピクセルフィルレート


■早くする方法！！

  • まずはカリング！！
    • マップは壁とかで遮って、遠くを見えなくする工夫を。
  • スキニングオブジェクトを少なく。
    • ジョイント数も少なく。
    • 親子関係よりは、スキニングの方が良い。
    • (mayaでいうと）1skinCluster、1マテリアルがベスト！
  • ライトマップを使えば、ローポリゴンでも綺麗にAO（アンビエント・オクルージョン）が入る。
    • ライトマップならライトたくさんおける。
    • マップは50000頂点くらいで作成している。
    • コリジョン抜けはしないので、地面のポリとかは思い切って減らしてもOK。
  • 空
    • UnityのSkyBoxは綺麗なので使いたいのだけど、モバイルだと問題がありそう。
      • Tex圧縮が汚い。←これがSkyBoxにかかるのか、いまいちあやふや。
      • DrawCall6使う（立方体）←これも、いまいちよくわかんないです。
    • 従来通りの球をつかう方法で。
      • ファークリップが問題になる。
      • カメラを複数用意して、キャラ用、メイン、スカイ用、とクリップの値を分ける。
  • ソートの問題
    • 木とか、半透明のものは、描画順がおかしくない程度にまとめる。
    • 確か半透明オブジェクトは、Static入れてもまとまらない。

→アンビエント・オクルージョン参考
→ファークリップは遠くのオブジェクトを描画しない。逆に手前のオブジェクトを消すのはニアクリップです。

スキニングの件も、携帯機でよく直面する問題です。
スキン数やマテリアル数はパフォーマンスに直結するので、なるべく少なく。
なんならメカものも関節構造ではなく、スキンで処理しちゃいます。


■まとめ

  • iPhone4なら、3Dはそのまま結構出る。
  • ただし、ちょっとしたことで重くなる
  • 最適化は、常識的な範囲内でOK！
    • テクスチャを大きく出来る利点がある！！
  • どんどん作って、出してみればいい。


■シーン管理

  • あまりバラけさせないほうが良い
    • 関連するものどうしを近くに置くとか。
    • 関連性がわかりづらくならないように。
  • モデルのそばに、関連するMaterials、Texturesフォルダを置く。
                    • -

例)
Models
　-Stages
　　-s01
　　　-fbx
　　　-Materials
　　　-Textures

                    • -


■エディター・エンジンとは？

  • 効率アップに重要なこと
    • 繰り返し試せる
    • 作業中と結果が同じ
    • 似た作業が同じように出来る
  • 重要なのは、コンテンツ工学・・・日本では、これが抜けている！！
    • 職人技を一般化する。
    • 感ではなく、数値化する。客観的に分析。
    • 学びやすい、体系的な情報に。
  • おすすめ書籍

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

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

  • 海外との差が叫ばれて久しいが…
    • 技術的な部分はUnityなどのエンジンで吸収できる。
    • 日本の開発者が得意なことをやる！感覚的なもの、手触り！

…と、講演の内容は以上です。

築島様は語り口調も面白く、なおかつ技術的にも有用な情報が聞けて、実のある講演だったなと。携帯機にはどれも似たような苦労があるんだな…と思ったり。

最後に紹介されている書籍はぜひ読んでみたい。多分、公演直後のAmazonでは品薄になってたと思いますww

                                          • -

これで、全3部のセミナーレポートは終了。今後読み返して、修正。加筆することはあるかもしれませんが。また、実際にUnityで自分で試して得た情報も、随時アップしようかと思います。

ではでは。

2012/02/23「3DCGツールとUnityによるゲーム開発実践セミナー」レポート　その２：マトリックス「Ragdoll」開発事例

ようやく書く時間が出来ました。1週間ぶりです。


前回の記事http://d.hatena.ne.jp/ikaakira/20120311/1331485160に引き続き、
Unityのセミナーレポートです。全3部のうち、今回は第2部。
コンシューマーゲームの開発なんかでおなじみのMatrix社の講演です。


・Matrix


本講演は、GREEから配信されているMatrix社製のAndroidアプリ「Ragdoll」を題材に、
Maya→Unityへのアプローチ手法についてお話いただきました。
自社フレームワークも持っている中で、Unityを選んだ理由、
スマホ向けにビルドするための苦労など、実践的なお話です。


https://play.google.com/store/apps/details?id=jp.gree.android.pf.greeapp3130

                                                                                            • -

■アジェンダ

  • プロジェクト
  • 「Ragdoll」とは
  • Unityを選んだ理由
  • プロジェクト構成
  • 実際の流れ
  • アニメーション
  • マテリアル
  • GUI
  • AssetBundle
  • フォント
  • ライティング
  • ラグドール
  • シーン分け
  • 課題
  • 要望
  • よかったこと
  • まとめ
  • Q&A


■プロジェクト

  • 2011/1スタート
  • 目的：短期間・低コスト・成果


■「Ragdoll」とは

  • ジャイロと物理演算を組み合わせてぶらぶら揺れる
  • 必須条件：リアルに見える・揺れる・カスタマイズ（キャラクター・UI）・かわいい


■Unityを選んだ理由

  • Androidネイティブ開発も検討したが・・・→Unityで！
  • いろいろゲームエンジン触ってみたけれど・・・
    • リアルさ
    • シェーダをカスタマイズできるのが決め手。（Unrealとかはできないのか？）


■プロジェクト構成

  • 初期：計５人
    • プロデューサー：１（ベテラン）
    • プランナー：１（中堅）
    • プログラマー：１（中堅）
    • テクニカルアーティスト（TA)：１（ベテラン）
    • デザイナー：１（新人）

※新人からベテランまで多様な配置をこころがけた。
※Unity Proライセンス使用は、プログラマーとTAのみ


■実際の流れ

  • Unity3.4.2pro ＋ maya2011
  • モデルはNurbsからポリゴン化。やり直しが利きやすい
  • キャラごとにリグをカスタマイズ。ペイントウェイトでスキン設定。
  • 複雑なUIは、mayaで作成。
  • 受け渡しはFBXで。
    • mayaでやること
      • メッシュ作成
      • ジョイント
      • モーション
      • UI
      • マテリアルの仮付け
    • Unityでやること
      • マテリアル
      • Pysics（物理設定）
      • プレハブ化（Unityのプログラムで扱えるように部品化することです）　
  • 腕や足などの各パーツは、原点をボディパーツの頂点にスナップできる。
    • どの頂点にも。カスタマイズが面白い。
    • 法線方向にスナップする。


■アニメーション

  • モデル用のFBXと、アニメーションFBXを別に作成。
    • アニメーション用には、モデルの変わりにロケータをつける。
  • Unityでの作業
    • AnimationClip（Unityで扱えるアニメーションデータ）を複製
      • 元のFBXは不要になるので削除。アニメーションだけ残せる！
    • データ変更の仕組みを自動化した。


■マテリアル

  • マテリアルはUnity上で。
  • Strumpy Shader Editorを使用。
      • モバイルで使用するには重いので、手直しが必要。
  • Furシェーダは別に作成。長さが調整可能。

※>Strumpy Shader Editorの参考記事。＞http://www.shader.jp/?page_id=300
AssetStoreで無料配布されてるみたいですね。ノードベースのシェーダプラグイン。


■GUI

  • Unity標準の「GUI Texture」は使いづらい。
    • 解像度、縦横費の違いに対応しづらい
    • DrawCal（描画回数）が増える。
  • 「EZGUI」を使用！
    • レイアウトが崩れない
    • テクスチャアトラス（テクスチャをまとめること）で、マテリアルを1つに出来る。
    • ボタン、スクロールリストなど豊富な機能。

※参考記事。$200もするんだ！＞http://d.hatena.ne.jp/nakamura001/20110804/1312481838
※こっちも＞http://blog.cshool.jp/2011/10/4090.html



■AssetBundleの使用

  • 複数シーンのテクスチャをまとめて高速化を図ろうとしたら・・・
    • ロードが長くなった！！
    • データ更新が面倒！！
  • UnityのAssetBundleを使用！
    • シーン・データごとにAssetBundleを作成。
    • 更新確認して、必要なものだけ追加・更新。
    • アプリのビルドと、AssetBundleのビルドバージョンをあわせる必要がある。

※ここにAssetBundle関係の記事リンクあります＞http://aretokore.jp/blog/2011/05/unity.html
（AssetBundle以外の記事も充実してます。EZGUIとかも）
※僕自身、これが何なのかよく分かっていませんが・・・




■フォント

  • Unityでは、フォントテクスチャを2048x2048に収める必要がある。
  • 「ひま字」フォントを使用。
  • スプライトテキスト（使用する文字だけ抜き出す機能）は、使用しなかった。
    • ユーザー独自ネームのため。

※ひま字フォント＞http://www.kfstudio.net/himaji/


■ライティング

  • Unityはモバイルでシャドウマップが使えない。
    • Blob Shadow Projectorで丸影を実装。
  • 「ピクセルライトカウント」というパラメータを減らすと、負荷が減る。
    • 見た目はあまりかわらないのでオススメ！

※Blob Shadow Projectorは標準機能みたいですね＞http://d.hatena.ne.jp/nakamura001/20110528/1306603307


■ラグドール

※ここでいうラグドールは商品タイトルではなく、３Ｄ用語としてのラグドールです。
参考→http://www.4gamer.net/games/039/G003948/20080208032/

  • 「Ragdoll Wizard」機能を使用。←これmaya?
  • 耳などには追加でジョイント、剛体設定
  • モデル修正のために、maya上でのクラスタを合わせておく。
    • →再設定の必要が無い。

※このへん、内容はだいたい分かるのですがmayaでの具体的な設定方法は分からず・・・

※Ragdoll WizardもUnityのAssetみたいですね。＞http://unity.creator.ms/unity-005.html




■シーン分け

  • 初期
    • 作業者ごとにシーン分け
    • スクリプトシーンを、GUIシーンに追加していた。
  • EZGUI導入後
  • エクセルでパラメータ管理→マクロ→Unityに流し込む
  • Subversion
    • バージョン1.7以降であれば、使用に問題は無い。


■課題

  • リソース管理・まとめ方は一考の余地あり。いい方法があれば教えてほしい。
  • ロード時間の短縮。


■要望

  • 受け渡しフォーマットの強化。
    • Phisycs、マテリアル、AnimationClipなど、mayaからそのまま持ってこれれば。
    • AssetBundle互換問題
      • モバイルでも、CPUプロファイラが動いてほしい（よくわかんない）


■よかった事

  • チーム力・開発力の向上。
  • 実装までの速度アップ。再生ボタンを押すだけ！
  • コミュニティ（facebook Unity助け合い所）の存在
    • Unityは異例の盛り上がり！
    • OPEN化！


■まとめ

  • iPhoneかAndroidで迷った。
  • Unityは画材のようなもの。使い方次第で変わる。
  • 目的のうち「速い」は達成できなかった
    • ものは出来るのだが、チューニング、リリースまでの時間がかかった。
  • 最後に・・・

とにかく作ろう！！！

  • お仕事お待ちしております。スマホ・デモ・プロトタイピングなど。
    • unity_inquiry@matrixsoft.co.jpまで


■Q&A

  • EZGUIのバグは？端末依存とか、ボタンの反応とかであると聞いたが？
    • バグはあったが、開発上、大筋では問題なかった。
  • mayaでのUI作成と、EZGUIをどう組み合わせたのか？
    • ボタン挙動はEZGUIで。
    • mayaのUIは、プログラムでアニメーションを実行しているだけ。
  • シーンきり分けについて詳しく
    • デザイナー・・・maya上でレイアウト。UnityではUIシーンを構築せずに、プレハブ化まで
    • プログラマー・・・プレハブを呼び出すだけ。
  • アニメーションデータが、メモリを圧迫してしまう・・・
    • 複製したアニメーションクリップを動的に読み込んだり
    • プレハブにアニメーションを仕込んだりしている
  • FBXに入っているアニメーションデータを全て載せるのがきつい・・・
    • 必要なものだけを読んだりしている。
                                                          • -

・・・と以上になります。


改めてまとめてみると、各要素ごとにしっかり整理されていて、
非常に分かりやすいプレゼンでした。細かなTIPSもあったりして。


会場では、質疑応答でも見られるように「EZGUI」についての質問が多かったですね。


あとはやはりアニメーションデータの持ち方はどこも苦労しているのかな？という印象でした。
Matrixさんはそんなに問題ないようなのですが、質問者さんのほうでは
なかなか解決が難しい問題のよう。時間が短いせいもあり、あまり質疑がかみ合わない感じでした。

  • -

さて、残すはラスト第３部ですが、今日はここまで。
また来週にでも更新します。

2012/02/23「3DCGツールとUnityによるゲーム開発実践セミナー」レポート　その１：mayaとは？Unityとは？その連携について


http://www.info-event.jp/autodesk/maya-unity/


随分と遅れてのレポートになりますが、先月行われたAutodesk／Unity社主催のUnityセミナーのレポート記事です。
既に当日のレポートは各WEBサイト様なりTogetterなりにまとめられていますので、そちらを参照いただいたほうがよいかも。

■[Unity][Unity3d]「3DCGツールとUnityによるゲーム開発実践セミナー」開催
http://d.hatena.ne.jp/nakamura001/20120224/1330056162

■「UnityでiPhone向け3Dゲームを作る」レポート
http://d.hatena.ne.jp/Aqu/20120223/1330013483

■3DCGツールとUnityによるゲーム開発実践セミナー #autodeskunity
http://togetter.com/li/262530


本記事ではスライドの内容を追いつつ、特に僕自身が気になったことを補足させていただこうかと思います。
セミナー自体がなんとなく３部構成だったので、記事も３回に分けて書かせてもらおうかなと。


まずは、主催者であるAutodesk／Unityの講演。
「mayaとは？Unityとは？その連携について」と題して。まあタイトルそのままの内容です。


※ちなみに協賛にGREEとかも名をつられてます。あと、アマナイメージズ？という聞きなれない会社も協賛として参加していてなんぞここ？と思ってたのですが、実はCG業界にいろいろと関わっている会社だったのね…。知らんかった。詳細はのちほど。
※あと、当日のセミナー会場には当然プレスの方もいたわけですが、彼らのカメラのフラッシュが限りなくうざかったです。同じように感じていた人もいてクレームが入ったのかはわかりませんが、後半はちょっとおとなしくなった気がする。
※あとこれは要望なのだけど、CGとかIT系に限らず、セミナーは椅子だけじゃなくて机が欲しいなあ…ノートPC持ってったんだけど、膝に置いて打つのがしんどくて、すぐ紙メモに切り替えました。机の分面積狭くなるのはあれだけど。でかい箱が必要なら、その分有料でもいいから。



■mayaとは？Unityとは？その連携について

                                                                                          • -

Autodesk講演

                                • -

mayaの説明

  • 販売中のmayaトレーニングブック３では、Unityとの連携についても解説している。

Autodesk Maya トレーニングブック 3

Autodesk Maya トレーニングブック 3


Mudboxの説明

  • 巨大なテクセル（Giga Texel）が扱えるように。


上記、各種ミドルウェアについて補足。

  • HumanIKは名前の通りキャラクターアニメーションに関わる技術。mayaにはFBIK（フルボディIK）として統合されています。
  • Ptexは、米ディズニー社が開発したテクスチャマッピング技術です。UVの概念がないらしい。＞http://www.ousam.com/blog/2010/01/17/597
  • Beastはよくわかりませんが、上記リンク見る限り、リアルタイムでのGI（グローバルイルミネーション）ライティングに関わるものらしい。
  • Alembicも知りませんでした。異なるソフト間で、シーンファイルの互換性を保てるようですね。＞http://cgworld.jp/feature/report/alembic.html

Unity講演

                                • -

概要

  • 日本では？90万人が利用？（あやふや）
  • エディタ自体を拡張可能
  • 最新の3.5では、AIナビゲーションメッシュ、ライトプルーブなどのリッチな機能も実装
  • Unity Web PlayerはブラウザベースのMMOなどでも採用されている。
  • 全世界で1億人がインストールし、毎日500万人？ペースで増加している。


AssetStore
http://unity3d.com/unity/asset-store/

  • 本人7：Unity3の取り分ルールで販売可能。
  • Total2000アイテム超
  • トップセラーは月20000ドルの売上


GREE、DeNAでも採用。


日本での普及

  • 昨年比、1496%の成長。
  • 売上世界第2位
  • Unity Proの採用企業は300社を超える
  • ユーザーも3万人を超えた
  • Facebookの「Unityユーザー助け合い所」でも活発なやり取りが行われている。＞http://www.facebook.com/groups/unityuserj/


上記の数字的なものは結構あやふやです。とりあえず、爆発的な勢いてユーザーも採用事例も増加してるよ、ってこと。


最新のUnity3.5で搭載された機能について補足。


他にもUnity3.5ではいろいろ機能追加されてるらしい。まとめ記事こちら。
https://sites.google.com/site/sunflowerlaboratory/project-updates/unity35gadeta

LIVE DEMO

                                • -

実際にゲーム「WET」で使用されたアセットを使用し、マップ、マップオブジェクト（ハイメッシュの像）、キャラクターの３つについてそれぞれ取り上げたデモが行われた。


・マップ

      • -

maya

  • 新しく搭載されたビューポート2.0で、ハイメッシュのマップでも表示がサクサク。


unity

  • Unityの「Asset Server」を用いて、Win、Mac 両方の環境に同じ物をアップデート可能。
    • チーム間でのやりとりが容易に。
  • mayaのデータ（.ma）は、そのままUnityで読み込み可能。
  • Unity「SkyBox」を使ってリアルな空背景を作成出来る。


Asset Serverのデモでは、実際に.maのデータをUnityに読み込んで、それを他の環境でも同期させたりしてましたね。
SkyBoxで作った空は、非常に綺麗です。ただ後半のセミナーでは負荷が高くて使うのを断念した、という報告も。

・マップオブジェクト（像）

      • -

Mudbox

  • テクスチャをステンシルで転写。
  • 白黒画像を用いて、レイヤーマスクもペイント出来る。
  • ハイメッシュモデルを作成→１クリックでmayaに送信


maya

  • MudboxのSDivレベルが自動的にLOD付きのモデルとしてインポートされる。
  • テクスチャもCollapse（集約）され、１枚になって割り当てられる。


Unity

  • 上記のLOD設定はそのままUnityに引き継がれて、自動的にLODレベルが設定される。
  • LODGroupで、LODのかかり具合を調整（スライダで調整してましたね。わかりやすい）
  • カリングも可能。
  • Unity上で、バンプ、スペキュラ、キューブ環境マップなど適用し、調整。


その他
ポリゴンリダクションはSoftImageが強力なので、そちらを使うとよいかも。


SDivレベルってのは、Mudboxのようなスカルプトモデラーでモデリング中に分割を増やす中で作成されるものなんだけど、これがmayaでも、なおかつUnityでもLODレベルとして自動的に反映される、というのは非常に便利。
スライダによるLOD調整も明示的で、非常にわかりやすい。
LOD（レベル・オブ・ディテール。カメラとの距離に応じてモデルの詳細を変化させる）は３Ｄゲームでは必須の技術なので。

・キャラクター

      • -

maya

  • HumanIKの機能と、キャプチャーデータを利用してモデルにモーションを流し込む
  • MotionBuilder(MB)に転送。


MotionBuilder

  • mayaから送られたモーションをリターゲット（キャラクタに合わせて流しこむ）
  • モーションをベイクする（プロット？）←このプロットの意味がよくわかりませんでした。
  • MBのストーリーボード機能、各モーションをクリップ化してブレンド出来る。
  • 待機（Idle）、歩く、走る、攻撃、の４つのモーションをクリップ状に連続して並べて、BreakDown。スケルトンにモーションをBake（焼付け）する。
  • 再度、mayaにモーションをアップデート。


maya

  • TIPS:mayaでモーションの保管方法をAuto→Plato？に変えておかないと、Unity上で上手く動かない？


Unity

  • 連続したモーションを細切れにして名前をつける。
    • StartFlame、EndFlameを数値設定
    • Upright（←どういう意味だろ？）すると、4つのクリップに変換される。
  • 歩き回れるキャラクターを簡単に作るには？→Unityのアセット「Charactor Controller」を使用。
    • Phisycsでキャラクターのアタリを作成。（←これはUnity本でやりました）
    • Charactor Controllerにスクリプトを差し込む。
      • ThirdPersonController
      • ThirdPersonCamera
    • カメラの設定や、歩く速度を変えたり出来る。
    • IKの機能もある。
  • キャラクターをプレハブ化して、他のシーンに持っていくことも可能。

ここで説明している、Unityでキャラクターに複数のモーションを持たせる方法ですが、以前、当ブログの記事でも取り上げたものとは違う方法です。
＞http://d.hatena.ne.jp/ikaakira/20111106/1320589021


僕の場合は、複数アニメーションを並列で持たせた（複数のクリップ）のですが、ここでは１本のタイムライン上に複数モーションを並べたデータを作成し、Unity上でフレーム数を指定して区切って、その後複数クリップに変換しています。
やり方としてはこっちのほうが簡単かなあ…。
なんかデータの持ち方としては、しっくりいってないのですが。


他、おそらくUnityの標準アセットで簡単にキャラクターとカメラを動かしてTPS（サードパーソンシューティング）風なものを作成していましたが、これも非常に簡単！やっぱりカメラ処理がそれっぽいとゲームっぽくなりますね。


以降、時間が余ったので、Unityいかにクオリティアップするかの話でした。

  • Terrain Editor（地形作成エディタ）が強力。
    • 山とか海とか
    • リアルタイムでペイント出来る。
  • マップへのアタリ付け
    • Phisycsから。Boxなどでつけていく。→即反映。
  • mayaオフラインファイル
    • Unity側で、既存のモーションを壊さずにアニメーションを補正出来る？（←よくわからない）
    • 補正したアニメーションのファイルを、リファレンスとして持ってくる。
    • Editファイルに情報を持たせることが出来る（これmayaの話だね）
      • テキストファイルで開ける。
      • 拘束条件、ロケータ情報などもつけることが出来る。
  • 絵作り
    • UnityのImageEffectが便利。
    • DoF（被写界深度）、FishEyeなどのリッチエフェクトが簡単に試せる。


Terrain Editorはすごい！ペイントで地形がもりもり出来ていきます。


ImageEffectも、結構揃っててすぐいろいろ試せるのはいいね。


Unityの話はまあわかったけど、むしろmayaで知らないことが多いなあ…
mayaオフラインファイルって、mayaいじってるとプロジェクトフォルダの中に出来る「Edit」っていう謎のフォルダの中身のことか？これがテキストファイルなので、maya上ではなく、テキストエディタで（オフライン）でいじれるってことなのか…？

・まとめ

                            • -

これまではmaya、maxからうまくデータが渡せないこともあったが、Autodesk／Unityで協力して煢然している。
今後は、Scaleform（Flashから書き出せるやつですね）、Beast（また出た）でも。

・Ｑ＆Ａ

                            • -
  • mayaの標準マテリアルは、そのままUnityに持ってこれるのか？
    • ものによる。基本はUnityでの調整が必要。


Autodesk／Unityの講演は以上です。


Unity側の話はだいたいわかったので、実際に触っといてよかったなと。
むしろ、MayaのオフラインファイルとかMBまわりの知識がないのでそのへん調べとかないと。


この後、休憩を挟んで協賛企業のプレゼンでした。
※休憩中に知り合いの先生とちょいと会ったので立ち話。来期からUnityを使った授業を考えてるとのこと。）
※その最中にデジタルスケープの人も話に混じってきた。名刺いただきました。


参考：協賛企業プレゼン

                        • -

■アマナイメージズ
http://amanaimages.com/indexTop.aspx


冒頭で上げたこの会社ですが、実は国内最大手、ポリゴン・ピクチュアズを
グループに収めるけっこうな大企業だったようです。知らんかった。


本業は、ストックフォト販売。
昨年から、３Ｄモデルデータの販売も開始していて、12万点ほどの品揃え。
※欧米では、３Ｄモデル販売は大きな市場とのこと。
1点、数千円からの販売だそうです。
他に、BGM、SEの素材販売も。

                        • -

■イマジカデジタルスケープ
http://corp.dsp.co.jp/

人材紹介、派遣でお馴染みのデジタルスケープですが、
元々はデジハリの卒業生を受け入れるために作られたのが前進なんですって。
登録2万人、500社以上とお付き合いあり。受託開発もやっていて、100名以上が在籍。


DCCツール、Unityの運営導入サポートなどのコンサル業務もやってるみたいです。
力を入れているのが、多様化する開発スタイルへのコンサルティングとか。
内部制作、外部制作のメリット、デメリットを考慮。
Unity講座も準備中。
ムービーARアプリはうちだけ！と自慢してました。

【勉強会】第１回 横浜へなちょこUnity勉強会③〜FBXに複数のアニメーションを持たせる〜とりあえず解決編

イベント 書籍 Unity 3dsmax

http://atnd.org/events/20574

また前回の記事の続きです。複数のアニメーションを持ったFBXファイルをどうやってUnityに読み込むか？


４．複数のアニメーションを持ったFBXを作成する方法（解決編）

  • -

その後、「FBX」「複数持たせる」「アニメーション」などで検索していくと、一つのヒントが見つかりました。こちらのページです。
↓
■複数アニメーション対応FBXの出力
http://www.kosaka-lab.com/tips/2010/01/fbx.php


おおこれはまさに望みの内容！！と思ったのですが…かなりトリッキーな方法ではあります。引用させて頂きますので、御覧ください。

（以下、引用）

MayaからFBXにアニメーションを出力した場合、１つのFBXファイルに対して１つのアニメーションしか出力されません。一つのFBXファイルに複数のアニメーション（歩く、座る、など）を格納する方法を発見しました。

MayaからFBXに出力する時にバイナリではなくテキストモードで出力します。
そして、動作毎に、一つずつファイルを出力します。３つのモーションが欲しければ３つファイル出力します。このとき、モデルのデータに変更を加えないようにしてください。

　どれか一つのファイルをメインとして、そのファイルにアニメーションデータを追加していきます。
メモ帳や秀丸などのテキストエディタでFBXファイルを開きます。

ファイルの後方辺りに、アニメーションデータが格納されています。

;Takes and animation section
;----------------------------------------------------

Takes: {
Current: "Take 001"
Take: "Take 001" {
FileName: "Take_001.tak"

・・・・略・・・・
}
}
　Currentの行とTake : "Take 001" { ・・・・}の間が、一つのモーションとなります。
なので、他のファイルから取得した同じ部分をTakes{　・・・・}　に貼りつけます。
識別しやすいように任意の名前をつけてください。

;Takes and animation section
;----------------------------------------------------

Takes: {
Current: "Take 001"
Take: "Take 001" {
FileName: "Take_001.tak"

・・・・略・・・・
}


Current: "Take 002"
Take: "Take 002" {
FileName: "Take_002.tak"

・・・・略・・・・
}

Current: "Take 003"
Take: "Take 003" {
FileName: "Take_003.tak"

・・・・略・・・・
}

}
　これで、１つのファイルに複数のアニメーションを格納することができます。同じような方法でXファイルにも複数のアニメーションを格納することができます。

（以上、引用終わり）


ポイントとしては、

・maya（maxでもOK）から、テキスト形式（ASCII）でFBXをアニメーションごとに出力。
・各FBXのアニメーション情報部分を、１つのFBXに追記して保存する。

ということになります。早速試してみます。



maxからFBXで書きだす際に、「拡張オプション」の「FBXファイル形式」でバイナリではなくASCIIを選択。

で、テキストエディタで開いてみると…

あれ？先に紹介したサイトのFBXの中身とちょっと違います。「Takes and animation section」になってるはずのところが「Takes section」になっていて、しかもアニメーション情報の中身がありません。どうやら、これはFBXのバージョン違いによって起こる問題のようで、最新のFBX2012、また2011でも、同様の形式で書き出されてしまうようです。

ここでの対処法は、書き出し時のオプションで「FBX2010」を選択すればOKのようです。


この方法で、複数のFBXを書き出します。ここでは、「boy_idle」「boy_walk」の２つのFBXを書き出しました。


次に、１つメインのFBXを決めて、そこに他のFBXからのアニメーション情報のテキストのみをコピペします。スキンキャラクターのFBXとなると非常に長いテキストファイルになるのでちょっとわかりにくいのですが…


ここから


ここまで

をコピーして、


ここにペーストしました。アニメーションの名前が「Take 001」のままだと重複してしまうので、「Take 002」など、別の任意の名前に変えておきます。「Idle」「Walk」などわかりやすい名前にしておいたほうが良いでしょう。

テキストの編集が完了したら、ファイルを保存し、Unityにドラッグ＆ドロップしてみます。すると・・・


１つのモデルに２つのアニメーションを持ったFBXが読み込めました！！



＜追記＞

  • -

これは勉強会の後、（つい先程）試したのですが、
Projectビュー内でのドラッグ＆ドロップではなく、Hierarchyビューで「boy_idle」を選択
↓
Inspectorビュー内の「Animation」→「Size」をデフォルトの「1」から「2」に変更。すると「Animation」の項目に「Element 1　Take 001」が追加されます。「Element 0」には、Tale 001（idleのアニメーション）が最初から入っています。
↓
Projectビューの「boy_walk」ツリー内の「Take 001」を、「Element 1」の「Take 001」にドラッグ＆ドロップします。名前が同じなのでわかりにくいですが、こちらの「Take 001」は、歩きのアニメーションです。
↓
Inspectorビューの「Animation」の一番右にある○マークを押すと、再生するアニメーションを選択することが出来ます。これまた同じ名前「Take 001」で分かりづらいのですが…。

この方法で、Unity上で１つのモデルに複数のアニメーションを持たせることが出来ます。ただし、この方法では結局同一のモデルを複数読み込むことになりますので、ビルドした際のデータ量がどうなるのか（僕にはよくわかりませんが）、心配な所ではあります。試しにアニメーションのコピー元である「boy_walk」を削除すると、コピー先のアニメーションも消えてしまいました。結局、別モデルのアニメーションを参照しているだけなんですね。これで出来無くは無いけれど…決してベストとは言えない方法です。

  • -

５．まとめ

  • -

…目的は達成したものの、最初に述べたようにちょっとトリッキーな手法です。出来れば、maya、maxから直接複数アニメーションを書き出せないか、またはUnity上で複数アニメーションをジオメトリ１つに対して設定できないか、さらに検証したいところです。
例えば、ジオメトリを持たないFBXって書き出せないのかなあ…と思うのだけど、max、mayaのエクスポーターからは、必ずジオメトリ込みで書き出す必要があります。試しに骨のみで書き出したFBXをジオメトリ付きのFBXに適用してみたところ、

こんなふうに横向きになっちゃいました。（ジオメトリがあればよいってことは、何かダミーのモデルと合わせてエクスポートすればいいのかもしれない。後で試してみます。）

後、帰りの電車で勉強会参加者の一人に聞いた情報で、「Cheetah3d（チータ3D）」というソフトを使ったらどうか？みたいなお話しがあったのですが、これは初めて聞きました。ソフトの存在も含めて。
http://ja.wikipedia.org/wiki/Cheetah3D
http://www.cheetah3d.com/


今後も検証は続けるとして、ひとまず自前のキャラクターをUnityに読み込むことが出来ました。
次はこのデータをサンプルゲームに組み込んで、動かしてみたいと思います。

  • -

【勉強会】第１回 横浜へなちょこUnity勉強会②〜FBXに複数のアニメーションを持たせる。

イベント 書籍 Unity 3dsmax

前の記事の続きです。

http://atnd.org/events/20574

勉強会後半戦は、個人でそれぞれの課題に取り組むような感じ。僕はひととおり「Unity入門」の内容は（触りだけとは言え）終わってるので、次は自作のキャラクターを動かしたい！ということで、まずは3DソフトからUnityにアニメーション付きのモデルを持ってくることにしました。（この１ヶ月の間にホントはやっときたかったんだけどね…）

１．3DソフトからのFBXエクスポート

  • -

Unityコミュニティ内での標準ツールとしてはmayaを使用しているっぽいのですが、今回はアニメーションで使い慣れてるmaxを使用。サンプルキャラクターは、学校のローポリモデリング、アニメーションの授業で使用しているものです。（仮に「Boy」としましょう）

テクスチャが仮なので、まだ顔が描いてありません。ちょっと怖い。


Unityは.mbや.maxのデータを直接読むことも出来るらしいのですが、ひとまずそのへんの検証は後回しにして、3Dデータ交換形式の標準でもある「FBX」を使用します。最近、仕事でFBXを扱うこともあったので、FBXへの書き出し自体は特に問題になることはあリませんでした。


ファイル→書き出し

FBX形式を選択し、任意の名前をつける（ここでは「boy」にしました）

FBXエクスポートのオプションウィンドウで標準プリセットの「Autodesk Media&Entertainment」を選択してOKを押します。

  • -


２．UnityへのFBXインポート

  • -

次にUnityへのFBXインポートですが、これも特に問題無く出来ると思います。「Unity入門」Chapter6の内容を参考にすればOK。


先ほど作成した「boy.fbx」をUnityのProjectビューにドラッグ＆ドロップし、さらにProjectビュー内の「boy」をHierarchyビューにドロップしてプレハブ化すれば、Sceneビュー、Gameビューにキャラクターが表示されます。（テクスチャは別途読み込む必要あり）

Playボタンを押せば、アニメーションが再生されます。


ここで注意すべき点としては、maya、maxなどの3Dソフトであまりに小さすぎる、または大きすぎるキャラクターを作成した場合には、各ソフトでのFBXの書き出し時、もしくはUnityでの読み込み時に単位設定を調整する必要があります。今回のmaxのデータの場合、キャラクターを実寸で身長150cmくらいに作っておいたのですが、Unity単位ではおそらく1.5として読み込まれています。（Unityの単位の扱いはメートルを基準にしているっぽい）

max側でスケールを調整するには、FBXのエクスポートで「拡張オプション」→「単位」の項目で「自動」のチェックを外し、任意の単位を設定します。

ちなみに、標準のセンチメートルからミリメートルに変更してFBXを書き出すと、Unity上でのサイズは10倍になります。
※Unity向けに限った話では無いのですが、基本的にmayaでもmaxでも実寸を基準に作成していれば大きな問題は起きにくいかと思います。

Unity側でサイズ変更をする場合は、Projectビューでモデル（boy）を選択した状態で、Inspectorビューの「FBX Importor」→「Scale Factor」の値を変更します。


Scale Factor = 0.01（デフォルトの場合）


Scale Factor = 0.001に変更すると、サイズが1/10になる。

おそらく、この数値は１ｍを基準にして0.01ならcm、0.001ならmm単位で読み込まれるみたいだね。
ちなみに一番下の「Apply」ボタンを押さないと、変更が反映されないのでこれも注意！（けっこう知らないとはまります）


もう一つの注意点として、これはUnity入門にも書いてあるのですが、標準で読み込んだ場合には、アニメーションがループ再生されません。

これは、Inspectorビューの「FBX Importor」→「Animation」領域内の「Animation Wrap Mode」をデフォルト値「Default」から「Loop」に変更し、「Apply」ボタンを押せば、ループ再生されるようになります。



３．複数のアニメーションを持ったFBXのエクスポート

  • -

さて、ここからが問題です。Unity入門のChapter6では、サンプルのFBXが複数のアニメーションを持っています。

Idle、Walk、Jump、Crouchの４つのアニメーションを持っているのが分かると思います。


先ほどmaxから書き出したboy.fbxのアニメーションを見てみると、

「Take 001」という１つのアニメーションしか持っていないことが分かります。
（アニメーションの名前も、FBX書き出し時に自動的に上記に名前になるようです）

まあこれは当然で、そもそも mayaも maxも、１つのシーン内、１つのタイムライン上に複数のアニメーションを持つことはできません。
（アニメーションレイヤーという機能はあります。まだ試してはいないのですが…これは本来、複数のアニメーションを持たせるための機能ではありません。要検証。）


試しに、Unity入門のサンプルFBXをmaxに読み込んでみると…

確かに、FBXが複数のアニメーションを持ってる！…のですが、ここから1つだけを選択して読み込むことしか出来ません。
やはり、3Dツール上で複数のアニメーションを持つことはできないようです。


ひとまず、maxでboyに「idle」と「walk」の2つのアニメーションをそれぞれ別ファイルで作り、別のFBXとして書きだしてみました。


boy_idle.fbx


boy_walk.fbx（適当に作ったら、手足が同時に出ちゃってる…）


んで、これを同じUnityプロジェクトにドロップして、Unity内でアニメーションを複数もたせられないか…と思ったんだけど

やっぱり、個別のモデルにに個別のアニメーションとしてしか読み込まれないし、Projectビュー内でドラッグして別のモデルにアニメーションだけ紐付け出来るんじゃないかと思って試したけど、ダメですね。（何か方法はあるのかもしれないけど…）


ん〜こりゃどうしたもんか。
後で勉強会の主催者に聞いてみたら、前の記事で紹介したUnity本「Unityではじめるゲームづくり」では、複数のアニメーションを並列で持つ方法ではなく、タイムライン上に異なるアニメーションを直列に並べて、プログラム側でトリミングして使用している、とのこと。まあ、確かにこういう方法取る場合もあるけど、データ作り自体をそういうふうにする必要があるし、プログラム側でも処理がめんどいよな〜。やっぱり複数のアニメーションを持つ方法が、Unityでは最適解だと思うのだけど…。



また長くなったので、解決編は次の記事に。

  • -

【勉強会】第１回 横浜へなちょこUnity勉強会①〜プレゼン

Unity 書籍 イベント

今月もはるばる行って来ました横浜。
http://atnd.org/events/20574

前回の第0回は書籍「Unity入門」の読書会という趣旨だったのですが、今回からは特にお題は決めず、各自が発表やその場で勉強をするスタイル。

僕の今回の目的、というか自分に課したお題は「自分で作ったデータをUnityで動かす」です。「Unity入門」のChapter6のサンプルのような、スキンキャラクターを用いたアクションゲームが作りたいなと。そのテスト。
http://homepage3.nifty.com/ika-aki/CoinCrazy/WebPlayer/WebPlayer.html

  • -

今回、第1部としては主催者と参加者からそれぞれ１つずつプレゼンがありました。
※がっつりプログラムの内容なので細かい内容はよく分かりませんが、ピンポイントで我社のプログラマに見せたいので、その際のメモをのっけときます。Twitterのハッシュタグ「#yhunity」でまとめて見れますので、そちらも参照して下さい。
↓
http://twitter.com/#!/search?q=%23yhunity

最初のプレゼンは主催者の@fum1h1roより。主に、Unityにおけるコードの再利用について。

  • -

敵の動きをスクリプトで書く場合、全敵のスクリプトを描くのはつらい。解決策としては・・・

①コピペ

敵少なけりゃいいけど数百とかいたらダメでしょ

②クラス継承

・javascriptの場合・・・クラス定義どこにあるの？
→独自の継承の余地が無い。
→UnityのはJavaScriptではない。似てるだけ

・C#の場合・・・
→独自にクラス作って敵に継承できた。
→C#は通常C#に近い。制限は名前空間の使用禁止くらい

③クラスコンポジション

別のクラスからメンバとして呼び出せる。
→この方法がいい？

Unityはオブジェクトに対してコンポーネントを追加していくタイプ。


まとめ

・ゲーム制作では継承が敵作成（同じような処理だけどちょっと異なる処理）に有効
→GUIでも使い出がありそう。

・Unityのスクリプトは、別のスクリプトと合わせて使用することが出来る。
→パフォーマンスを上げるにはC#。
→JavaScriptとC#の混在でOK。

  • -

以上、わからないなりにメモってた内容なので、間違いあればご指摘下さい。


これらのコードの再利用については、「Unity入門」でも、最近発売されたUnity本「Unityではじめるゲームづくり」（既に先行販売中）でもあまり触れられていない部分だとのこと。その点、有意義なプレゼンだったのではないでしょうか。

Unityではじめるゲームづくり (ゲープロシリーズ)

Unityではじめるゲームづくり (ゲープロシリーズ)


２つめのプレゼンは「Pythonゲームプログラミング入門」の翻訳をされた@shinriyoさんからのプレゼン。（←2011/11/12 ご指摘により修正しました！）

「Unity Programing in Boo」と題して、スクリプト言語「Boo」のUnityでの使用についてお話し頂きました。後ほどどこかにスライドをアップして頂けるとのことなので、詳しい内容はそちらから見て頂ければと思います。

※2011/11/12追記！スライドをアップしていただきました！
http://www.slideshare.net/ShinsukeSugita/unity-programing-on-boo-10045689

Pythonゲームプログラミング入門

Pythonゲームプログラミング入門

以下、簡単なメモ。
↓

・Boo=Pythonもどき
→インデントが文法
→リスト内包表記もOK
→直接Vector3の値へ代入OK。

・日本で使ってる人はまず見かけない。
→海外だと、Boo使われてる（作者はブラジルの人）
→今後増えてく？そうでもない。
→作者がUnityで働いてるらしいので、今後サポートはされるだろう。

・Booの本が無い。どう学べばいいのか？

  • -

プレゼンの最後に「今後Unityでどのコードを使うか？」というアンケートが取られたのですが、

・JavaScript・・・やや少なめ
・C#・・・過半数
・Boo・・・１名

と、以外にC#の人が多かったです。


この後は、各自あるいは数人でまとまって勉強、となり、僕は前述のように「自作キャラクターを動かす」ための勉強をしてたのですが、内容がプレゼンと全く別になるため、次の記事に回します。

    • -