Houdiniの一般的なデータI/O

Typical data I/O in Houdini

（株式会社ポリゴン・ピクチュアズ）

(Polygon Pictures Inc.)

今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。

■概要

■Overview

Houdiniではシーン構築やシミュレーション、レンダリングといった処理を行いますが、その際にインポート/エクスポートするジオメトリキャッシュやシミュレーションキャッシュなどのデータを扱うことになります。
それらに用いるファイルフォーマットは、用途に応じて使い分けを行なったりしますが、本資料ではその入門となるような、一般的によく用いられる手法をもとにご紹介したいと思います。
またHoudiniではキャッシュファイルの扱いやフォーマット、分散処理のための計算クラスター等、インフラの設計とセットで検討しなければならない点もあり、それらは効率的なファイルI/Oとも関係しています。それに付随するインフラやパイプラインにも簡単に触れたいと思います。

under construction...

■基本的な構成

■Basic configuration

■アセット管理の基本的なアプローチ

■A basic approach for asset management

Houdiniでは、外部のDCCツールである、Maya・3dsMax等のDCCツールで作成したモデルデータ・ボーン・マテリアル・アニメーション・ライト・カメラなど、さまざまなデータをHoudiniにインポートするケースがあります。AlembicやFBXといったフォーマットを使用するのが一般的ですが、最近ではUSDが使われるケースも増えてきました。
Houdiniでパイプラインを構築していくうえで、外部からのデータをどのようなフォーマットで受け取り、インポートしていくかは、パイプライン設計上、非常に重要な点となります。
各フォーマットの概要は以下のようになります。

・Alembic
SonyPicturesImageworks社とLucusFilm社によってオープンソース化された、ジオメトリキャッシュのためのファイルフォーマットです。
基本的にはベイクされた状態のジオメトリ情報を保持していて、ツール間でのデータ交換のためによく使用されます。

・FBX
もともとはMotionBuilder(旧Filmbox)のネイティブフォーマットとして開発されたもので、現在はAutodesk社で開発が続けられています。
Autodesk製品間では、標準のデータ交換フォーマットなっていて、ジオメトリの情報だけでなく、モーフィング、キーフレームアニメーション、マテリアル、テクスチャ、ライト、カメラ、階層情報、IKなどさまざまな情報を保持することが可能です。

・USD
Pixar社によってオープンソース化された、シーングラフのライブラリとなります。AlembicやFBXと同様な情報を保持できるため（USD内でAlembicデータをサポートしている）、ツール間のデータ交換フォーマットとして期待されています。
USDは単にファイルフォーマットというだけでなく、非破壊のコンポジション機能やHydraといった専用のプレビューエンジンなどもあり、コンカレントなパイプラインを構築することが可能になります。

・OBJ
歴史あるフォーマットとなり、シンプルな形状データとして現在も使われることもあるようです。一括でのobjファイルの入出力などをHoudiniで扱う場合、それなりに手間が発生するので工夫が必要ですが、非常に分かり易いデータフォーマットな為に用い続けているスタジオもあります。

・CSVなど
各種座標データなど、Houdiniでnativeにサポートしていない情報の入出力に用いるには便利な場合もあります。しかしながら、パイプライン上で扱う場合、煩雑な管理になりがちなので、他フォーマットに比べて運用時に工夫が必要になる場合があります。

上記のように、フォーマットによって格納できるデータの種類がことなるため、ワークフローに応じて必要なデータ交換のためのファイルフォーマットを選択する必要があります。

次に、インポートしたアセットからシーン構築していくシーンアッセンブルについて解説します。Houdiniで外部から受け取るデータフォーマットで、利用頻度が高いAlembicをもとに説明します。
Alembicはインポート設定やジオメトリ指定が柔軟であり、メモリ効率やクッキングスピードを考慮した方法を選択できるため、最近ではもっとも利用されているフォーマットとして使用されています。
例えば、アニメーション工程の後にAlembicキャッシュに変換し、それをHoudiniで読み込むフローの場合、アニメーションパブリッシュ後にAlembicキャッシュに変換する処理などはパイプライン上でサポートすることにより、FXショット作業開始時に必要なデータをほぼ自動でアッセンブルするといったことが可能になります。
マテリアルの情報については、レンダラーによってフローが変わっていきますが、FX要素のみをHoudini内のMantraレンダラーでレンダリングするケースが多く、その場合はHoudini上でマテリアルを作成します。また、レンダラーのプロキシファイルやシーン記述ファイル（rib, ass, rs）などを利用し、MayaなどのDCCツールからマテリアル情報を含めたかたちで、Houdiniにデータを移行し、そのまま同じレンダラーでレンダリングをすることもあります。
Alembicといったジオメトリキャッシュデータをやりとりする上では、特に大きな問題はありませんが、パイプラインのフローを考えた際に、マテリアルなどのレンダラー固有の情報についてのやりとりには、まだ手間がかかってしまうのが現状です。
今後はUSDによるシーン記述ファイルの共通化やOSLによるシェーダーファイルの共有化、MaterialXの普及などにより、これらのデータ交換がよりスムーズに行えることが期待されています。

Houdiniで作成したジオメトリを他のDCCツールへエクスポートする際も、Alembicを使用することが多いです。DCC側でHoudiniEngineを使用すればbgeoデータの読み込みが可能になり、Alembicでは扱う事の出来ないボリュームやパーティクルをDCC上でも扱えるようになります。
ポリゴン・ピクチュアズではMayaでの検証は行なっておりますが、UNITY・UE4・Cinema 4D・3dsMAXでは未確認なため、DCCツールごとにどこまで実用性があるかは利用するDCCツール上で確認してみてください。
ジオメトリではなく、ボリュームデータをエクスポートする場合はOpenVDBが主流となっています。最近ではレンダラー側のOpenVDB対応も進み、V-Ray・Arnold・Redshift・3DelightなどがOpenVDBに対応した機能を用意しており、DCCツール上では、それらを使用してインポートしレンダリングする事ができます。
パイプライン上では、キャラクターやセットとエフェクト要素をすべてアッセンブルしてライティングを行うことが可能となりますが、マテリアルはは含まれないため、インポート後にアサインする必要があります。
3dsMaxのフルイドシミュレーションプラグインであるFumeFXとPhoenixもOpenVDBを扱うことが可能で、Houdiniなどの外部ソフトウェアでシミュレーションデータを併用してシミュレーションをかけることも可能です。また、最近リリースされたNukeプラグインの"Eddy for Nuke" でもOpenVDBを扱うことができます。
Nuke内でシミュレーション・シェーディング・レンダリング・ディープコンポジットを一貫して行える為、新しいワークフローが想像できます。
OpenVDBは単にボリュームデータのためのファイルフォーマットというだけでなく、データアクセスのためのAPIやPythonラッパーなど、便利なサブモジュールも充実していることから、非常にパイプラインフレンドリーなデータライブラリとなっており、今後も発展が期待されます。

・geo/bgeo format
http://www.sidefx.com/docs/houdini/io/formats/geo.html

・Alembic
https://github.com/alembic

・FBX
https://www.autodesk.com/products/fbx/overview

・USD
https://github.com/PixarAnimationStudios/USD

・MaterialX
https://github.com/materialx

・OSL
https://github.com/imageworks/OpenShadingLanguage

・OpenVDB
https://github.com/dreamworksanimation/openvdb

under construction...

■Houdini作業上での中間ファイル

■Intermediate file on Houdini work

ノードグラフの処理結果を中間データとして一時的に保存したい場合、ネイティブジオメトリフォーマットのbgeoを使用します。ポイント・メッシュ・ボリューム等の全てのプリミティブタイプをサポートしています。
中間ファイルには、エミッター・コリジョンオブジェクト・リジッドボディオブジェクト等のシミュレーションソースや、コピー（インスタンス）に使用するジオメトリなどケースに応じて様々です。
また、シミュレーションのデータをSIMファイルとしてディスクキャッシュ化できます。エラー等で途中で止まってしまった場合に再開が可能になるのですが、場合によっては膨大なデータになりディスク容量を圧迫する事になる為、bgeoで結果のジオメトリのみを保存することが一般的です。
bgeoを書き出す前に、後の作業に不要なアトリビュートやグループなどの情報を削除する事で、ディスク容量とファイルIOが抑えられ効率化に繋がります。作業内容によって判断が必要なため、アーティストの理解が必要になりますが、こういった点をパイプライン側でサポートすることにより、ヒューマンエラーを抑制し、データサイズを効率化することが可能です。

Houdiniは14.0以降 ifd・bgeo・vdb・ratフォーマットでBlosc圧縮に対応しています。高速で効率的な圧縮のためデフォルトで利用することをおすすめします。Blosc圧縮をかけたファイルは、拡張子がgeometory.bgeo.scのようになります。

・Blosc
https://github.com/Blosc

under construction...

■シミュレーション

■Simulation

シミュレーションをおこなう上では、シミュレーションの計算に時間がかかることや、テイク回数が増えることによってストレージ内に保存するキャッシュデータが増大していくといった課題があります。
それらを解決していくために、パイプライン上での工夫が必要となります。HoudiniではHqueueと呼ばれる分散シミュレーションのためのシステムが同梱されており、一部のソルバーでは複数台のマシンを同時に利用した分散処理が可能です。
またレンダリングに使用されるようなディスパッチャをうまく利用して、階層化されたシミュレーションをフレームごとに実行し、すべてのシミュレーションを実行する前に中間の状態を確認したり、Wedgeをつかったシミュレーションのバリエーション作成をディスパッチャのなかで並列で実行することにより、無駄なシミュレーション時間を軽減することが可能です。
無駄なシミュレーション時間を減らすことは、ストレージ容量の軽減にもつながります。
またHoudiniではソルバーのOpenCL対応も行われているため、CPU/GPUをOpenCL経由で利用することにより、シミュレーションを高速化することが可能です。ただしGPUを利用する場合、VRAMサイズの制限やVRAMへのデータ転送に時間がかかり、逆にシミューレーション時間が伸びてしまうこともあるので注意が必要です。
OpenCLを利用するにはそれぞれOpenCL用のドライバをインストールする必要があります。nVIDIA社についてはCUDAと呼ばれるOpenCL相当の独自ライブラリも存在するため、Intel社ほどOpenCL対応については積極的ではない側面もあります。

・Hqueue
http://www.sidefx.com/docs/houdini/ref/hqueue.html

・OpenCL
https://jp.khronos.org/opencl/
https://software.intel.com/en-us/articles/opencl-drivers
https://developer.nvidia.com/opencl
https://developer.amd.com/tools-and-sdks/opencl-zone/

under construction...

■レンダリング

■Rendering

Mantraでイメージをレンダリングするために、Houdiniはシーン記述ファイルのifdを作成する必要があります。
レンダリング工程の効率化とHouidniライセンス節約の観点から、ifd作成の高速化とファイルサイズを抑えることが非常に大切です。その対処として最も良い方法は、レンダリングするジオメトリやボリュームデータ、ホールドアウトに使用するキャラクターやセットなど、サイズが大きいジオメトリデータをifdに毎回書き込むのではなく外部ファイルとして参照することです。
簡単な方法としては、bgeoファイルを読み込む際の設定を"Packed Disk Primitive"にすることで、データをディスクからストリームする事ができ、IFDにはその参照パスが書き込まれるだけなので、高速かつ軽量に処理する事ができます。
同じようにAlembicでは"Alembic Delayed Load Primitives"として読み込む事で外部参照にする事が出来ます。
他の方法としては、レンダリング時にジオメトリを参照するシェーダー(Delayed Load Procedural)を使う方法もありますが、現在では"Packed Disk Primitive"を使った手法が一般的です。

・Mantra
http://www.sidefx.com/docs/houdini/render/understanding.html

under construction...

■アセット管理とストレージ

■Asset management and storage

プロシージャル処理によって構築された巨大なアセットのキャッシュファイルや、シミュレーションによって生成されたキャッシュファイルはデータサイズが大きくなります。これらのデータは、Houdini上でのシーンアッセンブルや、レンダリング時に各計算クラスターから参照されるため、データI/O面の速度を考慮する必要があります。
特にキャッシュデータを読み込みながらレンダリングを行う処理では、レンダリングそのものの計算負荷よりも、データI/Oの遅さが、結果的にレンダリング時間を長くしてしまう場合もあります。
インフラへの要件としては、キャシュデータへのアクセスが頻繁に行われることを考慮し、ランダムアクセスや細かいブロックサイズのI/Oに対応できるよう、共有ストレージのディスクをオールフラッシュ(SSD)などにすることが効果的です。
数年前までは、SSDのディスクは非常に高価なものでしたが、昨今は容量単価もHDDに近づいてきており、FX用途のI/O要件に応じたストレージシステムの構築も重要なインフラ設計のひとつとなります。

・Houdini System Requirements
https://www.sidefx.com/Support/system-requirements/

under construction...

■アーティスト環境のシステム要件

■System Requirements for Artist

アーティストが共有ストレージにデータ置いて作業する場合、そのマシン環境および共有ストレージからのデータI/Oなどを考慮する必要があります。
国内ではWindows環境にて作業されているアーティスのかたも多くかと思いますが、Houdiniの特徴として多くのLinuxディストリビューションをサポートしています。一般的にHoudiniのような大きいサイズのデータI/Oが発生するソフトウェアでは、軽量なカーネルかつシンプルなドライバモデル、NFSプロトコルによるファイルストレージへのデータI/Oという利点から、Linux環境のほうが他のOSと比べ高速な動作でオペーレーションすることができます。
もちろんストレージシステム側がNFSプロトコルをサポートしている必要があり、Windows系のサーバーなどでは対応が難しく、クライアントとストレージシステムの相互での対応が不可欠となります。 またパイプライン構築にあたっても、OpenVDBやAlembicといったOSSライブラリを直接ハンドリングするケースもあり、それらのOSSをビルドする際には、ライブラリの依存関係も含め、Linuxのほうが環境構築のし易さがあります。


・Houdini System Requirements
https://www.sidefx.com/Support/system-requirements/

under construction...

※会合までに資料の内容を更新する可能性があります。

※There is a possibility to update the contents of materials by the meeting.