• 招待枠　　　：　１０名
• 応募枠　　　：　１２名
  計　　　　　：　２２名

＜ゲーム＞

• シアーはデータ量が増えるので基本的には扱わない。
• キーフレームの容量が増えるのでスケールは使いたくない。
• SSCやスケールはアトリビュートをロックして逃げている。
• スケールはゲームエンジンによって仕様などが異なる。
• プログラマーとシアーを出力できないか試行錯誤したことがある。
  不可能ではないがデータ量が多くなる、処理負荷などの問題で中止した。
• 疑似的なシアー表現をエンジンで再現することはある。

＜映像＞

• XSIの階層スケールは最高だった。
• 3dsMaxでは、SSCやインバーススケールのように親のスケール
  の影響を切ることができるが、それより上の階層からの影響も全て切れてしまう。
• Mayaの方がmatrixが使用できるので楽だと思う。
• シアーとスケールは難解。
• コントローラー開発ではまる時は大体がシアーとスケール。
• 骨の軸さえしっかりと設定されていればmatrixで何とか対応できる。
• 部位毎にスケールできる仕様を要求されることが多い。
  シアーとスケールの対応は必須。

◆仕様の違い
＜Unity＞

• インバーススケールを持ち込むことはできません。
• Segment Scale Compensate（以後SSC）は持ち込むことはできません。
• ３軸の均等スケールは可能です。

<Unreal Engine 4 >

• インバーススケールを持ち込むことは可能です。
• SSCは持ち込むことはできません。
• ３軸の均等スケールは可能です。
• スケールがXSIの階層スケールと似ています。

＜ゲーム＞＜映像＞

• Blenderは調査検証を含めて、モデリング作業で少し使用している。
• Blenderは気になるがまだ導入も検証もしていない（多数）。
• Blenderは様子見（多数）。
• BlenderはGUIが使い辛い。
• ゲームでもシミュレーション作業などでHoudiniを導入しつつある。
• Houdiniは背景制作で使用している。
• Houdiniは髪の毛のリダクションの自動化に使用している。
• 特定機能だけ使う。

＜映像＞

• クロスシミュレーションはリガーが兼任している。
• クロスの仕込みはシミュレーションチームが作業し、
  ショットとめり込み修正はリグチームがお手伝いしている。
• ガチのクロスシミュレーションは使用していない。
• SplineIKのカーブにヘアーを仕込んで簡易シミュレーションと手付けで対応している。
• 常に人員不足なので自動化して対応している。
• 揺らし用のリグの仕込みとパラメーターの初期設定はリガーが担当し、
  実際に揺らすのはアニメーションチーム。
• カーブを揺らすようなセカンダリーリグの簡単なシミュレーションは、
  アニメーションチームで対応してくれる。

＜映像＞

• クロスシミュレーションは使用せず、全て手付けで対応している。
• アニメーターから、全ての頂点にコントローラーが欲しいと要求されたことがある。
• クロスモデファイヤで対応している。
• アニメ案件だとコストではなく、表現力を重視して骨への手付けで対応している。
• Spring Magicを使用している。

＜ゲーム＞

• ジョイントベースで物理で揺れるシステムを使用している。
• ApexClothを使用している。
• 物理揺れの最終調整はテクニカルよりの人(TA/TD)でないと対応できないことが多い。
• ゲームでのめり込みの許容範囲は、ディレクターが良いと言えばOK。
• 骨にアニメーションをベイクして出力することもある。
• マント用の骨など、プリセット骨があればアニメーションの共有も可能。
• モバイルだと、基本的にベイクベースじゃないと処理負荷的に厳しい。

＜ゲーム＞

• 骨打ちとウェイト調整まではモデラーさんが担当。
  コントローラーの開発と設定はリガー、またはTA/TDさんが担当。
  骨の名前と軸に関しては、リガーが確認するようにしている。
• 骨打ちはリガー、ウェイト調整はモデラーさんが担当。
  ポーズで確認しつつモデルの修正といった作業が多い。
• 命名規則が守られていないことが多く、チェックコストが重い。（多数）
  インフルエンス数も守られていないことも多いので、細部までチェックする。
• リガーが骨の設計を行い、モデラーさんに仕様を伝えた上で骨打ち作業をしてもらう。
• とんでもない位置に骨が打たれていることも多い。軸もヤバい。
• 骨打ちもウェイト調整もモデラーさんが担当だが、
  骨に関しては入念にチェックしておきたいので自主的にチェックするようにしている。

＜ゲーム＞

• 現状はモデラーさんが骨打ちの作業を担当しているが、
  骨打ちに関してはリガーが担当するようにしたい。
• 専門のリガーが必要。

＜映像＞

• モデラーさんに骨を設定して欲しい。
  仮バインドしてポーズのチェックをすることで、
  プロポーションの違和感なども認識できるので。
• ボディリグ・フェイシャルリグの分業でコストが増えてきた。
  今後は統合する予定。

＜ゲーム＞

• やはり実機合わせでの制約が多く、デフォーマーが使えないのはしんどい。
• 実機で確認しながら再度モデル修正などの繰り返しも多い。
  処理負荷を考慮しての修正、変更も多いので映像とは制作フローが違う。
• プロシージャルアニメーションも多用されている。
• ゲームのフェイシャルは複数言語対応がおもしろい！

＜映像＞
◆[１体目１.５ヵ月+α]　MAYA（モジュラーリグシステム使用）

• 基本的には過去のアセットから流用する。
  ツールやモジュールがあるので体だけで１０日+α。
  流用しているが作品によりシルエットや体形がバラバラなので、
  調整に１０日以上かかることも多い。
• フェイシャルはツール化しているので、ウェイトのみの作業で５日前後。
  もちろん過去のアセットから仕様が変わると、修正や開発に数ヵ月かかることもある。
• 体のコントローラーは基本的には他の案件と同じなので自動生成。
• 髪や服のセカンダリーは１５日+α。
  アニメーターさんがショットで使う揺れものの初期パラメーター調整含む。
• ２体目以降は体とフェイシャルを合わせて６日前後。
  セカンダリーはデザインによるので１体目と変わらず１５日+αで考える。

◆[１体目１ヵ月+α]　MAYA（モジュラーリグシステム使用）

• 過去のアセットから流用する。
• 補助骨などは全てスクリプト、ツール化されている。
• 体のウェイト調整で２～３日。
• 規格が大きく変わるものは、修正や開発に１０日以上かかることも多い。
• 体のコントローラーは基本的には他の案件と同じなので自動生成。
• セカンダリーは１０日+α。
• フェイシャルリグはウェイト調整のみで１体５日前後。
• フルスクラッチだと別で開発工数としてガッツリ確保。
  

◆[１体２週間+α]　MotionBuilder / MAYA

• MotionBuilder用のリグ設定で２～３日。
• 補助骨などはありものを流用。
• Maya用のリグで５日前後。
• シミュレーションもリグチームが担当するので、服にコントローラーは設定せず、
  シミュレーションで対応と割り切ることで効率化を図っている。
• クロスの仕込みで５日前後。

◆[１体目 １～１.５ヵ月]　3dsMax

• 受託仕事だと求められるクオリティにより差はあるが１体目 １～１.５ヵ月。
• ２体目以降は５日+α。ものによる。
• 3dsMaxだとモディファイヤでアニメーターさんが調節できるので、
  デフォームを詰めて作業しないことも。

◆[１体目 ７日]　3dsMax

• 骨打ちとスキンは２～３日。
• 通年コントローラ開発をしているので、コントローラー設定に関しては１体３～４日。
• フェイシャルはショット側でツイークコントローラを作成するツールを開発。
  アニメーターさんに活用してもらっているので、リグ工数削減に繋がっている。

＜ゲーム＞
[１体目 ２～３か月]

• 開発期間が長いので、１体に対しての工数を試算するのが難しい。
• まずは実機に出力することが優先される。
• 命名規則や骨向きのルールを決めて、
  最低限動かせるプロトタイプとして２～３日で出す。
• その後、本格的に試行錯誤して作る期間として２～３か月。
• 人型以外は汎用性持たせてライブラリを作って流用。
  デザインによるが１体１~７日。
  

[１体 ７日]

• 既にあるモジュールと骨数が一致してれば、
  モジュールベースで作成したものの調整がメイン作業。
• 人型のコントローラー設定で０.５~１日。+セカンダリーをデザインにより追加。
• ユニークなモンスターなどの場合は１～５日と幅がある。
• フェイシャルはモデラーがツィーク骨を作って表情を作成する。
  それをターゲットにしてコントローラーを作成する。
  コントローラーはツール化しているので１日+α。

＜映像＞

• １体当たりで考えると作業工数が積みあがってしまうので、
  人だけ押さえてマイルストーンを設定する。
  ほかのタスクも対応しながら、フェイシャルリグ開発に半年ぐらいの期間をおさえる。
• テクニカル系の人は様々な業務に日々対応している。
  一つの業務、プロジェクトに専念しての開発は難しい。
  他セクションや制作はその点を考慮してスケジューリングしてほしい。
• モデラーさんやアニメーターさんとのやり取りもあるので、
  ある程度の期間を抑えてコントローラーを開発したい。
• アニメーターさんからのフィードバックが多いので、長めに期間を押さえる。
• 別案件の対応をしながら作業できる期間を押さえておく。
• 与えられた工数では、アニメーターさんからの要求に対応できない。
• 効率化のための開発期間を設けて欲しい。
• ８時間労働の工数で見積って欲しい。
• クリーチャーや特殊なアセットは数ヵ月かかることもある。
  

＜ゲーム＞

• 開発期間が長いので、リガーは出力のバグを探っていたり
  アニメーターさんのサポートしたり、リグではないことをしている。
• スクリプトが書けないとしんどいので、自分のために覚えた。
• そんな状況なので新人の育成や教育が難しい。
• ゲームは途中で仕様ががらっと変わって、再出力が発生することがある。
• 制作中も、差し替えは発生するものだと考えて制作している。

＜ゲーム＞＜映像＞

• アセットはリファレンスして使用している。（多数）
• 常に最新のものが提供されている状態。
• アセットはパイプライン上でバージョン管理をしている。
• 作業ファイルもモデル、リグのバージョンをそれぞれバージョン管理している。
  ビルドスクリプトで最新のデータを読み込んで構築する。
  共通領域で保存しているので引継ぎなども可能。
• ツールの古いバージョンも使いたいと言われると複雑に分岐させるしかなく頭痛の種。
• 最初のシーケンス終了後、バージョンロックして以後の作業とは切り離す。
  完了した個所への変更がかからないようにしている。
  仮に変更をかけたい場合も、その部分にだけパプリッシュしなおすことが可能。
• 他会社さんにツールを貸し出す時の為に、専用のバージョン管理システムを開発した。
• プラグインにバグがあっても、現状使用しているリグが壊れるような更新はしない。
  デフォルト挙動はバグがある状態のままにする。
  バグフィックス機能をON/OFFで切り替えられるようにアトリビュートを追加し、
  ユーザー側で選択できるように対応している。ツールを更新する際も同様。

＜ゲーム＞＜映像＞

• 会社やプロジェクトによって変わります。
• 宗教的なものが存在しており、考え方が色々あります。
• 規則に一貫性があり、説明できるものにする。
• プログラマー目線で考えて決める。
• 規則性が無いとプログラム処理する時に苦労する。

◆以下宗教

• 部位の名前を英語にする派（upArm など）
• 日本人なんだからローマ字派（ude など）
• アルファベットで数える派（beltA、beltB など）
• 数字で数える派（belt1、belt2 など）
• アッパーキャメルケース派（UpArmBelt など）
• ローワーキャメルケース派（upArmBelt など）
• スネークケース派（up_arm_belt など）
• 左右の識別子は大文字の「L」「R」派（arm_L など）
• 左右の識別子は小文字字の「l」「r」派（arm_l など）
• 左右の識別子は「Left」「Right」派（arm_Left など）
• 左右の識別子は「left」「right」派（arm_left など）
  ・・・などなど

＜ゲーム＞＜映像＞

• とにかくノードを繋いで遊んでみる。
• 社内に外国人が多いと、リグの文化も色々あり勉強になることが多い。
• Youtubeなどにアップされている動画を片っ端からみて勉強する。
• フリーのリグデータをダウンロードして解析する。
• セミナーに参加する。

＜学生＞

• 「Mayaリギング -正しいキャラクターリグの作り方- 」を読んで勉強しました。
• 本やネットのブログ記事などを参考にしています。