Katana資源

Katanaを使用しますKATANA_RESOURCESプラグインやその他のカスタマイズ（シェルフ、タブ、解像度など）を探すためのパスのリストを提供する環境変数。これは、コロン（Linuxを使用している場合）またはセミコロン（使用している場合）で区切られたディレクトリのリストにすることもできます。 Windows ）。アイデアは、リソースの場所のリストを作成できるようにすることです。プラグインを作成する開発者の場合Katana、彼らが適切に拾われるために彼らが正しい場所に行くことを確認する必要があります。

例は次のディレクトリに提供されており、このパスがKATANA_RESOURCES環境変数：

$ KATANA_ROOT / plugins / Resources / Examples

新しいパスを追加する

追加するディレクトリKATANA_RESOURCESパスはKatanaプラグイン用。たとえば、次を指定できます。

export KATANA_RESOURCES = / home / tom / dev / katana / Resources：/ tools / site / katana / Resources

次の場合に表示されるはずですKatana開始：

> katana [INFO LicenseCheck]：インタラクティブライセンスOK [INFO python.ResourceFiles]：追加Katana $ KATANA_RESOURCESからのリソースパス：[INFO python.ResourceFiles]：/ home / tom / dev / katana / Resources [INFO python.ResourceFiles]：/ tools / site / katana / Resources

これらは、にリストされているものに加えて検索されますデフォルトセクション、以下で詳しく説明します。

注意：  この変数は、標準のLinux環境変数として動作します。したがって、これにディレクトリを追加し、すでにそこにあるものを保持したい場合は、これを編集するときに注意する必要があります。

重要なディレクトリ

配置するパスKATANA_RESOURCES実際には直接検索されません。代わりに、プログラムのさまざまな部分で使用されるサブディレクトリの意味のあるセットがあります。Pythonモジュールの場合、リストされている「タイプ」は、モジュールのPluginRegistryリストに設定されている各タプルの最初の値を参照します。

• Args - .argsシェーダーのファイル。

• AssetPlugins -PythonベースのAssetPluginおよびFileSequencePluginプラグイン。

• Gaffer* -Gafferスーパーツールを拡張するPythonベースのGafferModuleプラグイン（スクリプトアイテム）。

• GenericAssign -新しいGenericAssignベースのノードを定義するためのテンプレート（.xml）。

• Importomatic* -Importomatic SuperToolのプラグインを形成するPythonベースのImportomaticModuleプラグイン。

• Libs -コンパイル済みのC ++プラグインKatana、すべてのAPIに対して。たとえば、Cベースのアセットプラグイン（.so）。

• Macros -からマクロとして保存されたノードKatana UI（.macro）。

• Ops -シーンデータを任意に作成および操作できるC ++プラグイン。Opsは、Libsサブフォルダーに配置することもできますKATANA_RESOURCES。Opsが読み込まれますKatanaそれらがLibsフォルダーに配置されているかOpsフォルダーに配置されているかにかかわらず。

• Plugins -GafferProfileなどのタイプを含む、さまざまなPythonモジュールKatanaプラグイン、RenderLocationPlugin、ViewerProxyLoader、UVTileFormats。

• RenderBin -このディレクトリは実際には標準ではありませんKatanaディレクトリですが、多くのレンダープラグインは、これを使用して、レンダー自体がロードするバイナリおよびプラグインを格納します。 Katana。

• Resolutions -追加の解像度ファイル（.xml）。

• Shaders -レンダラー用の追加シェーダー。このディレクトリが考慮される唯一の時間Katanaそれ自体は、ビューアのシェーダーを見つけることです（.glsl）。

• Shelves -各シェルフのディレクトリ。各シェルフアイテムのPythonスクリプトが含まれます。

• Startup -設定に使用できるPythonスクリプトKatana起動時に。（execfileを使用して）明示的に実行される唯一のファイルは、 init.py。他のスクリプトを実行したり、モジュールをインポートしたい場合は、そこから呼び出す必要があります。

• SuperTools* -新しいSuperToolsを実装するPythonモジュール。

• Tabs* -UIのペインにドッキングできる新しいタブを実装するPythonモジュール（KatanaPanel）。

• UIPlugins -AssetWidgetDelegatesなどのUI固有のプラグインを実装するPythonモジュールKatanaプラグイン。

注意：  これらのプラグインはロードされません--batch、 --script 、そして--shell起動モード。

• ViewerManipulators -ビューアー用の追加のPythonマニピュレーター（KatanaManipulator）。

デフォルト

Katana設定内容に関係なく、常に次の（内部）場所を検索しますKATANA_RESOURCESに。$KATANA_ROOTどこにKatanaインストールが生きています。

$ {KATANA_ROOT} / bin / python / UI4 / Resources

$ {KATANA_ROOT} / plugins / Resources / Core

通常、検索順序は「標準パス動作」です。すなわち、 Katanaディレクトリを左から右に見てください。ただし、ロードされるプラグイン/ディレクトリのタイプによって、観察できることが少し異なります。

コンパイル済みプラグイン

コンパイルされたプラグインの多くは、「最初にロードされた」スティックが固定されていることに基づいて機能します。これはに基づいていません.so名前、しかし代わりに渡される名前REGISTER_PLUGIN。同じ名前の繰り返し登録は無視されます。各ディレクトリのプラグインはreaddirによって繰り返されるため、「ファイルシステムの順序」でロードされます。

ViewerModifierPluginsの場合、マッピングがロケーションタイプ（API呼び出しに基づく）である場合、ロケーションの有効な勝者は、特定のロケーションタイプを受け入れる最初の名前付き登録です。

しかし、「最初の」プラグインとは何ですか？ 同じ名前の複数の登録の場合、たとえば、両方とも「OuModifier」という名前の中央プラグインのローカルビルドの場合、パスの最初から左から右に取得します。ただし、「LightModifier」と「MyLightModifier」など、複数の独立した名前の登録が同じタイプを処理する場合、最初は内部プラグインマップから反復され、現在はアルファベット順に並べられています。

Python

Pythonモジュールは通常、ディレクトリから取得されます（使用__import__）、 左から右へ。そのため、PluginRegistryに特定の名前を登録する最初のモジュールが勝ちます。任意のディレクトリ内で、プラグインはos.listdir、その順序を任意として文書化します。ただし、一部のコードはこの検索順序を逆にします。アスタリスク（*）上記は右から左への優先順位です。さらに、シェルフメカニズムは左から右（非反転）を検索するため、シェルフは期待どおりに機能しません。これは、右端のファイルの内容が優先されることを意味します。