18が先日リリースされ、大いににぎわうHoudini界隈。これが、今年のSIGGRAPH2019にて、開発範囲の拡大や、開発環境の整備などを理由に改名されることが発表された。Toolもリリースされたことになる。Toolは新規のマニュアルインストール方法が採用されていることに気が付いた。それが、果たしてどういったものなのか、イケてるインストール方法なのかなどを検証しそのノートとしてこれを書こうと思ったのがきっかけ。先に断っておくが、僕の経験をもとに書いているため、すべてを書き起こさず、あとで見返して思い出すようのノートとして書いている。ところどころ?があると思うが、そこに関して聞きたい方は、コメント欄か直接聞いてほしい。従来のインストール方法は以下の2種類。Shelfのアップデーターを使うこれはシンプルに、Shelfツールの、このボタンを使用してインストール/アップデートする方式。その場所をhoudini.envに記述する。$APPDATA\SideFX\GameDevToolset\17.5\1.228\bin;$PATHこちらのインストール方法の利点としては、インストール場所としての確保やインストールパスの設定などの項目を気にせずに利用環境を作れることにある。よくて5-6人くらいのチームか、プロジェクトの数がそこまでないケースや中長期プロジェクトを抱えてない場合においてのみ許される運用方法。それ以上の場合でこれを行うと、バージョンの違いによるパイプラインの乱れや、ユーザー間でのバージョン統一の整合性コントールを各人にゆだねてしまうといった、ツールの管理コストとして、TA/TDどころか各ユーザー、チームとしてのコストとして計上されてしまう。これは、まだ少ない規模であればいいが、20-30人規模やプロジェクトの数が3つ以上になどにスケールすると、一気に混乱を呼んでしまう。(人によっては10人規模でも耐えられなく、相談されることもある。)さらに言えば、インハウスツールや、ユーザーごとのスクリプト開発環境を考えると、頭が痛くなるやり方なのである。書くこちらの方は、いわゆる環境変数を利用して、自由に配置するという方法。プロジェクトやチームのメンバーが共通でアクセスできるファイルサーバーに配置し、そこを共通で読み生かせるという方法を仕込むことができる。従来の方法は....これらの二つのインストール方法からわかる通り、いずれもhoudini.envに頼った記述方法である。〜補助魔法導入で失敗しないために〜」にもあるとおり、houdini.envに直接書くのはイケてないため、専用起動batなり、ツールランチャーを作るのをオススメするという事を書いた。新規のインストール方法は次の2通り。従来通り、Shelfツールからインストール/アップデートするPackage機能を使ってインストールする1の方法は、従来の方法と変わってないため、説明は省く。この記事の注目点となるのは、この2つめのインストール方法になる。Package機能を使ってインストールするさて、SideFXはなぜこの新規の方式を採用するという事をしたのだろうか。それは、公式のドキュメントに記載がある。off).https://www.sidefx.com/docs/houdini/ref/plugins.htmlつまるところ、前述のhoudini.envファイルに、直接バージョンのダイレクトパスを書き込む方法のイケてないところを認めたということで、解決策として、プロジェクトごとやユーザーごとに柔軟にパッケージのバージョンを定義して、切りかえられるようにした仕組みを用意したということ。それが、このPackage機能になる。Tool以外にも、インハウスツール、ユーザーごとのツールのインストールにも適用できる、新規の方法である。17.5から使えるようになっている様だ。Package機能は、次の項目を定義し、バージョンを切り替えることができるようになっている。スタジオごとのデフォルトバージョンプロジェクトごとのデフォルトバージョンユーザーごとのデフォルトバージョンその他、切り離されたプラグインやツール、アドオンなどまた、下記に説明する通り、専用のエクスプレッションを使用することで、ダイナミックにパスを切り替えることができるようになっている。基本的には、以下の動画を見ればよいが、機能面での要点を検証のために記述していく。https://youtu.be/TmTORjg6q9s?t=192Package機能を使ったインストール方法には、専用記述方法のJsonファイルを使用する。いった感じで配置する。そのJasonファイルの置き場所は次の通り。"D:/Develop/Houdini/SideFXLabsTool"}複数のパスを通すこともできる。]}また、パスの追加メソッドも指定することができる。]}運用プランさて、ではどういったケースを考え、運用するための環境構築を設定すればいいだろうか。これについて、ケースを考えて手順を思考してみる。プランA-A(基本編)ケース想定プロジェクトA(スタジオ内公開)のプロジェクトがある。ユーザーX、ユーザーYが居る。ユーザーXは、プロジェクトAにアクセスできる。ユーザーYは、プロジェクトAにアクセスできる。共有パスにHoudiniコンフィグの場所を用意する。S:\shared\tools\houdini\18.0Houdiniコンフィグの置き場所にpackagesフォルダを作成する。S:\shared\tools\houdini\18.0\packages各種Packageファイルをpackages以下に保存する。Packageファイルを書き換える。S:\shared\configs\houdini;&ポイント設定には、演算子を使用した条件文をエクスプレッションで書ける。Toolのパス設定をするかしないかを設定している。いう変数はあらかじめHoudini側が定義しており、それに関してはドキュメントにまとめがある。Toolがリリースされたら、所定の位置にインストールし、SideFXLabs.jsonのSIDEFXLABS_CURRENT_VERSIONの値を書き換える。新しくインハウス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の項目はすでにやっておく。部分は、システムのアクセス権限でコントロールできるようにしておく。プロジェクトの共有パスにHoudiniコンフィグの場所を用意する。S:/projects/project_c/tools/houdini/18.0各種Packageファイルをpackages以下に保存する。ファイルを書き換える。各プロジェクトのpackages以下にツールディレクトリを掘って、そこに格納していく。(バージョンディレクトリを切って、バージョン管理をそこで行っても可)プロジェクトのPackageファイルを書き換える。こんな感じのディレクトリ構造になる。総評Packageの機能の目的として、柔軟に環境設定を行えるということをやろうとしたのは受け取る事ができた。して、そのPackageが必要としている前提Packageを定義出来る点。このPackage機能を利用する規模の組織は次のような感じになるのかとまとめてみた。(感覚的なものなので、あくまで参考に。Toolでのインストール/アップデートPackageは、確かに柔軟性はあるのだが、導入に少々手間を感じた。Packageファイルを増やさない方がいいとも、この検証で分かった。複雑なプロジェクト状況を持つスケールのスタジオには、対応方法としてナシではないが、あまりオススメしづらいかもしれない。その手間の数は、状況の複雑さに応じてスケールしていってしまう事がわかる。Toolのバージョンごとの検証などを行う場合、バージョンなどは即座に変えて検証出来たほうがいいので、文字を書き換えるのも面倒。GUIでのツールランチャーを用意して、パッケージのバージョンを切り替えつつ、Houdiniの起動を行える方がより効率的だと思う。まとめツールランチャーを作るといったことは、確かにそういった人材が所属しない組織においてはコスト高である。そこの人員は割きにくいが、プロジェクトごとにパッケージを変えたり、開発環境を排他的な状態を保ちつつ開発するといった用途で、リリース環境と開発環境を運用していく上では、このPackage機能は有用といえる。この機能自体も出たばかりなので、これからも改善は加えられていくと思うが、もっと書き換える手間を割かずとも実装できるとうれしいなと思った。K@takavfxGame/Film/Ads業界で、TAって役職の人。個人でやってる勉強のためにメモの内容を公開していきます。upLoginユーザーは見つかりませんでした。