はじめに

Houdini 18が先日リリースされ、大いににぎわうHoudini界隈。

特に、僕の周りで関心が集まりやすいもので、実際、周りの人が使えるような環境にしているもので調整する頻度が高いのが、Game Development Toolset (GitHub Repo)。

これが、今年のSIGGRAPH2019にて、開発範囲の拡大や、開発環境の整備などを理由に改名されることが発表された。
それが、SideFX Labs Tool (GitHub Repo)である。

Houdini 18では、そのリリースと同時に、このSideFX Labs Toolもリリースされたことになる。

そこで、これらを使える環境をプロジェクトに敷くためにインストール方法を敷くことになるのだが、SideFX Labs Toolは新規のマニュアルインストール方法が採用されていることに気が付いた。

それが、果たしてどういったものなのか、イケてるインストール方法なのかなどを検証しそのノートとしてこれを書こうと思ったのがきっかけ。

先に断っておくが、僕の経験をもとに書いているため、すべてを書き起こさず、あとで見返して思い出すようのノートとして書いている。なので、ところどころ？があると思うが、そこに関して聞きたい方は、コメント欄か直接聞いてほしい。(特にツールランチャーによる、GUIで吸収できる部分などの話は、書き始めると3倍くらいは文章書かなければいけないので、冗長として省いている)

検証環境

Houdini 17.5.327 & 18.0.278 & 18.0.304
Game Development Toolset 1.220
SideFX Labs Tool >= 1.28

従来と新規のインストール方法の比較

従来のインストール方法

従来のインストール方法は以下の2種類。

Shelfのアップデーターを使う
- Game Development ToolsetのShelf機能にあるアップデーターを使用してインストールする
任意の場所に配置して、houdini.env に書く
- レポジトリをダウンロードし、任意の場所に配置し、 HOUDINI_PATH と PATH を houdini.env ファイルに記述する

1. Shelfのアップデーターを使う

これはシンプルに、Shelfツールの、このボタンを使用してインストール/アップデートする方式。

Update Toolsetを実行
インストールしたいGame Development Toolsetのバージョンを選択して、Updateボタンでインストール/アップデート

仕組みとしては、レポジトリからファイルをローカルのダウンロードして来、その場所をhoudini.envに記述する。

# GAMES DEVELOPMENT TOOLSET 
HOUDINI_PATH = $HOUDINI_PATH;$APPDATA\SideFX\GameDevToolset\17.5\1.228;&
PATH = $APPDATA\SideFX\GameDevToolset\17.5\1.228\bin;$PATH

こちらのインストール方法の利点としては、インストール場所としての確保やインストールパスの設定などの項目を気にせずに利用環境を作れることにある。

しかしながら、このローカルにダウンロードしてきてそこに対して独自にパスを通していく方法は、 よくて5-6人くらいのチームか、プロジェクトの数がそこまでないケースや中長期プロジェクトを抱えてない場合においてのみ許される運用方法。

それ以上の場合でこれを行うと、バージョンの違いによるパイプラインの乱れや、ユーザー間でのバージョン統一の整合性コントールを各人にゆだねてしまうといった、ツールの管理コストとして、TA/TDどころか各ユーザー、チームとしてのコストとして計上されてしまう。

これは、まだ少ない規模であればいいが、20-30人規模やプロジェクトの数が3つ以上になどにスケールすると、一気に混乱を呼んでしまう。
(人によっては10人規模でも耐えられなく、相談されることもある。)

さらに言えば、インハウスツールや、ユーザーごとのスクリプト開発環境を考えると、頭が痛くなるやり方なのである。。

2. 任意の場所に配置して、houdini.env に書く

こちらの方は、いわゆる環境変数を利用して、自由に配置するという方法。
プロジェクトやチームのメンバーが共通でアクセスできるファイルサーバーに配置し、そこを共通で読み生かせるという方法を仕込むことができる。

つまり、従来の方法は....

これらの二つのインストール方法からわかる通り、いずれもhoudini.envに頼った記述方法である。(maya.envファイルと同じ扱いになる)

しかし、このhoudini.envに頼った書き方は、去年のアドベントカレンダー「闇の魔術に対する防衛術 Advent Calendar 2018」として書いた記事「Houdiniと環境変数の魔導書〜補助魔法導入で失敗しないために〜」にもあるとおり、houdini.envに直接書くのはイケてないため、専用起動batなり、ツールランチャーを作るのをオススメするという事を書いた。

新規のインストール方法

新規のインストール方法は次の2通り。

従来通り、Shelfツールからインストール/アップデートする
Package機能を使ってインストールする

1の方法は、従来の方法と変わってないため、説明は省く。

そして、この記事の注目点となるのは、この2つめのインストール方法になる。

Package機能を使ってインストールする

さて、SideFXはなぜこの新規の方式を採用するという事をしたのだろうか。それは、公式のドキュメントに記載がある。

The problem is that not only the user wants to set environment variables, but also studios, plug-in authors, and so on. Multiple parties would end up rewriting or appending to the houdini.env file, sometimes causing errors or redundancy.

Also, you might want variables defined some times and not others (for example, switching between project-specific paths, or turning "experimental" assets on and off).

つまるところ、前述のhoudini.envファイルに、直接バージョンのダイレクトパスを書き込む方法のイケてないところを認めたということで、解決策として、プロジェクトごとやユーザーごとに柔軟にパッケージのバージョンを定義して、切りかえられるようにした仕組みを用意したということ。

それが、このPackage機能になる。

公式が勧めている、インストール方法の比較

Tools	Default Install	Manual Install
Game Development Toolset	Shelf Install/Update	houdini.env直接書き込み
SideFX Labs Tool	Shelf Install/Update	Package機能使用

Package機能

公式ドキュメント

Package機能の特徴

この機能は、SideFX Labs Tool以外にも、インハウスツール、ユーザーごとのツールのインストールにも適用できる、新規の方法である。

ちなみに、Houdini 17.5から使えるようになっている様だ。

Package機能は、次の項目を定義し、バージョンを切り替えることができるようになっている。

スタジオごとのデフォルトバージョン
プロジェクトごとのデフォルトバージョン
ユーザーごとのデフォルトバージョン
その他、切り離されたプラグインやツール、アドオンなど

また、下記に説明する通り、専用のエクスプレッションを使用することで、ダイナミックにパスを切り替えることができるようになっている。

Package機能を使った基本的なインストールの仕方

基本的には、以下の動画を見ればよいが、機能面での要点を検証のために記述していく。

https://youtu.be/TmTORjg6q9s?t=192

Package機能を使ったインストール方法には、専用記述方法のJsonファイルを使用する。
名前は何でもよく、例えば、 SideFXLabs.json といった感じで配置する。

そのJasonファイルの置き場所は次の通り。

$HOUDINI_USER_PREF_DIR/packages
$HFS/packages
$HSITE/houdinimajor.minor/packages (例: $HSITE/houdini18.0/packages)
$HOUDINI_PACKAGE_DIR

書き方

HOUDINI_PATH に対して、パスを通す場合の基本

SideFXLabs.json

{
    "path" : "D:/Develop/Houdini/SideFXLabsTool"
}

複数のパスを通すこともできる。

a_project_tools.json

{
    "path" : [
        "/user/bob/libs",
        "/user/tom/libs",
        "/user/sam/libs"
    ]
}

また、パスの追加メソッドも指定することができる。

a_project_tools.json

{
    "path" : 
    [
        {
            "value" : "/user/bob/libs",
            "method" : "append"
        },
        "/user/tom/libs",
        "/user/sam/libs"
    ]
}

運用プラン

さて、ではどういったケースを考え、運用するための環境構築を設定すればいいだろうか。
これについて、ケースを考えて手順を思考してみる。

プランA-A(基本編)

ケース想定

プロジェクトA(スタジオ内公開)のプロジェクトがある。
ユーザーX、ユーザーYが居る。
ユーザーXは、プロジェクトAにアクセスできる。
ユーザーYは、プロジェクトAにアクセスできる。

準備

共有ファイルサーバー(or NAS)を用意する。
共有パスにHoudiniコンフィグの場所を用意する。
- 例: S:\shared\tools\houdini\18.0
Houdiniコンフィグの置き場所にpackagesフォルダを作成する。
- 例: S:\shared\tools\houdini\18.0\packages
各種Packageファイルをpackages以下に保存する。
Packageファイルを書き換える。
各マシンのhoudini.env ファイルに、 HOUDINI_PATH=S:\shared\tools\houdini;$ を記述する。

SideFXLabs.json

{
    "env": [
        {
            "SHARED_PACKAGE_SERVER_ROOT": "S:/shared/tools/houdini/18.0/packages"
        },
        {
            "HOUDINI_PATH": {
                    "houdini_version='18.0.304'": "$SHARED_PACKAGE_SERVER_ROOT/SideFXLabsTool/1.28"
            }
        },
        {
            "PATH": {
                "method": "prepend", 
                "value": [
                    "$SHARED_PACKAGE_SERVER_ROOT/SideFXLabsTool/$SIDEFXLABS_CURRENT_VERSION/bin"
                ]
            }
        }
    ]
}

houdini.env

HOUDINI_PATH = S:\shared\configs\houdini;&

ポイント

設定には、演算子を使用した条件文をエクスプレッションで書ける。

ここでは、以下のようにHoudiniのバージョンによって、SideFX Labs Toolのパス設定をするかしないかを設定している。

{
    "HOUDINI_PATH": {
      "houdini_version='18.0.304'": "$SHARED_PACKAGE_SERVER_ROOT/SideFXLabsTool/1.28"
    }
}

この、 houdini_version という変数はあらかじめHoudini側が定義しており、それに関してはドキュメントにまとめがある。

運用

新しいSideFX Labs Toolがリリースされたら、所定の位置にインストールし、SideFXLabs.jsonのSIDEFXLABS_CURRENT_VERSIONの値を書き換える。

プランA-B

ケース想定

プランA-Aを前提とする
SideFXLabsのノードをベースに、カスタムHDAを作成し、別の場所に配置した
- Ex.) S:/shared/tools/houdini/packages/InhouseTools/otls/inhouse_sops.hda

準備

Packageファイルを作成し、プランA-Aで作成したpackagesディレクトリに保存する

inhouse_hdas.json

{
    "requires": ["SideFXLabs"],
    "env": [
        {
            "HOUDINI_OTLSCAN_PATH": {
                "method": "prepend", 
                "value": [
                    "S:/shared/tools/houdini/packages/InhouseTools/otls"
                ]
            }
        }
    ]
}

運用

新しくインハウスHDAを作る。
指定したディレクトリ以下に配置していく
- S:/shared/tools/houdini/packages/InhouseTools/otls

プランB

ケース想定

プロジェクトA(スタジオ内公開)、プロジェクトB(秘匿)、プロジェクトC(秘匿)の3プロジェクトがある。
ユーザーX、ユーザーYが居る。
ユーザーXは、プロジェクトAとプロジェクトBにアクセスできるが、プロジェクトCにはアクセスできない。
ユーザーYは、プロジェクトAとプロジェクトCにアクセスできるが、プロジェクトBにはアクセスできない。
プロジェクトBではRedshiftを使うが、全社的にも、プロジェクトCでもRedshiftを使わない。

準備

プランAの項目はすでにやっておく。
S:/projects/ のの部分は、システムのアクセス権限でコントロールできるようにしておく。
プロジェクトの共有パスにHoudiniコンフィグの場所を用意する。
- Ex.1) S:/projects/project_b/tools/houdini/18.0
- Ex.2) S:/projects/project_c/tools/houdini/18.0
各種Packageファイルをpackages以下に保存する。
- Ex.1) S:/projects/project_b/tools/houdini/18.0/packages/project_b.json
- Ex.2) S:/projects/project_c/tools/houdini/18.0/packages/project_c.json
ユーザーの houdini.env ファイルを書き換える。

project_b.json

{
    "envs": [
        {
            "PROJECT_NAME": "project_b"
        },
        {
            "HOUDINI_VERSION_ALIAS": "18.0"
        },
        {
        {
            "SHARED_PACKAGE_SERVER_ROOT": "S:/shared/tools/houdini/packages"
        },
            "PROJECT_PACKAGE_SERVER_ROOT": "S:/project"
        },
        {
            "REDSHIFT_VERSION": "3.x.x"
        },
        {
            "HOUDINI_PATH": {
                "method": "prepend",
                "value": [
                    "$PROJECT_PACKAGE_SERVER_ROOT/$PROJECT_NAME/tools/houdini/$HOUDINI_VERSION_ALIAS",
                    "$PROJECT_PACKAGE_SERVER_ROOT/$PROJECT_NAME/tools/houdini/$HOUDINI_VERSION_ALIAS/packages/redshift/$REDSHIFT_VERSION"
                ]
            }
        },
        {
            "PATH": {
                "method": "prepend",
                "value": [
                    "$PROJECT_PACKAGE_SERVER_ROOT/$PROJECT_NAME/tools/redshift/$REDSHIFT_VERSION/bin"
                ]
            }
        },
        {
            "REDSHIFT_LICENSE": "REDSHIFT_LICENSE_SERVER_IP"
        },
        {
            "REDSHIFT_COREDATAPATH": "$PROJECT_PACKAGE_SERVER_ROOT/$PROJECT_NAME/tools/redshift/$REDSHIFT_VERSION"
        }
    ]
}

project_c.json

{
    "envs": [
        {
            "PROJECT_NAME": "project_c"
        },
        {
            "HOUDINI_VERSION_ALIAS": "18.0"
        },
        {
            "SHARED_PACKAGE_SERVER_ROOT": "S:/shared/tools/houdini/packages"
        },
        {
            "PROJECT_PACKAGE_SERVER_ROOT": "S:/project"
        },
        {
            "HOUDINI_PATH": {
                "method": "prepend",
                "value": [
                    "$PROJECT_PACKAGE_SERVER_ROOT/$PROJECT_NAME/tools/houdini"
                ]
            }
        }
    ]
}

houdini.env

HOUDINI_PATH=S:/projects/project_b/tools/houdini/18.0;S:/projects/project_c/tools/houdini/18.0;S:\shared\tools\houdini;$

運用

各プロジェクトのpackages以下にツールディレクトリを掘って、そこに格納していく。(バージョンディレクトリを切って、バージョン管理をそこで行っても可)
プロジェクトのPackageファイルを書き換える。

例えばこんな感じのディレクトリ構造になる。

総評

Packageの機能の目的として、柔軟に環境設定を行えるということをやろうとしたのは受け取る事ができた。
特にいいなと思ったのは、 Required として、そのPackageが必要としている前提Packageを定義出来る点。

このPackage機能を利用する規模の組織は次のような感じになるのかとまとめてみた。
（感覚的なものなので、あくまで参考に。）

組織規模	おすすめ採用インストール方法
20人以上、または、3つ以上の中長期プロジェクト、また、さまざまインハウスツール開発と高頻度の検証・運用	ツールランチャー
10人程度、または、3つ以上の中長期プロジェクト、また、さまざまインハウスツール開発	Package機能を使ったインストール or 起動Bat
個人、または、5人以下	Shelf Toolでのインストール/アップデート

Packageは、確かに柔軟性はあるのだが、導入に少々手間を感じた。
あまりPackageファイルを増やさない方がいいとも、この検証で分かった。
なので、複雑なプロジェクト状況を持つスケールのスタジオには、対応方法としてナシではないが、あまりオススメしづらいかもしれない。

そして、その手間の数は、状況の複雑さに応じてスケールしていってしまう事がわかる。

また、こまめにSideFX Labs Toolのバージョンごとの検証などを行う場合、バージョンなどは即座に変えて検証出来たほうがいいので、文字を書き換えるのも面倒。やはり、GUIでのツールランチャーを用意して、パッケージのバージョンを切り替えつつ、Houdiniの起動を行える方がより効率的だと思う。

まとめ

ツールランチャーを作るといったことは、確かにそういった人材が所属しない組織においてはコスト高である。
なので、そこの人員は割きにくいが、プロジェクトごとにパッケージを変えたり、開発環境を排他的な状態を保ちつつ開発するといった用途で、リリース環境と開発環境を運用していく上では、このPackage機能は有用といえる。
まだ、この機能自体も出たばかりなので、これからも改善は加えられていくと思うが、もっと書き換える手間を割かずとも実装できるとうれしいなと思った。