Toolkit の概要

  1. Shotgun サポート
  2. Shotgun 管理者ガイド
  3. 統合の詳細ドキュメント

Shotgun Pipeline Toolkit のさまざまなコンセプトの概要です。

ここでは、アプリとエンジンの仕組み、Toolkit の起動方法と現在のコンテキスト(作業領域)の管理方法、ディスク上にフォルダを作成する方法など、主要なコンセプトについて詳細に説明します。環境設定と開発に関与するユーザはここから始めることをお勧めします。
このドキュメントは、Toolkit の設定を管理するユーザのみが使用可能な機能について説明します。詳細については、『Shotgun 統合管理者ガイド』を参照してください。

目次:

はじめに

プロジェクトと環境設定

      独自の環境設定を展開する

      プロジェクトごとにパイプライン設定を指定する

      更新を確認する

      Core API の更新を確認する

ディスク上にフォルダを作成する

現在のコンテキスト

ファイル システム テンプレート

実行するエンジンとアプリを選択する

      既定の設定での環境

      Shotgun 環境 - コンテキスト メニューを設定する

アプリを設定する

      フック

Shotgun とシェルから実行する

Shotgun にパブリッシュする

再利用可能なアプリを作成する

セキュリティと認証

      Core v0.16 にアップグレードする

      認証とプロンプト

            グローバル スクリプト キーを使用する

            Shogun にログインする

            非インタラクティブ環境で実行する

      技術の詳細

            Shotgun 認証ライブラリ

            Shotgun の認証と権限

            Toolkit のシリアル化

            ファイルの場所

            マルチスレッド環境

Toolkit の技術詳細とその他

はじめに

Shotgun Pipeline Toolkit の詳細を知りたいですか? ここは、それにぴったりの場所です。このドキュメントでは、いくつかの主要機能の詳細について説明します。説明、例、簡単なデモを使用して、Shotgun Toolkit のすべてを紹介します。このドキュメントは、Toolkit に慣れる方法や、Toolkit がスタジオにどのような付加価値を与えるのかを理解するのに最適です。すべての内容を確認すれば、いくつかの主要なコンセプトとそのコンセプトの仕組みを理解できます。

次に、Shotgun Pipeline Toolkit (Sgtk)の簡単な説明を示します。

  • Sgtk は Shotgun プラットフォームに基づいた Pipeline Toolkit です。これを使用すると、スタジオでツールを作成してインストールすることが非常に簡単になります。
  • Sgtk はファイル システム ベースのツールです。ディスク上での格納場所を整理できるため、ディスク上で管理するものを適切に構造化できます。
  • Sgtk は一種のアシスタントです。パイプライン内のデータの占有や抽出は行いませんが、情報を簡単に検索してミスを防ぐための優れたツールをアーティストに提供します。
  • Sgtk は共有をサポートします。すべてのパブリッシュが Shotgun に保存されるため、制作上の更新と作業を簡単に共有できます。

次のセクションでは、Shotgun Pipeline Toolkit の詳細とその仕組みを確認します。

プロジェクトと環境設定

Shotgun Pipeline Toolkit では、すべてがプロジェクト中心になっています。Shotgun では通常、入札段階からプロダクション前の段階までをプロジェクトのライフ サイクルとして扱います。プロジェクトのコンテンツ作成フェーズの準備が完了したら、Toolkit でこのプロジェクトをセットアップすることができます。

新しいプロジェクトをセットアップする場合は、テンプレート設定を使用します。これは、エンジン、アプリ、ファイル システム設定、およびその他の設定を含む定義済みの設定です。Toolkit を初めて使用する場合は、確認用としてまずはサンプルの設定を使用することができます。別のプロジェクトで Toolkit を既に使用したことがある場合は、新しいプロジェクトの出発点としてこの設定を使用することをお勧めします。この方法では、スタジオの設定を展開して、それぞれの新しいプロジェクトに合わせて調整できます。もちろん、スタジオの設定を個別に管理し、新しいプロジェクトすべてのテンプレートとして使用することもできます。

それぞれの設定を使用して、数多くのストレージ ポイントを定義します。標準のサンプル設定「tk-config-default」の場合、プライマリと呼ばれる 1 つのストレージ ポイントを定義します。つまり、すべてのプロダクション データは 1 つのファイル システムのプロジェクト ルート内に格納されます。また、複数のファイル システムのルートを使用して設定をセットアップすることもできます。これは「マルチルート設定」と呼ばれます。マルチルート設定が必要な例としては、レンダリングや編集用の個別ストレージを設定する場合などがあります。各ストレージ ポイントは Shotgun のローカル ファイル ストレージとして存在する必要があり、これは[サイト基本設定](Site Preferences)の[ファイル管理](File Management)タブでセットアップできます。

Shotgun Toolkit では、実際のプロジェクト設定を任意の場所にインストールできます。通常、これは、プロジェクトのデータを格納する場所ではなく、ソフトウェアをインストールした場所になります (場所に問題がある場合は、後でいつでも変更できるので心配はいりません)。

独自の環境設定を展開する

新しいプロジェクトをセットアップする場合は、既存のプロジェクトをベースにすることができます。Shotgun Toolkit はこのプロジェクトから新しいプロジェクトに設定フォルダをコピーします。つまり、新しいプロジェクトは、アプリとエンジンのバージョン、設定、およびカスタマイズが元のプロジェクトとまったく同じになります。これは、パイプラインを展開し、既存のプロダクションの一部として行った改善と調整を活用する場合に役立ちます。

また、プロジェクトのセットアップに問題がなく、一元的に保存する場合は、プロジェクトの設定フォルダを使用するだけです。この設定はスタジオのテンプレートとして使用することができ、新しいプロジェクトを作成するたびにこの設定をベースにすることができます。必要に応じて、git などを使用すると、このスタジオ テンプレート設定をソース制御することもできます。パイプライン設定テンプレートの一定期間の展開方法をトラッキングすることで、シンプルで分かりやすくなります。更新する場合は、1 つのプロジェクトから設定をコピーして変更をコミットするだけです。

設定管理の詳細については、次の詳細ドキュメントを参照してください。

> プロジェクト設定を管理する

プロジェクトごとにパイプライン設定を指定する

プロジェクトに対して Shotgun Toolkit をセットアップすると、パイプライン設定が作成されます。この設定にはプロジェクトに必要なすべての設定とファイルが含まれています。この設定には専用の tank コマンドが用意されており、プロジェクトを直接操作する場合はシェルで実行できます(すべてのプロジェクトで動作するグローバルな tank コマンドもあります)。Shotgun では、ディスク上のプロジェクト設定の格納場所を簡単にトラックできるように、パイプライン設定が特別なパイプライン設定エンティティとして登録されています。

プロジェクトのセットアップ時に作成されるマスター設定とは別に、プロジェクトの追加設定を作成できます。これは、プロジェクトのユーザに影響を与えることなく設定に変更を加える場合に役立ちます。このためには、Shotgun でパイプライン設定にアクセスして右クリックするとクローンを作成できます。これにより、他の設定に基づいてプロジェクトの新しいパイプライン設定が作成されます。この新しい設定を使用すると、他のユーザに影響を与えることなく、新しいアプリなどを安全にテストすることができます。

プロジェクトのメイン設定は Primary という名前にする変更する必要があります。この設定の名前を変更したり、修正または削除した場合、予想どおりに動作しなくなる可能性があります。Shotgun に保存されているパイプライン設定は、手動ではなくさまざまな特定の tank 管理コマンドを使用して操作するため、既定では読み取り専用です。

例: 環境設定のクローンを作成する方法

更新を確認する

一般的な他のアプリと同様に、Shotgun Toolkit アプリ ストアにはアプリとエンジンの新しいバージョンが常に用意されています。これらの新しいバージョンには、重要なバグ修正や新たな素晴らしい機能が含まれている場合があります。アプリとエンジンのアップグレードは省略可能です。通常、このプロセスは非常に簡単で、変更を加える前にはアップグレード スクリプトによって必ずプロンプトが表示されます。同様に、誤って不要なバージョンをインストールした場合も簡単にロールバックできます。

アップグレード プロセスは 1 つのコマンドで処理します。プロジェクト設定フォルダ内にある tank コマンドを実行して、パラメータ updates を追加するだけです。

> /software/shotgun/bug_buck_bunny/tank updates

パラメータを設定せずにこのコマンドを実行すると、すべての環境、エンジン、およびアプリがチェックされます。これには時間がかかります。また、インストールしたアプリとエンジンのサブセットで更新ツールを実行することもできます。

一般的な構文:

> tank updates [environment_name] [engine_name] [app_name]

特別なキーワードである ALL を使用すると、カテゴリ内のすべての項目を指定できます。以下に例を示します。

  • すべてをチェックする: tank updates
  • ショット環境をチェックする: tank updates Shot
  • すべての環境内のあらゆる Maya アプリをチェックする: tank updates ALL tk-maya
  • ショット環境内のあらゆる Maya アプリをチェックする: tank updates Shot tk-maya
  • Loader アプリが常に最新の状態を維持するようにする: tank updates ALL ALL tk-multi-loader
  • Loader アプリが Maya で最新の状態を維持するようにする: tank updates ALL tk-maya tk-multi-loader

アプリ ストアの確認に加えて、このスクリプトは登録された他のすべての場所もチェックするため、展開されたアプリの場所に応じて、ローカル git、Github リポジトリ、ディスク上のファイル、およびアプリ ストアをクエリーする可能性があります。

新しいバージョンのアプリを導入すると、アプリ設定が変更される場合があります。たとえば、新しい機能で新しい設定パラメータが必要になる場合があります。この場合、tank アップグレード スクリプトは、このパラメータに値を入力するためのプロンプトを表示します。

Core API の更新を確認する

オートデスクは、必要に応じて Toolkit Core API の新しいバージョンをリリースします。Core API の更新には個別のコマンドを使用します。この場合のコマンドは tank core です。

ディスク上にフォルダを作成する

Shotgun Pipeline Toolkit でプロジェクトをセットアップすると、Toolkit を使用して一貫性のあるフォルダ構造を作成できます。ディスク上でパイプライン設定の一部としてファイル システム テンプレートを作成すると、このフォルダ構造が設定されます。このフォルダ構造ではいくつかのパスが動的になります。たとえば、Shotgun アセットを表す asset と呼ばれるフォルダを設定するとします。この動的なフォルダは Shotgun クエリーと他の多くの項目に接続できます。

Shotgun Toolkit には、異なるセットアップとシナリオを処理するさまざまな動的フォルダ タイプが数多く用意されています。フォルダ作成時に標準的な Shotgun API クエリー構文を使用すると、異なるアセット タイプのアセットがファイル システム上のさまざまなフォルダに格納されるようにファイル システムを整理することなどもできます。この操作方法については、管理者ガイドを参照してください。

> Shotgun Pipeline Toolkit を管理する

Shotgun Pipeline Toolkit のフォルダは 2 つのパスで作成されます。すべてのユーザがいつでも実行できるダイレクト パスと、通常はアプリケーションの起動直前にアーティストが実行する遅延パスです。この遅延パスは完全に自動で、アプリケーション固有のフォルダとユーザ サンドボックスのセットアップに使用されます。

現在のコンテキスト

ファイル システム構成が作成されると、Shotgun Toolkit はディスク上のフォルダとフォルダが属する Shotgun オブジェクト間の関係を認識します。これにより、パスのパブリッシュ、ロード、および解決を行うときに Shotgun のオブジェクトとフォルダ、ディスク、またはファイルを簡単に関連付けることができるため重要です。また、「コンテキスト」や「現在の作業領域」と呼ばれる場所にも関連付けられます。コンテキスト オブジェクトは Toolkit Core の一部で、作業している現在のコンテキストをトラックします。Toolkit がファイル システムのパスを解決する場合に中心となるメカニズムです(このドキュメントの後半で説明)。

コンテキストは、タスク、アセット、ショットなどの Shotgun オブジェクトまたはディスク上のパスのいずれかから作成できます。アプリを実行すると、常にコンテキストにアクセスするため、ファイル システムの命名規則に関する情報がないアプリ、またはアプリがアセットやショット パイプラインで使用されるかどうか分からないアプリを簡単に作成できます。これは Toolkit Core API とコンテキストですべて処理されます。

ファイル システム テンプレート

Toolkit Core にはファイル パスを処理するためのシステムが含まれます。これは「テンプレート システム」と呼ばれています。Shotgun Toolkit がファイル システム ベースであるため、アプリは、ディスクからデータを読み取ったり、データを書き込んだりする場合はファイル パスを解決する必要があります。アプリはファイル システム構造に依存しません。つまり、ファイル システムの整理方法を認識していません。テンプレート システムはこれらすべてを処理します。

テンプレート システムの中心は「テンプレート設定ファイル」です。このファイルには、プロジェクトの重要なすべてのファイル システムの場所が含まれています。テンプレートは次のようになっています。

maya_shot_publish: 'shots/{Shot}/{Step}/pub/{name}.v{version}.ma'

基本的に、特定の動的フィールドが含まれるパスを定義します。各フィールドの設定には検証と入力が必要です。たとえば、上記テンプレートの {version} フィールドが 3 つのゼロ(001、012、132 など)を使用した整数となるように定義することができます。アプリがディスクへの読み書きを行うと、その場所を定義するためにテンプレートがテンプレート ファイルに追加されます。多くの場合、アプリはパイプラインを形成するために設定されているため、1 つのアプリ(パブリッシュ アプリなど)の出力テンプレートは別のアプリ(ロード アプリなど)の入力テンプレートになります。このため、すべてのファイル システムの場所が 1 つのファイルに保存されます。

テンプレート API を使用すると、フィールドの値とパスのリスト間でジャンプできます。

# get a template object from the API
>>> template_obj = sgtk.templates["maya_shot_publish"]
<Sgtk Template maya_asset_project: shots/{Shot}/{Step}/pub/{name}.v{version}.ma>

# we can use the template object to turn a path into a set of fields...
>>> path = '/projects/bbb/shots/001_002/comp/pub/main_scene.v003.ma'
>>> fields = template_obj.get_fields(path)

{'Shot': '001_002',
 'Step': 'comp',
 'name': 'main_scene',
 'version': 3}

# alternatively, we can take a fields dictionary and make a path
>>> template_obj.apply_fields(fields)
'/projects/bbb/shots/001_002/comp/pub/main_scene.v003.ma'

上記のパスとテンプレートには 2 つの異なるタイプのフィールドが設定されます。Shot フィールドと Step フィールドは Shotgun で同等のオブジェクト(ショットとパイプライン ステップ)が設定された高レベルのフィールドで、name フィールドと version フィールドはこの特定のタイプのテンプレート(この場合はパブリッシュ パス)専用です。ショットではなくアセットのパブリッシュ パスを定義する場合は、name フィールドと version フィールドがあります。これはすべてのパブリッシュで必要となるためで、データのタイプには関係ありません。ただし、Shot フィールドと Step フィールドはなくなります。代わりに、アセット フィールドと Shotgun のアセットが関連付けられた Asset フィールドと Step フィールドを使用できる可能性があります。

パブリッシュを実行するアプリを開発する場合、ショット パブリッシュとアセット パブリッシュのそれぞれを実行する個別のアプリを作成したいとは思わないはずです。その代わり、シーケンス、ショット、またはアセットに関係なく、すべてのパブリッシュ シナリオを処理できるパブリッシュ アプリを 1 つだけ作成したいと思うはずです。

ここでツールキット コンテキストが登場します。基本的に、ツールキット コンテキストを使用すると、テンプレート フィールドを 2 つの異なるグループ(上述のとおり)に分割できます。コンテキスト フィールド(Shot、Step、Asset など)は、アプリ コードにショットやアセットなどのコンセプトを処理する専用コードを設定せずに、アプリ外部で解決されます。その代わり、アプリには、このアプリに固有のビジネス ロジックに直接関連付けられたフィールドのみを設定する必要があります。パブリッシュ アプリの例では、ビジネス ロジックは name フィールドと version フィールドで構成されます。上図の説明のとおり、Shotgun Toolkit はフィールド解決を 2 つの異なるフェーズに分割します。一部のフィールドはコンテキストによって設定され、別のフィールドはアプリのビジネス ロジックによって設定されます。この方法では、特定のファイル システム レイアウトに関連付けられないようにアプリを設計することができます。これは優れたパイプライン ツールを作成する上で重要な要素だと考えています。

通常、パス解決を処理するアプリ コードは次のようになります。

# start with an empty fields dictionary
fields = {}

# first let the context populate all its fields
fields.update( self.context.as_template_fields( publish_template_obj ) )
# fields is now {'Shot': '001_002', 'Step': 'comp' }

# now the app can add its business logic
fields["name"] = "main_scene"
fields["version"] = 234

# and finally the app can produce the path it needs in
# order to save out the file
path = publish_template_obj.apply_fields(fields)

テンプレート API の設定方法と使用方法に関する詳細については、次を参照してください。

> ファイル システム設定リファレンス

> Core API リファレンス

実行するエンジンとアプリを選択する

Toolkit Core にはユーザに表示するアプリを決定する上で重要な役割があります。キャラクタ リギングの作業のために Maya を使用している場合、ショットのライトを処理するときに別のアプリ コレクションが必要になることがあります。さらに、操作方法に応じてアプリを個別に設定できるため、リギングのレビュー アプリでターンテーブルを生成する一方で、アニメータが実行したときには同じレビュー アプリでショット カメラを使用してプレイブラストを実行できます。

このような柔軟性を獲得するために、Shotgun Toolkit プロジェクト設定には一連の「環境」が含まれます。環境とは、一連のアプリ、エンジン、およびそれらすべての設定パラメータを定義する設定ファイルです。

例: 環境ファイルはどのようなものですか?

環境ファイルは、一連のエンジンとアプリを定義する yaml ファイルです。

description: Example environment file

engines:

  tk-maya:
    debug_logging: false
    location: {name: tk-maya, type: app_store, version: v0.2.10}

    apps:

      tk-maya-breakdown:
        hook_multi_update: default
        hook_scan_scene: default
        location: {name: tk-maya-breakdown, type: app_store, version: v0.2.7}

      tk-multi-about:
        location: {name: tk-multi-about, type: app_store, version: v0.1.8}

      tk-multi-loader-1:
        dependency_mode: false
        hook_add_file_to_scene: default
        location: {name: tk-multi-loader, type: app_store, version: v0.2.6}
        menu_name: Load Assets...
        publish_filters: []
        sg_entity_types:
          Asset: []
        single_select: true
        tank_types: [Maya Model, Maya Rig]

  tk-nuke:
    debug_logging: false
    location: {name: tk-nuke, type: app_store, version: v0.2.10}

    apps:

      tk-multi-setframerange:
        location: {name: tk-multi-setframerange, type: app_store, version: v0.1.2}
        sg_in_frame_field: sg_cut_in
        sg_out_frame_field: sg_cut_out

      tk-multi-snapshot:
        hook_copy_file: default
        hook_scene_operation: default
        hook_thumbnail: default
        location: {name: tk-multi-snapshot, type: app_store, version: v0.1.15}
        template_snapshot: nuke_shot_snapshot
        template_work: nuke_shot_work

ご覧のとおり、各アプリとエンジンにはパラメータ location があります。これはコードの格納場所と使用中のバージョンを定義します。これはアプリ更新のチェックを管理する Toolkit Core で使用されます。上記の例では、承認済みアプリと管理アプリの一元管理ストアに属する app_store タイプの場所を示していますが、git などの他の場所もサポートします。これにより、Shotgun Pipeline Toolkit に付属するアップグレード システムを使用して内部ツールを簡単に管理およびアップグレードできます。

Toolkit が起動したら、初期化する環境を決定する必要があります。このためには、独自のビジネス ロジックを追加できる「フック」と呼ばれる Python コードを使用します。コンテキスト オブジェクト(現在の作業領域)はこのコードに渡されます。多くの場合、これは使用環境を決定するために使用されます。

これにより、パイプラインのそれぞれの部分に個別のアプリを設定できます。さらに、更新も個別に実行し、管理するスーパーバイザを個別に指定することもできます。

例: 選択環境フックとはどのようなものですか?

選択環境フックはプロジェクトごとにカスタマイズ可能で、次のようになっています。このフックは PIPELINE_CONFIG/core/hooks/pick_environment.py に格納されています。

from tank import Hook

class PickEnvironment(Hook):

    def execute(self, context, **kwargs):
        """
        Example Pick Environment Hook!
        """

        if context.project is None:
            # our context is completely empty!
            # don't know how to handle this case.
            return None

        if context.entity is None:
            # we have a project but not an entity
            return "project"

        if context.entity and context.step:
            # we have a step and an entity
            if context.entity["type"] == "Shot":
                return "shot_step"
            if context.entity["type"] == "Asset":
                return "asset_step"

        return None

既定の設定での環境

環境の仕組みと構造の実例を紹介するために、既定の設定で用意される環境を見てみましょう。

既定の設定で用意される環境は次のとおりです。

  • project.yml - コンテキストにプロジェクトのみが含まれる場合に実行されるアプリとエンジンです。
  • shot_and_asset.yml - コンテキストにショットまたはアセットが含まれる場合に実行されるアプリとエンジンです。
  • shot_step.yml - コンテキストにショットとパイプライン ステップが含まれる場合のアプリとエンジンです。
  • asset_step.yml - コンテキストにアセットとパイプライン ステップが含まれる場合のアプリとエンジンです。

既定の設定のファイル システムはパイプライン ステップに基づいて整理されます。つまり、たとえば、ショットの場所の下にモデリングやリギングなどのフォルダがあります。基本的に、作業するパイプライン ステップごとにフォルダが 1 つあります。各フォルダには、ディスク上に独自の作業領域とパブリッシュ領域があります。つまり、パブリッシュ テンプレートなどは次のようになっています。

maya_shot_publish: 'sequences/{Sequence}/{Shot}/{Step}/pub/{name}.v{version}.ma'

このテンプレートを使用するためには、コンテキストにエンティティ(この場合はショット)とパイプライン ステップの両方を含める必要があります。シーケンス ABC とパイプライン ステップ モデリングの子として関連付けられたショット 1122 の場合、上記のテンプレートは sequences/ABC/1122/Modeling/... に解決されます。たとえば、ショットは含まれるけれども、パイプライン ステップが含まれないコンテキストは、上記のテンプレートの設定には十分ではありません。ショットのみのコンテキストで Maya を起動することはできません。上記のテンプレートを使用して起動させるには、ステップが必要です。

これにより、上記のように環境がブレイクダウンします。既定の設定で定義されたファイル システム構造はステップ中心であるため、すべてのメイン アプリは、ステップが定義されたコンテキストで実行する必要があります。既定の設定では、asset_step.yml と shot_step.yml の 2 種類の環境ファイルを定義します。各ファイルには、Maya、Nuke、3dsmax、Motionbuilder、Photoshop といった数多くの DCC 用のエンジンが含まれています。たとえば、Shotgun 内のショット タスクから Maya を起動する場合、選択環境フックは環境 shot_step を選択し、Maya を起動して Maya のアプリ設定をロードします。

これは、Shotgun 内のショット オブジェクトから Maya を直接起動する際にも役立ちます。さらに重要なのは、これはコンソール tank Shot 1122 launch_maya で入力できるようにする際に本当に役立つということです。環境 shot_and_asset が関係するのはこの段階です。ショット(またはアセット)は含まれるがパイプライン ステップは含まれないコンテキストを使用して Maya をロードすると、この環境がロードされます。ただし、ファイル システム構成はパイプライン ステップごとにすべて整理されるため、ショットのみが設定されている場合はロードまたはパブリッシュを本当に実行することができません。その代わり、Maya は、作業ファイル アプリのみが含まれる最小設定で起動します。このアプリを使用すると、作業するタスクを選択し、コンテキストをこのタスクに切り替えることができます。タスクを選択すると、Toolkit はコンテキストを切り替えてエンジンを再起動し、すべてのアプリが搭載された環境 shot_step をロードします。

同様に、環境 project は、作業ファイル アプリのみが含まれる汎用的なフォールバックです。このため、プロジェクト内のほとんどの場所から Maya (または他のアプリ)を起動できます。最小状態で Toolkit が初期化されるため、作業ファイル アプリを使用して有効な作業領域にジャンプできます。

Shotgun の環境 - コンテキスト メニューを設定する

上述の動的環境とは異なり、コンテキストに応じて Shotgun Pipeline Toolkit によって自動的に選択されます。また、Toolkit には特別な Shotgun 環境セットが用意されています。この環境は Shotgun 内のコンテキスト メニューに表示されるアプリを制御します。このすべての環境ファイルは、shotgun_shot.yml や shotgun_asset.yml など、形式 shotgun_entitytype.yml に基づいて名前が付けられます。この環境で定義したアプリであれば何でも、Shotgun のこのエンティティ タイプのコンテキスト メニューに表示されます。

アプリを設定する

各アプリには指定する必要のある設定パラメータがたくさんあります。アプリをインストールまたはアップグレードする場合は、Toolkit ですべての必須設定を指定していることを確認します。通常、設定は自動的にドキュメント化されます。本ドキュメントのアプリ リスト セクションにアクセスすると、いくつかの例を確認できます。

> Shotgun Pipeline Toolkit で現在提供しているすべてのアプリ、エンジン、および設定。

文字列や整数などの単純な設定値は環境設定で直接指定します。テンプレートは異なります。Shotgun Toolkit ではすべてのテンプレートが 1 つの場所で管理されるため、環境ファイルはテンプレート ファイルで定義されたテンプレートをポイントしているに過ぎません。各アプリでは、設定で使用するテンプレートにさまざまなフィールドを表示する必要があります。たとえば、前述の例では、サンプルのパブリッシュ アプリがディスク上にその出力ファイルを作成する場合、name と version フィールド含むテンプレートを使用していました。そのため、このアプリには、name と version フィールドを含むテンプレートを必要とする設定が指定されていました。

name と version 以外のコンテキスト フィールドを含むテンプレートを使用したアプリを設定する場合、アプリ コードはこのフィールドを設定する方法が分からないため、このテンプレートからパスを生成することはできません。同様に、フィールドの 1 つが欠落しているテンプレートを指定した場合(version など)、結果が分かりにくくなります。この場合は、アプリでバージョン番号が書き込まれなくなります。そのため、Toolkit は、必要なフィールドがすべてのテンプレートで指定されるように起動時に設定を検証します。また、Shotgun Toolkit は既定値とオプション フィールドの使用方法もいくつかサポートしています。完全なリファレンスについては、次のリンクを参照してください。

> アプリとエンジンの設定リファレンス

> ファイル システム設定リファレンス

フック

テンプレートを使用したアプリ設定とは別に、Shotgun Pipeline Toolkit はフックと呼ばれるコンセプトもサポートしています。フックは Python コードの小型スニペットであるため、設定の一部としてアプリ コードを効果的かつ部分的にカスタマイズできます。次に、その動作と仕組みについて説明します。

アプリは複数のエンジンとプロジェクト間で再利用できるため優れています。ただし、アプリにはエンジン固有のコードの小型スニペットがいくつか必要です。たとえば、Nuke と Maya の両方で動作するローダー アプリを作成する場合、実際のファイル ロードを処理するコードが必要です。Nuke と Maya の API は完全に異なるため、このコードは Nuke と Maya で変える必要があります。さらに、すべてのエンジンでこのアプリを使用できれば最高です。また、スタジオが異なればシーンに項目をロードする方法も異なります。あるスタジオはカスタムの Maya リファレンス ノードをサポートし、別のスタジオは読み込みだけを行う場合もあります。

この状況は、フックを使用する Toolkit で処理されます。フックはカスタマイズ可能なコードです。このアプリには基本的な実装を含む既定のフックが含まれています。つまり、このアプリはすぐに正常に動作します。ただし、動作をカスタマイズする場合、このフック ファイルを設定にコピーすると、Toolkit は代わりにこのコードを使用します。

> フックの操作方法を管理者ガイドで確認する

Shotgun とシェルから実行する

Shotgun Toolkit をインストールすると、複数のプライマリ エントリ ポイントからアクセスできます。

  • Shotgun アクションは Shotgun 内の右クリック メニューに表示されます。
  • 起動アイコンは Shotgun Desktop アプリのプロジェクトで表示されます。
  • コンソールで tank コマンドを使用することができます。
  • Toolkit Python API はアプリケーションとシェルの両方で利用可能です。

アプリケーションの起動とタスクの実行は、Shotgun 内から Toolkit を実行するのが一般的です。Shotgun Toolkit は Shotgun ブラウザ プラグインを使用して、マシンのローカルにある Toolkit インストールと接続し、Shotgun エンジンとアプリを実行するためにローカルの Python を使用します。つまり、Shotgun 内からフォルダ作成などのローカルの作業を実行できます。また、Shotgun 内から QT UI ベースのアプリを実行することもできます。

さらに、コマンド シェルから Shotgun Toolkit にアクセスすることもできます。各プロジェクト設定には独自の tank コマンドが用意されています。プロジェクト設定ルートにアクセスして、./tank コマンドを実行するだけです。

最後に、Toolkit API を PYTHONPATH に追加して読み込みます。API の使用は単純です。たとえば、起動アプリ機能を使用する代わりに、手動またはスタジオの既存の起動システムの一部として、Maya 内の Shotgun Pipeline Toolkit を起動する場合は、簡単な数個のコマンドを実行するだけです。

Shotgun にパブリッシュする

他のユーザと共同で作業しているファイルを共有する場合は、このファイルをパブリッシュできます。つまり、パブリッシュ レコードが Shotgun 内で作成されます。

データ管理(ディスク関連項目が保存される場所やファイルに含まれる内容)の観点から見た場合、実際の作業はアプリが実行します。Toolkit API により、アプリ開発者は Shotgun 内でパブリッシュを簡単に作成し、このパブリッシュと最適なオブジェクトをリンクするためのメソッドを使用できるため、Shotgun が処理を進めて適切なユーザすべてに通知を送信するようにできます。また、用途が幅広く、高度に設定可能な既定のパブリッシュ アプリもありますが、これが Shotgun Toolkit を使用してバージョン管理を実装する唯一の方法ではありません。Sgtk はパイプライン ツールキットであるため、このツールキットを使用して独自のカスタム バージョン管理とパブリッシュ システムを必要に応じて開発することができます。ただし、最初は Publish アプリを使用することをお勧めします。

> 既定の Multi Publish アプリ

再利用可能なアプリを作成する

Shotgun Pipeline Toolkit はアプリとエンジンの単なるコレクションではありません。独自のツールと技術の開発に使用するフレームワークでもあります。Shotgun Toolkit を豊富な機能を備えたスタジオの開発プラットフォームにするための機能がたくさん含まれています。基礎として Toolkit を使用すると、基本的なパイプライン スタックを構築するのではなく、身近な問題に注目することができます。開発者がアーティストのパイプラインを間違って破壊しないようにソフトウェアの作成、評価、およびリリースを簡単に行えるようにしました。

  • エンジンは、基盤に関係なく、アプリを Python や QT (PySide/PyQt)で作成できるようにするものです。つまり、非常にシンプルなエンジン(PySide と Python が既に含まれている Nuke など)と、より複雑なエンジン(Python をサポートしていない Photoshop など)があります。これは、簡単で一貫性のある方法を使用してスタジオ用のツールを開発できることを意味しています。これまでの経験から、開発環境スタジオでは Python と PyQt/PySide を使用することが多く、多くの TD はこれに慣れています。

  • また、エンジン レイヤは、アプリを一度作成すれば複数の環境で展開できることを意味しています。オートデスクは、標準的なアプリ スイートを「マルチ アプリ」として開発しています。つまり、同じアプリをすべてのエンジンで使用できます。各 DCC アプリケーションで公開される特定の API と連携するように調整する必要がある特定のコードが必ずありますが、通常、これは 1 つ以上のフックに含まれるため、アプリケーションを簡単に再利用できます。このようにマルチ アプリを作成できるため、新しいエンジンを開発する場合、この新しいエンジンと連携するように標準的なすべてのアプリを簡単に設定できます。

  • パイプライン設定とクローン作成により、開発サンドボックスを簡単に作成できるため、開発者は日常の制作活動に影響を受けることなく制作上の開発を行うことができます。ツールを展開する準備が完了すると、メインのプロジェクト設定は簡単に更新でき、このツールはすべてのアーティストに展開されます。

  • アプリはエンジン内で実行されるため、アプリを簡単に再ロードできます。新しいコード変更をテストするたびに Nuke や Maya を再起動する必要はなく、Toolkit の再ロード ボタンをクリックするだけで、最新のコードがロードされます。

アプリ開発の詳細については、次のドキュメントを参照してください。

> Toolkit アプリ開発の概要

> Toolkit API リファレンス

> アプリとエンジンの設定リファレンス

セキュリティと認証

Shotgun Pipeline Toolkit を実行すると、特定の操作を実行するために Shotgun に定期的に接続されます。新しいレンダリングをパブリッシュした場合またはシーンにロードする項目を参照した場合などです。この場合、Toolkit はデータの読み書きのために Shotgun にログインする必要があります。つまり、Shotgun サーバとの接続を確立できるように現在のユーザを認証する必要があります。

Toolkit Core のバージョンが v0.16 よりも前の場合、1 人の Shotgun API スクリプト ユーザがすべての Toolkit の操作を処理することで、この状況は自動的に処理されていました。Core v0.16 の場合、Toolkit には各ユーザのログイン名とパスワードを要求するモードが既定値として設定されているため、操作感は他の Shotgun の実行方法と同じような感じになります。

Toolkit は認証にセッション トークンを使用します。これは Shotgun サーバで生成される固有の ID です。Toolkit で Shotgun API 要求が発生すると、このセッション トークンが渡されるため、サーバはこのトークンを検証し、要求に対してアクセスを付与します。このセッション トークンは、一定期間(通常は 24 時間)放置するとタイムアウトになります。タイムアウトになると、Toolkit が新しいセッション トークンを取得するため、通常、ユーザにはパスワードの再入力を求めるプロンプトが表示されます。

パイプラインで、ユーザにパスワードの入力を促すのが難しい、または不可能な状況が発生することは珍しくありません。この場合、Toolkit は、完全に「ヘッドレス」で実行する方法または認証のプロセスを完全にカスタマイズする方法をいくつか提供します。次のセクションでは、Toolkit のセキュリティ モデルの仕組みとそのカスタマイズ方法について説明します。

Core v0.16 にアップグレードする

v0.16 よりも前の場合、すべての認証は shotgun.yml と呼ばれる設定ファイルによって処理されていました。このファイルには Shotgun スクリプト資格情報が含まれているため、すべてのユーザはログインせずに同じ方法で Shotgun にアクセスできました。Core v0.16 はこの動作をまだサポートしていますが、既定ではユーザ名とパスワードを求めるプロンプトを表示するように設定されており、Toolkit がユーザを詳細に管理して、グローバルな場所にスクリプト資格情報を保存しないようにしています。

Core v0.16 は完全な下位互換性があり、shotgun.yml ファイルで指定されたスクリプト資格情報を使用して Toolkit プロジェクトを実行すると、このスクリプト資格情報は認証用として使用されます。つまり、Toolkit Core v0.16 に更新しても、既存のプロジェクトは新しい認証機能の影響を受けることはありません。

通常、既存の shotgun.yml ファイルは次のように表示されます。

# Shotgun Pipeline Toolkit configuration file
# this file was automatically created

host: https://mysite.shotgunstudio.com
api_key: abcdefghijklmnopqrstuvwxyz01234567890ABCDE
api_script: Toolkit
http_proxy: null

# End of file.

api_script と api_key の行が削除されると、Toolkit はログイン名とパスワードを求めるプロンプトをユーザに表示し始めます。新しいプロジェクトを v0.16 でセットアップすると、自動的に次の形式を使用します。

# Core v0.16 example which doesn't store script
# credentials in a file but instead prompts each
# user to individually log in

host: https://mysite.shotgunstudio.com
http_proxy: null

# End of file.

  • Core v0.16 で導入された新しい認証機能を使用して既存のプロジェクトを実行する場合は、shotgun.yml ファイル(通常は設定フォルダ内の config/core に格納)を特定して、api_key キーと api_script キーをコメントアウトするだけです。

  • 反対に、新しいプロジェクトを作成し、Toolkit で以前に使用した自動認証モデルを使用する場合は、有効なスクリプト資格情報で shotgun.yml を更新するだけです。

  • 既存のプロジェクトの api_key と api_script フィールドをコメントアウトすると、設定が v0.16 よりも前のコアに適用されなくなります。その前に、このプロジェクトで作業するすべてのユーザが Core v0.16 にアップグレードしていることを確認してください。

  • 上記と同じような状況の上級ユーザで、Shotgun Desktop v1.0.x を実行している場合、Shotgun Desktop で使用されるローカル サイト設定から api_key と api_script フィールドを手動で削除しないでください。古い v1.0.x バージョンの Shotgun Desktop は、shotgun.yml にスクリプト資格情報が保存されていないプロジェクトを処理できますが、このフィールドを表示するにはサイト設定ファイルがまだ必要です。パイプラインからハードコードされた資格情報を完全に削除するには、最新バージョンの Shotgun Desktop に更新する必要があります。

  • プロジェクトで共有コアを使用している場合、shotgun.yml ファイルは、プロジェクト設定ではなく、コア設定場所に格納されています。このような場合は、加えた変更がこのコアを使用するすべてのプロジェクトに影響します。

  • ユーザ ログインが一致しない - これまでは、すべてのユーザが同じスクリプト ユーザを使用して Shotgun に接続していました。つまり、Shotgun 接続に関しては、実際に接続しているユーザは誰なのかという強いコンセプトはありませんでした。Toolkit は、現在のユーザのオペレーティング システム ログインを取得して(フックを使用)、Shotgun のユーザと一致させて、実際のユーザを特定しようとします。この動作は v0.16 でもフォールバック メカニズムとして残っていますが、ユーザごとの認証が有効な新しいすべてのプロジェクトでは、このシステム ログイン一致ロジックは不要になり使用されなくなります。

  • 新しい権限 - これまでは Toolkit が接続に 1 人の Toolkit スクリプト ユーザを使用すると、このスクリプト ユーザに関連付けられた Shotgun 権限によって Shotgun 内で実行される操作が制限されていました。代わりにユーザが Toolkit にログインする新しいプロジェクトでは、実行できる操作を決定するのはユーザの Shotgun 権限になります。これは社内ツールとカスタマイズの両方の操作の動作に影響を与える可能性があります。これまでの Toolkit スクリプト ユーザはアーティストの代わりに Shotgun の操作を実行していましたが、現在はアーティストが各自の資格情報を使用して同じ操作を実行しています。通常、必要なすべてのパイプラインの操作を実行するための権限が付与されるようにユーザの Shotgun 権限を調整することで、潜在的な問題をすばやく修正します。

認証とプロンプト

Toolkit Core v0.16 以降、いくつかの異なるセキュリティ モードがサポートされています。そのすべての説明を以下に示します。

グローバル スクリプト キーを使用する

ログイン名とパスワードを求めるプロンプトが誰にも表示されないようにするには、shotgun.yml ファイルでグローバル Shotgun スクリプト キーを指定します。Toolkit は Shotgun のすべての操作にこのキーを使用します。これは Toolkit Core v0.16 より前のすべてのプロジェクトで使用されていたセキュリティ モードです。既定では、新しいプロジェクトはこのグローバル スクリプト キーを使用せずに作成されますが、api_script と api_key の 2 つのオプションを shotgun.yml に追加するとこのキーを有効にすることができます。例については、前のセクションを参照してください。

Shogun にログインする

ユーザごとのセキュリティを有効にすると、Shotgun には認証のためにログイン名とパスワードの入力が必要になります。セッション間でこれらは記憶されますが、ログイン名とパスワードの入力を求められることもあります。

Toolkit にログインすると、パスワードが Shotgun サーバに安全に送信され、セッション トークンが返されます。Toolkit はこのトークンを使用して接続し、トークンが有効な間はパスワードの入力を再び求められることはありません。トークンの期限が切れると(通常は 24 時間の放置後)、Toolkit はパスワードの入力を求めるプロンプトを再び表示します。ログイン名とパスワードの入力を求めるプロンプトは、次のさまざまな状況で表示されます。

  • Shotgun Desktop を起動した場合。

  • ターミナルで tank コマンドを実行した場合。プロンプトをオフにするにはいくつかの方法があります。それについては次のセクションで説明します。

  • Shotgun Web アプリケーションで Toolkit アクション メニュー アイテムをクリックした場合。

  • 通常、Maya、Nuke、または他の DCC を起動しても、パスワードの入力を求めるプロンプトは表示されません。これは、Shotgun Desktop、Shotgun Web アプリケーション、または tank コマンドで認証が既に更新されているためです。ただし、Maya または Nuke を起動して 24 時間以上放置した場合は、パスワードの再入力を求めるダイアログが表示されることがあります。これは Toolkit で Shotgun にアクセスする直前に発生します。

非インタラクティブ環境で実行する

多くの場合、パイプライン コードは UI またはユーザが存在しない環境で実行する必要があります。レンダリング ファームでのコードの実行は典型的な例です。この場合、Toolkit は API とコマンド ラインを介して資格情報を提供する方法をいくつか提供します。

tank コマンドを使用している場合は、いくつかのオプションを使用できます。--script-name コマンド ライン引数と --script-key コマンド ライン引数を使用すると、認証のスクリプト名とスクリプト キーを直接指定できます。

# never prompt for a username or password
> tank --script-name=headless_launcher --script-key=xxx Shot ABC123 launch_maya

コマンド ラインで詳細を直接指定しない場合は、詳細をファイルに保存し、--credentials-file 引数を使用して tank コマンドでこのファイルを指定することもできます。

# never prompt for a username or password
> tank --credentials-file=/path/to/script_credentials.yml Shot ABC123 launch_maya

このファイルの形式は次のとおりです。

script-name: Toolkit
script-key: abcdefghijklmnopqrstuvwxyz01234567890ABCDE

この方法では、さまざまなパイプライン サービスに応じて異なる権限が設定された複数の Shotgun スクリプト ユーザを管理できるため、プロセスでは必要な Shotgun データへのアクセスのみが制限されます。

Toolkit API を直接使用している場合、Toolkit が認証されるように現在はいくつかのコードを作成する必要があります。sgtk API のメイン セキュリティ API メソッドは sgtk.set_authenticated_user(user) で、特定のユーザと Toolkit のコア セッションを関連付けるのに使用されます。このメソッドに渡すユーザ オブジェクトは、ロジックを抽象化する Shotgun Authentication API で生成されます。次のサンプル コードでは、認証に Shotgun スクリプトを使用する Toolkit Core API セッションを設定する方法について説明します。

import sgtk
from tank_vendor.shotgun_authentication import ShotgunAuthenticator

# create an authenticator object. This is the main object which
# handles all authentication
sa = ShotgunAuthenticator()

# Use the authenticator to create a user object. This object
# identifies a Shotgun user or script and also wraps around
# a Shotgun API instance which is associated with that user.
user = sa.create_script_user(api_script="myscript",
                             api_key="xxxxx",
                             host="https://myhost.shotgunstudio.com")

# tell the Toolkit Core API which user to use
sgtk.set_authenticated_user(user)

認証されたユーザを Toolkit で設定すると、ユーザ オブジェクトが組み込まれた context シリアル化メソッドの一部として自動的にシリアル化されます。つまり、たとえば、Maya、Nuke、または他の DCC を起動する場合、資格情報は起動プロセス(通常は tank コマンド、Shotgun Desktop、または Shotgun Web アプリケーション)から起動した DCC に渡されます。このため、あるプロセスから別のプロセスに有効な資格情報を渡すことが非常に簡単になります。

Shotgun 認証 API の詳細については、インライン コード マニュアルを参照してください。

技術の詳細

Shotgun 認証ライブラリ

Shotgun に関連するすべての認証ロジックは、Toolkit Core や Shotgun Desktop で使用されるスタンドアロンの Python ライブラリとして開発されました。また、Shotgun へのログインが必要なシナリオを処理する必要がある他のアプリケーション(Toolkit 以外)で使用することもできます。ライブラリは Shotgun API をラップし、ユーザの認証が必要な場合に表示される、標準化された QT ベースの Shotgun ログイン ダイアログを含んでいます。Shotgun 認証モジュールは Shotgun 認証に共通する多くのシナリオを処理し、ユーザが安全性と快適性を感じられるように標準化されたユーザ エクスペリエンスを維持します。機能セットの概要は次のとおりです。

  • ユーザ名とパスワードの入力を求めるプロンプトに関して標準化された QT とコマンド ライン ベースのユーザ エクスペリエンス

  • API インスタンス間の Shotgun セッション トークンを維持するための既定のメカニズムです。API でユーザ操作の中断を最小限に抑えられます。

  • API のクライアントが既定の動作を設定できる設定可能かつオーバーライド可能な既定のマネージャです。

  • Shotgun 認証インスタンスは API の中心で動作し、Shotgun ユーザ オブジェクト オブジェクトのファクトリとして機能します。このオブジェクトは Shotgun のユーザまたはスクリプトを表します。

  • 認証ライブラリから返される Shotgun ユーザ オブジェクトには、このユーザに関連した Shotgun API インスタンスを作成する create_sg_connection() メソッドがあります。スクリプト ユーザ以外の場合、Shotgun API インスタンスで使用するセッション トークンは、通常 24 時間放置すると無効になります。この場合、Shotgun API インスタンスはこのエラーをトラップし、ユーザにパスワードの入力を求めるプロンプトが自動的に表示されます。

詳細については、Shotgun 認証モジュールのインライン コード マニュアルを参照してください。

Shotgun の認証と権限

ユーザが Toolkit で自分のログイン名とパスワードを使用して認証すると、Shotgun 認証ライブラリは Shotgun サーバに接続し、この情報を以降の要求で使用されるセッション トークンに変換します。パスワードはどこにも保存されませんが、セッション トークンはファイル権限が制限されたディスク上のファイルに保存され、認証が必要になると使用されます。Toolkit は可能な限りこの保存したセッション トークンを使用し、トークンが無効になった場合のみユーザにプロンプトが表示されます。通常、これは 24 時間放置すると発生します。

Toolkit がこの方法で Shotgun と通信する場合、API セッションは、ユーザが Shotgun Web アプリケーションにログインする場合に通常使用するのと同じ Shotgun 権限ルールを使用します。この権限にはさまざまな種類があり、多くの場合、既定の Shotgun API スクリプト権限よりも限定的です。つまり、スクリプト ユーザとしてログインした場合に正しく動作する操作が、ユーザとしてログインすると動作しなかったり、その逆もあり得るということです。権限エラーが発生した場合は、Shotgun 権限エディタでユーザの権限と API スクリプトを再度チェックしてください。このエディタは Shotgun Web アプリケーションの管理者メニューにあります。

Toolkit のシリアル化

Maya や Nuke などの DCC を Toolkit 内で起動すると(tk-multi-launchapp を使用)、通常、現在の context は文字列ベースの形式にシリアル化されます。次に、DCC プロセスが開始され、通常は Toolkit で提供される起動またはブートストラップ スクリプトを実行するように求められます。このスクリプトはコンテキスト文字列をオブジェクトにシリアル化解除し、新しい tk インスタンスを作成して、最後にエンジンを起動します。

この一環として、ユーザ オブジェクトもシリアル化されます。つまり、新しいプロセスはその親プロセスとまったく同じ資格情報設定を使用して実行されます。このため、ユーザごとに異なるプロセスを起動したり、あるマシンで取得したコンテキストを別のマシンで実行したりできます。

ファイルの場所

セッション トークンは次のファイルに保存されます。

  • MacOSX の場合: ~/Library/Caches/Shotgun/SITENAME/authentication.yml
  • Linux の場合: ~/.Shotgun/SITENAME/authentication.yml
  • Windows の場合: %APPDATA%/Shotgun/SITENAME/authentication.yml

Toolkit 認証ライブラリは現在のサイトとユーザのコンセプトを管理しています。つまり、このライブラリを使用すると、すべてのアプリケーションとセッションが同じログイン資格情報にアクセスするシングル サインオンを管理できます。

マルチスレッド環境

セッション トークンを一定期間放置して期限が切れると、Shotgun 認証ライブラリはパスワード入力を求めるプロンプトをユーザに表示します。ログイン時と同様に、このパスワードは Shotgun サーバに送信され、新しい有効なセッション トークンに交換されます。

実際には、Shotgun API が Shotgun 認証ライブラリからの戻り値を処理します。user_object.create_sg_connection() メソッドにはセッションの有効期限を確認するラッパー コードが含まれます。これが検出されるたびに、ユーザには再認証のプロンプトが表示され、操作を再試行します。

マルチスレッド シナリオでは、複数のワーカー スレッドで Shotgun API インスタンスを保持しているときに、複数のスレッドでセッションの有効期限が切れていると、Shotgun 認証ライブラリは最初のスレッドを除くすべてのスレッドを停止して、新しいパスワードの入力を求めるプロンプトをユーザに表示します。これにより、プロンプトが何度も表示されるのを回避します。ユーザにプロンプトが表示された場合、QT UI コードは常にメイン スレッドで実行されます。

Toolkit の技術詳細とその他の情報

Shotgun Pipeline Toolkit は Python (3.x ではなく v2.6+)で作成され、基本的にはクライアント マシン上で実行される一連のスクリプトです。この Toolkit は、Linux、Windows、および MacOSX で動作します。

ほとんどのアセット管理システムにはメタデータを格納するデータベースがあります。この Toolkit には独自のデータベースがありません。代わりに、ストレージとコンテキスト管理用の Shotgun データベースを使用します。Core API の処理の大部分は、Shotgun との通信ではなく、ファイル システムを使用したパスやデータの解決です。

Core API は「すべてを制御する」わけではなく、「一発勝負」の処理でもありません。代わりに、いつも側に待機して、スクリプトとアーティストがアドバイスやサポートを求める場所になります。アセット管理に共通する手法の 1 つは、パイプラインのファイル システムとデータ フローを完全に制御しようとすることです。パイプライン内で発生するすべてのことを把握することで、システムは非常に正確な方法でコンテンツ作成と処理をトラックできます。ただし、この手法には費用がかかります。完全な所有権を取得するには、多くの場合、既存のツールを再作成し、すべてのデータが格納される一元的なポイントを導入する必要があります。これは優れた方法ですが、Toolkit はデータの所有権を取得しようとはしません。代わりに、Toolkit はデータを把握して、その側に待機するヘルパーになろうとします。Shotgun Toolkit はディスク上のデータの格納先を把握しているため、プロダクション プロセス全体でアーティストと開発者が協力して簡単に組織化できます。

既存のパイプライン セットアップとコンテンツ トラッキング システムを使用して Shotgun Toolkit を段階的に実行できます。ディスク上の格納先を共有して把握している限り、Toolkit はデータを変更できます。

詳細については、次のドキュメントを参照してください。

> Shotgun Pipeline Toolkit で現在提供しているすべてのアプリ、エンジン、および設定。

> Shotgun Pipeline Toolkit を管理および設定する方法

> Sgtk API リファレンス

> アプリとエンジンの設定リファレンス

> ファイル システム設定リファレンス

> プラットフォーム API リファレンス
Big Buck Bunny - 画像提供: (CC) Blender Foundation (www.blender.org)
 
この記事は役に立ちましたか？
2人中2人がこの記事が役に立ったと言っています
記事の前回更新日:
フォローする