Toolkit の新しい既定の設定の概要

はじめに

Toolkit の従来の設定が改良され、tk-config-default2 としてリリースされました。この設定は、Shotgun Desktop で高度なプロジェクト設定を指定する場合に既定の設定となります。この記事の目的は、新しい設定構成の概要を紹介し、従来の Toolkit 設定に慣れているユーザに共通する質問に答えることです。既存の設定を新しい構造に更新する方法に関する概要と、従来のパブリッシュ アプリから新しい Toolkit パブリッシャーに移行する上での注意事項が含まれています。新しいソフトウェア エンティティを使用し、また Shotgun Web にメニューを読み込むための新しいセットアップもサポートされます。

既定の設定とは

既定の設定は、Shotgun Desktop の特定のプロジェクトで高度なプロジェクト設定を実行すると、プロジェクトごとにインストールされます。


高度なプロジェクト設定で既定の設定を選択する

スタジオ固有のワークフローをカスタマイズおよび整理するためのテンプレートが提供されます。既定の設定には、プロジェクトのファイルが格納されるディスク上の場所を管理する既定のファイルシステム スキーマとテンプレートが付属します。また、3dsmax、Houdini、Mari、Maya、Motionbuilder、Nuke、Photoshop など、すべてのサポート対象の統合も含まれます。これらの統合は、DCC ごとにファイル管理、パブリッシュ、ワークフローのロードを行えるように設定されています。既定の設定は、Toolkit 管理者にリファレンスを提供するため、スタジオの完全なパイプラインを構築するための開始点として最適です。

既定の設定構成の使用をお勧めする理由

新しい既定の設定は、プロダクション環境を手動で選択する必要がある場合に効率性を最大限高められるようにクライアントのフィードバックと観測データに基づいて再調整されました。エンジンとアプリの共通設定の変更を 1 つのファイルに切り離すことができるインクルードベースの構造により、従来の設定における多くの冗長性が排除されています。 

変更内容を把握する

新しい環境ファイルの構造に関する概要については、こちらを参照してください。

管理者が変更内容を把握するのに役立つ新しい設定の構造コンポーネントがいくつかあります。

  • アプリ、エンジン、フレームワークの場所記述子が設定内の 1 つの場所にだけ格納されるようになりました。従来の設定では、アプリまたはエンジンのバージョンを更新するには、最上位の環境ファイルごとに変更が必要でした。すべてのアプリとエンジンの定義に、1 つの場所にある場所記述子が含まれるようになりました。このバンドル記述子ファイルは、 env/includes 内にあります。



    • app_locations.yml      # すべてのアプリの場所記述子がここで定義されます
    • engine_locations.yml   # すべてのエンジンの場所記述子がここで定義されます
    • frameworks.yml         # すべてのフレームワークがここで定義されます
  • エンジンとアプリに固有のすべての設定は、そのアプリまたはエンジン専用のファイル内で定義されます。従来の設定では、最上位の各ファイルですべてのエンジンとアプリの設定が定義されていました。新しい構造では、環境ファイルにエンジン固有の設定ファイルのエンジン設定が含まれます。 エンジン設定ファイルにはアプリ固有の設定が含まれます。これにより、さまざまなすべてのエンジンとアプリの設定が分離されるため、エンジンまたはアプリを更新する場所をさらに簡単に判断できます(つまり、エンジンまたはアプリの設定ファイルに移動)。たとえば、すべての環境における Maya の設定方法を変更するには、次のファイルを編集します:  env/includes/settings/tk-maya.yml。すべてのプロダクション環境における Publisher の設定方法を変更するには、次のファイルを変更します: env/includes/settings/tk-multi-publish2.yml。 

  • このアプリとエンジンの設定ファイル内には、アプリとエンジンのそれぞれの設定が複数存在します。設定の各バリエーションは異なる環境に含まれているため、環境に対応する設定コレクションを簡単に把握できるように名前が付けられます。たとえば、 settings.tk-maya.asset_step settings (tk-maya.yml 内)は、asset_step 環境の Maya エンジン設定を定義します。 



    同様に、 settings.tk-multi-publish2.nuke.shot_step 設定(tk-multi-publish2.yml 内)は、shot_step environment 内の Nuke のパブリッシャー設定を定義します。

  • 環境リファクタリング以外での設定に関する大きな変更は、従来の tk-multi-publish アプリから新しい tk-multi-publish2 アプリへのアップグレードです。新しい Publisher はスタンドアロンのパブリッシュ ワークフローをサポートします。また、新しい設定と併せて、旧式のテンプレートベースのワークフローに対するサポートを追加するように更新されています。新しい Publisher の詳細については、『統合ユーザ ガイド』または『統合開発者ガイド』を参照してください。


    Shotgun Publisher

中心となるスキーマとテンプレートの多くの部分は、新しい設定ではほとんど変更されていません。一連の変更は、環境ファイルの構造と構成およびそれに付属する設定に関するものです。

エンジン設定

エンジン設定は、すべての環境におけるそのエンジンの設定を定義する設定ファイルとして切り離されました。たとえば、env/includes/settings/tk-maya.yml ファイルはすべての環境で使用する Maya の全設定を定義します。次の図は、プロジェクト環境の Maya の設定を示しています。

ここでは、menu_favourites などのエンジン レベル設定を、どこで変更できるのかを確認できます。 また、アプリの参照をここに追加することもできます。既定では、アプリ固有のファイルからすべてのアプリが含まれます。この構造により、管理者は 1 つのファイル内ですべての環境におけるエンジンの設定方法を確認できます。

アプリ設定

エンジン設定と同様に、アプリ設定がすべての環境におけるそのアプリの設定を定義する設定ファイルとして切り離されました。たとえば、 env/includes/settings/tk-multi-publish2.yml ファイルはすべての環境で使用する Publish2 のすべての設定を定義します。次に、shot_step 環境内の Maya の Publish2 設定を表すスニペットを示します。

ここで、対象環境のアプリ固有の設定(エンジン設定ファイル内に含まれる)を変更する方法を確認できます。この構造により、管理者は 1 つのファイル内ですべての環境におけるアプリの設定方法を確認できます。

ソフトウェアのパス

従来の設定内にあったenv/includes/paths.yml ファイルは、env/includes/software_paths.yml に名前が変更されました。これらのファイルの構造は同じですが、新しい設定で定義するソフトウェアのパスの数はかなり少なくなりました。これは、Toolkit でソフトウェアのパスを最適に解決するには、Shotgun でソフトウェア エンティティを使用する必要があるためです。 


Shotgun に表示されるソフトウェア エンティティのエントリ

ソフトウェア エンティティとスタジオに適したカスタマイズの詳細については、ここを参照してください。

環境ファイル shotgun_*.yml の削除

環境ファイル shotgun_*.yml は、以前 Shotgun Web アプリの Toolkit アクション メニューで利用できる Toolkit アクションを設定するために使用されていました。現在は、このような追加の環境ファイルの使用を止め、代わりに他のエンジンすべての設定方法と同じように tk-shotgun  エンジンを設定するようになりました。Toolkit アクションを必要とするエンティティの各タイプに shotgun_xxx.yml ファイルを使用する代わりに、project.yml や shot_step.yml など、より一般的な環境で Shotgun エンジンの設定を使用し、pick_environment コア フックの環境を手動で選択するようになりました。この目的は、より標準化された設定を使用することで、Toolkit ブラウザ統合に関する特別な動作を取り除くことです。ブラウザ統合に対するこの変更には下位互換性があるため、既存の設定はこれまでどおり引き続き機能します。

削除: app_launchers.yml

アプリ ランチャーの定義が env/includes/settings/tk-multi-launchapp.yml ファイルに移動されました。このため、さまざまな環境のアプリ起動設定が新しい設定構造と一致するようになります(各アプリとエンジンには独自の設定ファイルがあります)。また、アプリ起動設定の多くは、ソフトウェア エンティティによって実装された自動検出可能アプリ起動を使用するため削除されました。詳細については、ソフトウェア エンティティのドキュメントを参照してください。 

従来の既定の設定を使用する

従来の既定の設定は Shotgun Desktop の高度なプロジェクト設定を介して引き続き使用することができます。また、GitHub リポジトリも引き続きダウンロードに使用できます。さらに、従来の既定の設定は、最新のアプリ、エンジン、およびフレームワークで更新されるため、新しい既定の設定と一致しバージョンも認識します。 

既存の設定をマイグレートする

tk-config-default2 の最新リリースに伴い、既存の設定をこの新しい編成構造に変換することに興味を示しているクライアントがいます。次のセクションでは、この変換方法について説明します。

このプロセスは完全に任意です。既存の使用可能な設定は変更を行わなくても引き続き機能します。 

また、既存の設定から新しい構造へのマイグレートは、手動による高度なプロセスであるため、従来の Toolkit 設定構成、git、および tank シェル コマンドを十分理解している必要があります。慎重に進めてください。ここに防護柵はありません。

tk-config-default2 の使用

既存の設定をマイグレートするには、始めに、Shotgun で新しいテスト プロジェクトを作成して、Desktop の高度なプロジェクト設定を使用し、プロンプトが表示されたら新しい既定の設定を選択することをお勧めします。これにより、変更可能で有効な新しい設定が提供されます。

次に、環境設定ファイルなど、新しい設定構成を理解します。新しい構造の詳細については、この README および上記セクションを参照してください。

未使用のアプリとエンジンをクリーンアップする

新しい構造を十分に理解したら、スタジオで使用していないエンジンとアプリを削除する必要があります。このためには、アプリとエンジンの不要な設定ファイルを env/includes/settings フォルダから削除する必要があります。また、残りのエンジン設定ファイルから未使用のアプリのリファレンスを削除し、最上位の環境設定ファイルから未使用のエンジンのリファレンスも削除する必要があります。

たとえば、スタジオで tk-nuke-quickdailies アプリを使用しない場合は、Nuke エンジン設定ファイルからの上記のハイライトされた行を削除します。

同様に、スタジオで Motionbuilder を使用しない場合は、上記のハイライトされた行と tk-motionbuilder.yml のインクルードを削除する必要があります。上図は project.yml ファイルの一部です。最上位の複数の環境設定ファイルから未使用のエンジンの削除が必要になる場合があります。

また、env/includes/*_locations.yml ファイル内の場所ファイルから未使用のエンジンとアプリの記述子も削除する必要があります。

Motionbuilder エンジンを削除するには、 engine_locations.yml ファイルで定義されている場所の記述子を削除する必要があります。未使用のアプリの場所の記述子が app_locations.yml から削除されます。

付属する統合の設定を更新する

これにより、スタジオで使用する付属の統合のみが残された状態の設定になります。残っているアプリとエンジンの設定を更新して既存の設定と一致させる必要があります。

上図はアセット コンテキストの tk-nuke-writenode 設定です。既存の設定で異なるテンプレートやカスタムのテンプレートを使用したり、または別の write_nodes を追加する場合があります。既存のすべてのアプリ設定を点検して、異なる設定、見つからない設定、更新する設定を適切に特定する必要があります。さらに詳細な設定が必要になると、エンジン設定ファイルに含まれる別の設定ブロックの追加が必要になる場合もあります。

: 新しい既定の設定構成はわずかな設定だけを元に構築されているため、すべての設定が新しい構成内に存在するわけではありません。必要に応じて、設定に使用されている設定を追加できます。

ソフトウェア エンティティを使用するように更新する

新しい設定を使用すると、Shotgun のソフトウェア エンティティを介してほぼすべてのソフトウェアを起動できます。付属の統合を更新すると、env/includes/settings/tk-multi-launchapp.yml ファイルが表示される場合があります。

このファイルでは、設定内のすべてのソフトウェア ランチャーが定義されています。

Screen_Shot_2017-12-04_at_2.49.50_PM.png

上図の上部セクションには、起動アプリのソフトウェア エンティティ設定を使用するためのセットアップが表示されています。下部セクションには、残りの手動によるソフトウェア ランチャー設定が表示されています。可能な場合は、ソフトウェア エンティティ セットアップを使用することをお勧めします。既存の設定のカスタム ソフトウェア起動をこのファイルにマイグレートし、適切なエンジン設定ファイルから参照する必要があります。 

ソフトウェア エンティティ ランチャーを使用して変更を実装した場合は、tk-multi-launchapp で関連するエンジンにアクセスする必要があります。ローカル マシンでソフトウェア インストールをスキャンするロジックは、さまざまなエンジン内に格納されています(tk-maya は Maya インストールなどの検出方法を把握しています)。その結果、ソフトウェア エンティティ ランチャーを使用できるように tk-desktop または tk-shotgun を設定した場合は、必要なすべてのエンジン インスタンスを同じ環境内で利用できる必要があります。

上図では、プロジェクト環境用に設定したエンジンを示します。Shotgun Desktop はハイライト行に含まれていることが分かります。ソフトウェア エンティティ ランチャーを介して Desktop から起動するソフトウェアの場合、ここで関連するエンジンが設定されています。Maya、Nuke、Photoshop など、ソフトウェア エンティティベースの起動をサポートする他の DCC エンジンもここで設定されています。従来の既定の設定に含まれる古い shotgun_xxx.yml ファイルを使用する場合は、tk-shotgun エンジンのみを設定する必要があります。 

設定を検証する

シェルで検証コマンドを実行して、任意の時点で設定をテストすることで、環境設定ファイルが有効かどうかを確認できます。

./tank validate

または

./tank validate asset_step

カスタム アプリとエンジンを追加する

次に、付属物に含まれないがスタジオで使用するエンジンまたはアプリ、および既定の設定を環境設定ファイルに追加します。最初に、app_locations.yml ファイルと engine_locations.yml ファイルに場所の記述子を追加します。次に、既存のアプリとエンジンの設定ファイルを参照し、新しいアプリとエンジン用の設定を挿入します。最上位の環境設定ファイルで追加されたエンジンがある場合は必ず参照してください。

テンプレートとスキーマをコピーする

既存の設定の templates.ymlschema フォルダを上書きコピーし、新しい設定のフォルダと置き換える必要があります。


設定内のスキーマ フォルダと templates.yml ファイル

スタジオの template.yml を更新する必要がある場合のために、新しい設定に含まれる既定の templates.yml のコピーを保存しておくことが必要な場合があります。これにより、付属の設定からコピーしたアプリとエンジンで指定された新しいテンプレートを取得して評価し、スタジオで機能するように使用または変更する必要があるかどうかを確認できます。

最上位の環境を更新する

スタジオで「エピソード」または「プレイリスト」などのカスタム環境を使用する場合は、環境フォルダ内にも対応する環境設定ファイルを必ず作成してください。

上図は最上位の環境設定ファイルです。たとえば、 publishedfile_version.yml は default2 設定にとって新しいファイルです。これには、PublishedFile のメニュー項目と Shotgun のバージョン エンティティ メニューを表示する 2 つの役目があります。カスタム環境を移行する場合は、このファイルと他の最上位の環境設定ファイルを参照として使用します。

また、カスタム環境に合わせて pick_environment フックを変更する必要もあります。カスタム pick_environment フックを既に使用している場合は、既存の設定からコピーすることができますが、新しい既定の設定に付属するフックと比較して、すべての環境設定ファイルが定義されていることを確認する必要があります。

上図には、以前の図の publishedfile_version.yml ファイルを使用するのに関連する default2 フックの句が表示されています。

フレームワークを更新する

次に、スタジオで必要なカスタム フレームワークを含むように frameworks.yml ファイルを更新します。


  frameworks.yml ファイル( env/includes フォルダ内)。

このファイルは最上位の環境設定ファイルに常に含まれているため、適切な記述子を追加するだけで十分です。

上図は、最上位の shot.yml ファイルに含まれているフレームワークです。含まれているフレームワークは、この環境内のすべてのエンジンとアプリで使用できます。 

入力ミスや設定不足がないかを確認するには、検証を再び実行するのが最適です。

フックを更新する

最後に、古い設定で定義されているカスタム フックを上書きコピーする必要があります。これには、コア フックおよびアプリとエンジンのフックが含まれます。これらのフックはいくつかの例外を除いて継続して機能します。


既存のフックを新しい設定のフック フォルダにコピーする

初めてソフトウェア エンティティを使用し、既存の tk-multi-launchapp フックを定義している場合は、カスタマイズが予想どおりに機能していることを何度か確認する必要があります。主な違いは、起動するソフトウェアのエンジン名を特定するために起動アプリの設定を確認するとき、従来のフックに依存する点です。新しいソフトウェア エンティティベースを起動しても、この値は設定されません。その機能に依存するフックを更新する必要があります。起動アプリ フックは、更新がごくわずかとなるよう追加の引数としてエンジン名をフックに指定するようになりました。 

同様に、tk-multi-launchapp の defer_keyword 設定はソフトウェア エンティティ設定では使用されません。カスタムの遅延フォルダ作成でこの設定を使用している場合は、手動による起動方法を使用して続行する必要があります。

カスタム tk-multi-publish (publish1)フックは tk-multi-publish2 (publish2)と一緒に使用できません。上記手順で新しい設定に従来のパブリッシャーを手動で追加した場合、フックは問題なく動作します。ただし、publish2 にアップグレードする場合は、新しい publish2 プラグイン システムにマイグレートするための追加作業が必要になります。個別のタスクとしてマイグレートに取り組みことをお勧めします(設定のマイグレートは時間のかかるタスクです)。このパスを下に進む準備ができたら、次のセクションでその注意事項を参照してください。

この時点では、新しい構造を使用して設定を注意深く操作している必要があります。エラーがなくなるまで、検証と調整を実行することをお勧めします。その後、新しいプロジェクトを使用して設定をテストし、すべてが希望どおりに機能していることを確認できます。 

publish1 から publish2 にマイグレートする

コードと設定の新しいパラダイムへのマイグレートは手動のプロセスで、スタジオごとに異なります。以下の説明の目的は、予期される結果と publish1 コンセプトから publish2 コンセプトへの変換方法に関するいくつかのヒントを提供することです。

: publish1 から publish2 へのマイグレートは、新しい設定構造の使用とは関係ありません。有効な Toolkit 設定でどちらのパブリッシャーも使用できます。  

publish2 コンセプトを理解する

publish2 を使用するために既存の publish1 フックをマイグレートする準備が完了し、publish1 で定義したコンセプトに問題がなければ、新しいパブリッシャーとその API のコンセプトを理解する必要があります。詳細については、『統合開発者ガイド』を参照してください。特に、publish2 のフェーズ(特に承認フェーズ)、コレクタ フック、およびパブリッシュ プラグインを理解することは重要です。このガイドを確認して、publish1 フック構造を理解したら、変換のパスが明確になるはずです。

publish1 と publish2 の主な違いを次の図に示します。

publish1.png
publish1 フックと項目の関係図


publish2.png

publish2 プラグインと項目の関係図

ここでいくつかの違いを箇条書きにして明確にします。カスタム フックをマイグレートする前にこの内容を検討してください。

  • publish2 でパブリッシュする項目は collector フックで作成されます。これは publish1 の scan_scene フックに対応します。上図の緑のボックスを参照してください。 
  • publish2 には、プライマリ パブリッシュとセカンダリ パブリッシュを比較するコンセプトがありません。あるのはパブリッシュする項目のみです。上図の青のボックスを参照してください。
  • publish1 では、pre_publishpublish、および secondary_publish フックの動作は静的かつ事前定義済みです。publish2 では、1 つの項目で任意の数のパブリッシュ プラグインが動作し、プラグインのフェーズはプラグインのメソッド(validatepublishfinalize)で定義されます。 上記の tan ボックスを参照してください。
  • Publish2 は、継承を使用できる新しいスタイルのフックを使用します。付属の publish2 フックを確認すると、アプリの 1 つのベース クラス プラグイン内にコア パブリッシュ ロジックがどれだけ存在するかが分かります。

その他:

  • 1 つまたは複数のパブリッシュ プラグインは、収集した項目がプラグイン上で動作するのを許可します 
  • publish2 のコレクタ フックとパブリッシュ プラグインには、動作を管理するフック単位の値の定義に使用される設定のコンセプトが指定されています。たとえば、パブリッシュ時にファイルをコピーする場所を把握できるようにプラグインのパブリッシュ テンプレートを定義します。
  • エンジン固有の publish2 コレクタとプラグインはエンジン自体と一緒に使用します。これは tk-multi-publish2.yml 設定ファイルの {engine} トークンを検索すると分かります。
  • 再利用可能な基本コレクタとパブリッシュ プラグインは tk-multi-publish2 アプリと一緒に使用します。
  • ベース ファイル パブリッシャーは、ディスク上でファイルをパブリッシュするための共通ロジックをすべて処理できるように設計されています。インプレイス パブリッシュまたはテンプレートベース パブリッシュを処理できます。 
  • 付属の統合は基本コレクタとファイル パブリッシュ プラグインから継承を行い、一般的に使用されるパブリッシュ ロジックの重複を回避します。

publish1 から publish2 に設定を変換する

publish1 の設定を厳密に見ると、publish2 への変換方法に関していくつかの注意点があります。

  • display_name: publish2 では現在利用できません(現在作業中)
  • hook_thumbnail: DCC 固有のサムネイルの生成はセッション コレクタ プラグインによって定義されますが、publish2 に対応するフックがありません
  • hook_copy_file: ファイルのコピーは、既定ではベース パブリッシュ ファイル プラグインによって処理されます。カスタム パブリッシュ プラグインはファイルをコピーするように作成できますが、publish2 に対応するフックがありません。
  • primary/secondary フック: 前述のとおり、publish2 のプライマリ パブリッシュとセカンダリ パブリッシュには違いがあります。カスタム スキャン シーン ロジックはコレクタ フックにマイグレートする必要があります。カスタムのプリロジック、パブリッシュ ロジック、ポストロジックは、パブリッシュ プラグイン内に実装する必要があります。 
  • primary_*: プライマリの scene_item_typedisplay_namedescription、および icon 設定は、publish2 の項目コンセプトによってすべて定義されます。項目がコレクタによって作成されると、値が指定され、UI に表示されます。
  • secondary_outputs: 2 番目の出力は、publish2 の収集フェーズ中に作成された単なる別の項目です。現在の Maya セッションのように「プライマリ」項目の兄弟として表示したり、階層下に子として関連付けて必要な関係タイプを推測できます。 
  • expand_single_items: コレクタ フックは UI の項目の定義方法を定義できます。
  • allow_taskless_publishes: 項目はパブリッシュ時に関連付けられたコンテキストを定義できます。コンテキストはコレクション時に決定したり、ユーザが手動で定義できます。パブリッシュ プラグインは、検証メソッドでタスクをパブリッシュしなくても項目を許可できるかどうかを決定できます。
  • templates: テンプレートはコレクタまたはプラグインの設定で定義できます。テンプレートの使用方法の定義はコレクタとプラグイン次第です。

publish2 プラグインの追加資料

次に、プラグインの publish1 から publish2 への移行に役立つその他のリソースを示します。

  • tk-config-default2publish2 設定ファイルは、新しいパブリッシャーの設定方法を確認するのに最適です。スタンドアロン パブリッシャーの基本コレクタとファイル パブリッシュ プラグインを設定する方法を確認できます。また、このように同じフックが DCC 固有の設定によってどのように継承および使用されるかを確認できます。 
  • 基本コレクタは、ドラッグ アンド ドロップされたファイルがパブリッシュの項目に変換される方法、およびファイル拡張子の変換ロジックが項目タイプに変換される方法を定義します。
  • ベース ファイル パブリッシュ プラグインは、テンプレートの処理方法、Shotgun でのパブリッシュの登録方法、パブリッシュ タイプの定義方法など、ディスクでファイルをパブリッシュするためのロジックの大部分を定義します。
  • Maya 固有の publish2 フックも、DCC 固有のコレクションとパブリッシュの処理方法を確認できる優れた資料です。これらのフックは Maya エンジンのリポジトリ内に格納されており、現在のセッション、以前に書き出したプレイブラスト、alembic キャッシュ、セッション ジオメトリを収集およびパブリッシュするためのロジックが指定されています。 

結論

上記の手順が、新しい設定構成と既存の設定からそこに移行する方法を理解する上で役立つことを願っています。新しい設定に関する質問がある場合やマイグレート手順に関する説明がさらに必要な場合は、support@shotgunsoftware.com までお問い合わせください。 

フォローする

0 コメント

ログインしてコメントを残してください。