LoginSignup
1
3

More than 5 years have passed since last update.

パイプライン策定ガイドライン [WIP]

Last updated at Posted at 2015-06-23

About

パイプラインのデザインに関するガイドライン集。
随時追記&編集していくため[WIP]のままツッコミ待ちも含めて公開状態。

パイプラインの目的

基本的には自動化、合わせてデータの例外をなくす。

決められたルールにもとづいてデータが作成されることで、
必要とするデータの{特定/判別/生成}が可能になっている状態にする。
ルールが守られることで新たに追加されるデータも等しく処理できる。
※自動化要望は後から発生することも多い、その時どこまで徹底するかの判断も

  • XXなデータをXXしたい
  • XXでXXがXXならXXにする

最初にやること

  • 使用するツールを決定する
    • DCCツールやゲームエンジンなど必要なツール全て
    • ツールのバージョン(サービスパックの指定など)
    • ツールの言語(英語に統一がベター?)
    • ツールのインストールパスを決定する(基本統一)
    • ツールバージョンの更新ルールを決定する
  • データ構造と命名規則を決定する
    • データ格納パスを決定する(基本統一)
    • ファイル名、フォルダ名、ディレクトリ構造
    • データ名、データ構造(オブジェクト名含む)
  • 3DCGツール特有のルールを決定する
    • Y-Upにするか? Z-Upにするか?
    • Ascii/Binary?圧縮有無
    • 単位はcm?meter?inch?
    • 可能な限りスクリプトで設定を毎回チェックすること!
  • CGツール特有のルールを決定する
    • データ入出力フォーマット(FBXなど)
  • 以上の決定事項が外部協力会社でも守られるようにする

ファイル&ディレクトリ命名規則のポイント

  • ファイル名だけでもアセットをユニークに識別出来るようにする
  • ファイル名から格納先パスが構築できるようにする
     ※特に名前の省略するしないは基本統一する。
      仮にフォルダ名は非省略+ファイル名は省略とした場合、
      ファイルIDをフォルダ名にも含めるなどして機械的にフォルダが特定できること
  • 迷ったら自由桁はやめる。固定桁のIDに落としこむ。
    可変となる非省略形を採用してもアセット量が多い場合、識別力し易さは期待できない。
  • 全てのアセットが同じ規則に出来る方がいい。(キャラ、背景、エフェクト...etc)
  • 今良くても「何でもいい」は避ける。ルールを決めて自動的に名前が決まるようにしてみる。
  • ゲームの場合はバリエーションがよく発生する。(テクスチャ替え、モデル替えモーション共有) その場合もバリエーションであること、メイン素材が特定できる名称にすること。  ※CH01_V1, CH01_V2 や CH_01_01, CH_01_02など。   複数同時に使用される場合、末尾が 01などの連番にすると複製時の名称と衝突しやすい。

3DCGデータ構造のポイント

  • 同名オブジェクトは存在しないようにする
  • ジョイント、メッシュ、リグの区別がつくようにする
    • ジョイントにマテリアルが設定されているか判定できること
    • メッシュにマテリアルが設定されているか判定できること
    • メッシュ用ポリゴンなのか、スケルトン用のポリゴンか判定できること

DCCツールのバージョンを検討する

予想に反してバージョンを変えなければならないケースは無いか?

  • 途中から使用したくなったプラグインが対応していない
  • 既に新規購入ができないバージョンで、社内外のメンバーが増えてライセンスが不足する
  • 取引先の要求でバージョンを上げる必要になった

スクリプト作成で考えておくべき点

共通事項

  • そのスクリプトは個人で使うものか?チームで使うものか?
    • 複数のプロジェクトが混在しているか?
      プロジェクトによっては使わない?見えなくていい?
    • ** 社外や異なる環境にスクリプトを提供するか?**
      • ファイル名やメモリ上のデータが重複しないようにする
        ファイル名の先頭やフォルダ名に会社名を入れるなど
      • 出来る限りリソースをまとめて削除しやすくする
        きれいにアンインストールできるほうがいい!
      • 社外の人に見えていけないものを隠ぺいする
        ソースコードの中身やバージョン管理ツールのコメント
        社内で働く社外の人はいないか?
        ファイル名などにプロジェクト名がはいっていないか?
    • 開発用リソースとリリース用リソースが区別しやすいか?
      開発にのみ必要か?実行時に自動生成するのか?
      区別がしやすいとリリース作業が楽。
  • ローカライズの仕組みが事前に検討されているか?
    • 使用しているDCCツールにGUIをローカライズする仕組みはあるのか?
      ローカライズにはどのようなリソースを用意し、構造を維持しなければいけないか?
  • 容易に配布できるか?利用者が常に最新のツールがを利用しているか?
    • ファイルサーバーを全員で参照する?
    • SVNなどから自動で取得してくる?
    • インストーラーを作成する?
    • 勝手にツールがコピーして再配布されていないか?(古いバージョンが使われる!)

3dsMaxの注意点

  • Mayaと違ってツールリソースへの参照パスはたくさん追加できない。
    systemPath。additionalPath。PluginPath。
  • MaxUIに使用できるアイコンはMax起動後に任意のパスからロードは出来ない。
  • Max起動後にMCRをロードする場合、作成済みMenuやToolBarがUnknownに
  • 拡張メニュー用の画像はどのように用意したらいいのか?

まとめ中

  • パイプライン診断ツールがあったほうが良いかもしれない。  正しく環境が構築されていて、ツールが機能しているかのチェック&リポートツール。  特に外部会社や追加人員の環境構築で問題があった場合に発覚と調査が遅れるため。
  • Mayaなどが標準インストールパスにインストールされていないケース
  • バージョン管理サーバーが分かれていて変更を双方向同期しないといけないケース
1
3
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
3