Houdiniには、外部のプログラム/スクリプトを実行するためのビルトインのノード(ImageMagick, FFmpeg Encode Video, ShotGrid Downloadなど)がいくつか同梱されています。 とはいえ、独自またはサードパーティ製のスクリプト/プログラムをTOPで利用できるようにしたいことがよくあります。

いくつかの方法で、TOPネットワークから外部のプログラムを実行することができます:

• Python Scriptノードを使って、そのノードに、実行したいスクリプトをタイプすることができます。

  Python Scriptノードは、入力のワークアイテム毎に1回だけワークスクリプトを実行する新しいワークアイテムを自動的に生成します。 このスクリプト内で、入力のワークアイテムのアトリビュートにアクセスしたり、そのスクリプトが実行するワークに基づいて、出力されるワークアイテムに出力アトリビュートを設定することができます。

  • スクリプトを試してみたり、特定のネットワークに特化した何かの処理を行なう“one-off(1回限りの)”スクリプトには非常に役立ちます。

  • 非常に便利なオプションが用意されていて、必要な事はワークスクリプトを記述する事だけです。

  • そんなに柔軟性はありません。ゼロからワークアイテムを生成する必要がある場合、または、上流のワークアイテムから複数のワークアイテムを生成する必要がある場合、Python Scriptノードを使用するのではなくて、新しいプロセッサタイプを作成する必要があります。

  • カスタムユーザインターフェースを用意することができません。

  以下のone-off(1回限りの)スクリプトの書き方を参照してください。

• Generic Generatorノードは、入力のワークアイテム毎に、指定したコマンドラインを実行する新しいワークアイテムを生成します。ワークスクリプトを実行できるように、このコマンドラインを設定することができます。これは、実質的にPython Scriptノードと同じですが、ノードの中にスクリプトを埋め込むのではなくて、外部のスクリプトファイルを使用します。

• 新しいPython Processorノードを作成することができます。

  Python Processorノードは、ワークアイテムを生成する独自のPythonコードを記述することができます。このノードからデジタルアセットを生成することで、ネットワークとユーザ間で新しい機能を共有することができます。

  • ワークスクリプトを記述するだけでなく、さらにpdg APIを使ってもっと高度なPythonコードを記述する必要があります。

  • 柔軟性が高いです。つまり、ワークアイテムの生成をフルコントロールすることができます。例えば、入力のワークアイテムに基づいて複数のワークアイテムを生成することができます(入力のワークアイテムよりも 少ない数の ワークアイテムを生成することは できません 。そうしたい場合は、パーティショナーを作成することになります)。

  • Spareパラメータを使ってノードにカスタムインターフェースを追加することで、ユーザ側でノードの挙動を制御することができます。

  以下の新しいプロセッサタイプの作り方を参照してください。

ネットワークを構築する時は、おそらくPython Scriptノードが最初の選択肢となることでしょう。 カスタムPython Processorを使ってもっと柔軟性が必要になった場合でも、このPython Scriptノードで作成したワークスクリプトは再利用することができます。

1. ワークアイテム毎に処理させるワークが小規模またはローカルで十分で、プロセスキューまたはレンダーファームを使ってスケジュールを組むほどでもない場合(例えば、ファイルのコピー)、Python Scriptノードの Evaluate In Process を有効にすることで、そのワークをメインプロセスで処理させることができます。

   Evaluate In Process を有効にすると、ワークスクリプト内で利用可能なself変数(現行のpdg.Nodeオブジェクト)とparent_item変数(現行のワークアイテムの派生元の上流のpdg.WorkItem)を使用することができます。

2. Evaluate In Process を無効にすると、そのスクリプトの実行に使用するPython実行ファイルを設定することができます。Houdiniのhouモジュールにアクセスする必要があるのであれば、“Hython”を使用してください。そのスクリプトが純粋なPython(これにはpdgjsonとpdgcmdのモジュールを含みます)であれば、ここには“PDG Python”を設定することができます。通常のPythonはHythonよりも高速に起動し、Houdiniライセンスを使用しません。

3. Script エディタ内に、実行するスクリプトを記述します。

   このノードは、入力のワークアイテム毎に、このスクリプトを実行する新しいワークアイテムを生成します。現行ワークアイテムを表現したpdg.WorkItemオブジェクトは、このスクリプト内ではwork_itemとして利用可能です。

   詳細は、ワークスクリプトの書き方を参照してください。

   ( Evaluate In Process が有効でない限り)このスクリプトは、レンダーファームサーバー上で実行されるようにスケジュールが組まれることを忘れないでください。 ローカルマシンを想定しないようにしてください。詳細は、Job APIを参照してください。

1. TOPネットワーク内で、Python Processorノードを作成します。

2. このノードが上流のワークアイテムが完了するまで新しいワークアイテムを生成することができない(つまり、上流のワークアイテムからデータを読み込まないと、生成すべき新しいワークアイテムの数がわからない)ことがわかっているのであれば、 Generate When を“Each Upstream Item is Cooked”に設定してください。わからないのであれば、“Automatic”の設定のままにします。

3. Processor タブの Command フィールドは何もしません。このフィールドの目的は、ワークアイテムを生成するスクリプト内でそれをSpareパラメータとして参照することで、新しいワークアイテムのコマンドラインを設定できるようにするためにあります。ほとんどのユーザにとっては、スクリプト内でコマンドラインをハードコーディングするよりも、パラメータ内にコマンドラインをセットアップしてそれを参照した方が編集が楽だと思います。

4. ユーザ側でノードの挙動を制御できるようにするために、Spareパラメータを追加します。

   このようにした方が、Pythonコードに値をハードコーディングするよりもまったく言って柔軟性があり便利です。 コードを書いている途中でインターフェースの改良を施したり、コードを書き終わった後でもパラメータを追加/除去が簡単にできます。

   以下のSpareパラメータインターフェースを構築する方法のヘルプを参照してください。

5. Generateタブ内でコールバックスクリプトを記述します。 Generate タブのコールバックスクリプトは、このノードが生成するワークアイテムの内容、そのワークアイテムに設定するアトリビュート、ワークアイテム毎に走らせるコマンドラインを制御します。

   以下のGenerateタブのヘルプを参照してください。 Generateコールバックのサンプルコードは、Generateのサンプルを参照してください。

   Generateコールバックは、このノードが静的または動的のどちらなのかに応じてコールのされ方が異なります。

   • このノードが静的であれば、Generateコールバックは 1回だけ コールされます。upstream_itemsリストには、静的であると判断されたすべての上流のワークアイテムが入ります。

   • このノードが動的であれば、Generateコールバックは、 入力のワークアイテムが完了する度に コールされます。upstream_itemsリストには、1個のワークアイテム(新しく利用可能なワークアイテム)のみが入ります。

     このノードが動的であるものの、上流のワークアイテムすべてが利用可能になるまで待機させたいのであれば、そのPython Processorノードの前にWait for Allノードを配置してください。次に、そのPython Processorノードで以下のコードを使用することで、そのパーティション内のWorkItemオブジェクトにアクセスすることができます:

     upstream_items[0].partitionItems
     

   Tip

   このノードが静的であれば、parentキーワード引数を使って、このノードがどの上流のワークアイテムから生成した新しいワークアイテムなのかを指定してください。 このノードが動的であれば、新しいワークアイテムは、その1個しか利用できない上流のワークアイテムを親ワークアイテムと見なします。

6. 私たちは、コマンドラインにはPythonのワークスクリプトを走らせることを推奨しています。その理由は、実行ファイルを直接走らせるよりも柔軟性があって、ワークスクリプトはその結果をレポートすることができるからです。

   以下のワークスクリプトの書き方のヘルプを参照してください。

   既知の共有ネットワークファイルシステムの場所にワークスクリプトを配置すれば、コマンドラインからその共有場所を使用することができます。

   または

   Houdiniマシン上のどこかにワークスクリプトを配置して、このノードの Files タブのFile Dependencyとして、そのファイルパスを設定することができます。 これによって、そのファイルが各サーバーのディレクトリ上にコピーされるようになります。 次に、コマンドラインに__PDG_SCRIPTDIR__を使用することで、その共有スクリプトディレクトリを参照することができます (別々のラッパースクリプトをコールする別々のタイプのワークアイテムを作成する場合は、それらのファイルパスを複数のFile Dependencyとして設定することができます)。

7. 通常では、このノードの Regenerate Static タブでカスタムスクリプトを書く必要はありません。

   デフォルトの実装では、何かのパラメータが変わるとワークアイテムをDirty(変更あり)にします。 通常では、これで十分なのですが、もっと賢いロジックを使いたい場合(例えば、URLのetagをチェックして、それが変更されていれば、そのワークアイテムをDirtyにしたい場合)、このタブでそれを実装することができます。

8. Add Internal Dependencies タブは、このノードから生成されたいくつかのワークアイテムを、このノードから生成された他のワークアイテムに依存させたい場合にのみ、カスタムスクリプトを書く必要があります。

9. ユーザとネットワークの間で再利用できるようにプロセッサをアセットとしてパッケージ化したい場合、Python Processorノードからアセットを構築することができます。

new_item = item_holder.addWorkItem(index=0)
new_item.setStringAttrib("url", "http://...")

new_item = item_holder.addWorkItem(index=0)

# この新しいワークアイテムのコンテキストでURLパラメータを評価します。
url = self["url"].evaluateString(new_item)
# ワークアイテムで評価された値をアトリビュートに格納します。
new_item.setStringAttrib("url", url)

new_item = item_holder.addWorkItem(index=0)
new_item.setCommand("__PDG_PYTHON__ /nfs/scripts/url_downloader.py")

command_line = self["pdg_command"].evaluateString()
new_item.setCommand(command_line)

import pdg

# 入力のワークアイテム毎に生成される新しいワークアイテムの数を取得します。
per_item = self["peritem"].evaluateInt()

if per_item > 16:
    # Too many!
    raise pdg.CookError(
        "Can't create more than 16 items per incoming item"
    )

# 新しいワークアイテムの生成を継続します...

# パラメータを評価して、その値をワークアイテムのアトリビュートにコピーする便利関数を定義します。
def set_attrs(self, work_item):
    # このワークアイテムのコンテキスト内でパラメータポートを評価します。
    url = self["url"].evaluateString(work_item)  # ダウンロード先のURLを取得します。
    outputfile = self["outputfile"].evaluateString(work_item)

    # 新しいワークアイテムにアトリビュートを設定します。
    work_item.setStringAttrib("url", url)
    work_item.setStringAttrib("outputfile", outputfile)

    # このワークアイテムが走らせるコマンドラインを設定します。
    work_item.setCommand('__PDG_PYTHON__ __PDG_SCRIPTDIR__/url_downloader.py')


if upstream_items:
    # 上流のワークアイテムが存在すれば、それらのワークアイテムから新しいワークアイテムを生成します。
    for upstream_item in upstream_items:
        # 上流のワークアイテムに基づいて、新しいワークアイテムを生成します。
        new_item = item_holder.addWorkItem(index=upstream_item.index,
                                           parent=upstream_item)
        # パラメータに基づいて、その新しいワークアイテムのアトリビュートを設定します。
        set_attrs(self, new_item)
else:
    # 上流のワークアイテムが存在しなければ、1個の新しいワークアイテムを生成します。
    new_item = item_holder.addWorkItem(index=0)
    # パラメータに基づいて、その新しいワークアイテムのアトリビュートを設定します。
    set_attrs(self, new_item)

ワークアイテムを実際にローカルマシンまたはレンダーファームに対してスケジュールを組んでから、そのワークアイテムが走らせると、そのワークアイテムはコマンドラインを実行します。 このコマンドラインには、単純に実行ファイルを走らせるコマンドラインを指定することができますが、もっと柔軟且つ便利に使えるようにするために、私たちは、そのコマンドラインにはPythonの ワークスクリプト を走らせることを推奨しています。 このワークスクリプトは、ワークアイテムのアトリビュートにアクセスして、その実行方法を制御したり、そのワークスクリプトから生成されたファイルに基づいてワークアイテム上に出力アトリビュートを設定することができます。

Python Scriptノードの場合、このワークスクリプトを __Script__フィールド内でタイプし、そのノードが生成したワークアイテムに対してそのスクリプトが実行されるように自動的に設定されます。 Python Processorノードの場合、このスクリプトを外部(レンダーファームと共有されているネットワークファイルシステム内)で作成し、あなたが作成したワークアイテムがそのスクリプトを実行するように設定する必要があります。

import os

# 現行ワークアイテムの名前は、環境変数から参照することができます。
item_name = os.environ["PDG_ITEM_NAME"]
# この名前を使ってワークアイテムのデータを照会し、そのデータからWorkItemオブジェクトを構築します。
work_item = WorkItem.fromFile(getWorkItemJsonPath(item_name))

# これは、WorkItem.fromJobEnvironment関数を使用することと同じです:
same_item = WorkItem.fromJobEnvironment()

あなたの期待通りにPython Processorノードが動くようになったのであれば、後はそのノードをアセットに変換してしまえば、そのノードが簡単に再利用できるようになります。

1. Python Processorノードを選択します。パラメータエディタで、 Save to Digital Asset をクリックします。

2. 表示されたダイアログに必要事項を記入して Accept をクリックします。

   

   この新しいアセットタイプは、Python Processorノード上のSpareパラメータを自動的に Processor タブのパラメータインターフェースとして使用するようになります。

   

   ファイルディペンデンシーには、対応モジュールが自動的に追加されます。

   

3. この新しいアセットのパラメータインターフェースを続けて編集することができます。しかし、以下の点には注意してください:

   • パラメータインターフェースを編集した際にHoudiniがSpareパラメータの処理をどうするのか尋ねてきた場合、 Destroy All Spare Parameters をクリックしてください。

   • ワークアイテムのコマンドラインを設定するための Command パラメータを参照しないのであれば、混乱を避けるために、パラメータインターフェースからそのパラメータを非表示または削除してください。