vrsceneを利用して、3dsMAX ⇆ Houdini データコンバート 悪い点、まとめ

今回は、今まで vrscene を用いての 3dsMAX ⇆ Houdini コンバートの良い点についてちょこちょこ投稿していましたが、悪い点についても書いていこうと思います。

あくまで、僕個人の感想になりますので、本来はおかしいところもいくつか出てくるかもしれませんので、もし、参考にされる方がおられましても、自己責任でよろしくお願いいたします。



・V-Ray for Houdini の悪い点 -ストレージ容量-

Houdini から 3dsMAX へ vrscene ファイルを出力する際、vrsceneファイルは、Arnoldのassファイルのようにキャッシュ先のパスの記述だけではなく、出力しようとしているキャッシュ自身もvrsceneファイルに格納します。

元キャッシュの「bgeo.sc」「bgeo」と同じ容量のデータが、ストレージに作成されることになってしまい、ストレージを圧迫してしまいます。




V-Ray for 3dsMAX の悪い点 -連番読込未対応-

Houdiniからvrsceneファイルを出力する際は、1フレームに対し1ファイル($Fを用いた出力)か、全フレームに対し1ファイルで出力するかは選択できます。
そして、出力したvrsceneファイルをHoudiniで読込む際は、上記のどちらの方法でも対応しています。

しかし、3dsMAXで読込む際に使用する vrsceneLoader は、vrsceneの連番読込には対応しておらず、全フレームに対して1ファイルで出力されたvrsceneファイルしか読込できません。

破壊エフェクトなどは、オブジェクト数が多くなるので、フレーム数によっては、コンバートした際のvrsceneが数十~数百GBの容量のvrsceneファイルになることがあります。(Alembicを用いてコンバートする際も、3dsMAXは全フレームに対し1ファイルの読込が無難だったため、実際に状況が悪くなったわけではない)


結果、ネットワークレンダリングの際、計算を割り当てられた各マシンが、数十~数百GBの容量のvrsceneファイルに一斉にアクセスすることになり、ネットワークに負荷がかかってしまいます。



・上記の悪い点の影響

vrsceneを用いての 3dsMAX ⇆ Houdini コンバート に期待していた効果は、


・シェーディング・ライティング業務の軽減
・ネットワーク負荷の軽減

の2点でした。


1つ目の点の、シェーディング・ライティング業務の軽減においては、モデリング班と相談して、互換確認が取れているマテリアルでの作成をお願いすることにより、期待していた結果を得ることができました。


2つ目の点の、ネットワーク負荷の軽減においては、3dsMAXが全フレームに対して1ファイルのvrsceneファイルしか扱えないため、従来のAlembicを用いたワークフローの時からの改善が見られず、期待していた結果を得ることができなかった。


ただ、2つ目の問題は、3dsMAXの vrsceneLoader が連番読込に対応すれば、1ファイルの容量を減らすことができ、ネットワークの負荷を下げることができるので、V-Ray for 3dsMAX の進化に期待したいです。






以上が、テキストばかりで読みにくくなってしまいましたが、3dsMAX ⇆ Houdini コンバートの悪い点、まとめになります。

いったんこれで、vrscene周りの投稿は終了になります。
また、運用していて、新たな気づきがありましたら記事を投稿しようと思います。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です