今年、Monique Dewanchand 氏と私は、バンクーバーの SIGGRAPH に参加できました。私たちは一緒に At Mind という小企業を持っており、Blender の開発とプロジェクトを多数行っています。下記は私の SIGGRAPH でのオープンソースの状況に対する所見です。

過去数年間、様々な VFX 企業が自社のパイプラインを公開してきました。この彼らが示してきた共通の課題が、最終的にオープンソースプロジェクトになったのです。

私たちはオープンソース BoF ミーティングをいくつか回り、そのプロジェクトの背後の人々やスタジオに会ってきました。

USD / Hydra

私が最初に Universal Scene Description をついて聞いた時は、単にシーンを非常に早く読み込む能力のある、データ交換用のファイルフォーマットだと思っていました。SIGGRAPH にて私が見たものは、USD のパワーと、彼らが解決しようとしてる問題でした。

USD の立ち位置は、スタジオ用のデータバックボーンです。スタジオはこれをレイアウトから最終レンダリングまで使用できます。アーティスティックな試行錯誤に最適化されており、さらに複数のアーティスト達が同時に同じアセットで作業することも可能です。USD を部門間のデータ転送に使用し、作業の結果を簡単に再統合することもできます。

Blender で大きなシーンの作業を行う時、全データを読み込む必要があります。Blender は読み込んだ全アセットをコントロールしているため、巨大なシーンでの作業では、思った通りの速度で動いてくれません。

Hydra はツールと統合可能な、USD を表示するためのビューポートです。シーンをディスプレイに表示するレンダラーが選択でき、OpenGL をバックエンドに持っていますが、インタラクティブレンダラー用のバックエンドも開発可能です。私は Cycles と Hydra の連携が見てみたいです。

USD/Hydra は巨大なシーンに最適化された、自身の依存グラフを持っています。私は Maya に統合された Hydra ビューポートが、非常に複雑な VFX シーンを表示するデモを見ましたが、アーティストが作業する部分（アーマチュア）のみ Maya で読み込まれていたため、非常にすばやく反応していました。

Hydra の理念は Blender の2.8ビューポートのコンセプトに合っていますが、Hydra が OpenGL 4.0を実行に要求するなどの技術的課題があります。この件についてはさらに調査することで、解決策が見つかるものと思われます。

MaterialX / ShaderX / OSL / Gaffer

複数のアプリケーションを使用する時、マテリアルに違いが生じてレンダリングされる可能性があります。MaterialX (http://www.materialx.org/) は、あるアプリケーションやレンダリングプラットフォームから、モデルの見た目を完全なまま他に転送するのに必要な、データ値や関係についての一般的でオープンな標準の表現がない問題を解決してくれます。
これにはシェーディング設定や、パターン・テクスチャリング、入れ子のマテリアル、ジオメトリックアサインメントなどが含まれます。

MaterialX はマテリアルを表現します。また、例えば一つは乾いた状態、もう一つは濡れた状態など、マテリアル毎に複数の見た目を持たせることもできます。現在、MateriariX は多数のツールに統合されており、これらの各ツールでのマテリアルの表現が同じようになります。

MaterialX が使用できるようにするには、いくつか条件があります。使用するツール間で BxDF シェーダーの共通セットに対応している必要があります。そうでない場合、表示に違いが出てくるかもしれません。現在、MaterialX ライブラリは素直に実装できるよう、いくつかの基本的なノードに OSL 記法を提供しています。将来的には GLSL 記法や他の一般的なシェーディング言語を利用可能にしたいとしています。

MaterialX にはテクスチャ用にリファレンス実装を含む、ちゃんとした標準ノードが一式揃っています。しかし、シェーディング用は説明も標準ライブラリもありません。MaterialX でのサーフェスやライト、ボリュームシェーダーはブラックボックスとして処理されています。

ShaderX は MaterialX の拡張の一つです。ShaderX はシェーダーのOSL/GLSL ソースコードへ変換する機能の提供だけでなく、シェーダー記述用に Building Block を定義しています。このコードはすぐさまコンパイル可能で、アプリケーションやレンダラーから利用可能です。

昨今、多くのスタジオでは Gaffer（http://www.gafferhq.org/）を使用しています。私は今まで Gaffer について聞いたことがなかったのですが、Beers of a Feather にて Gaffer の開発者に会いました。氏は Gaffer をルック開発のためのオープンソースプロジェクトの一つと説明してくれました。私は Blender 2.8でルック開発の作業をしていたため、興味を持ちました。

Gaffer はシーンやレンダーレイヤー、マテリアル割り当て、レンダリングやコンポジティングタスクのトリガリング用のノードベースのコンフィグレーションです。
このコンフィグレーションはシーン間で共有可能です。例えばあるキャラクターが常に Character レンダーレイヤーにレンダリングされるとします。コンフィグレーションの共有により、レンダリングを設定する多数の時間が節約できます。Blender にも RenderLayers がありますが、シーン毎に設定する必要があります。RenderLayers の設定にノードベースのシステムを持ち、レンダラーやコンポジター・シーケンサーが呼ばれるようになれば、Blender はさらに柔軟性が向上するでしょう。

OpenColorIO

過去数年間、OCIO に目だった動きはありませんでした。しかし昨今では、Autodesk さえも内部カラーマネージャーを OCIO にリプレースしているのです。彼らが行った変更は Ver2.0リリースにてリリースされる予定です。

従来のバージョンでは、OCIO の GPU と CPUの実装間に違いがありました。GPU はベイクされた LUT を使用していましたが、CPU は OCIO 設定を直接読み取っていました。Ver2.0では GPU で LUT と OCIO 設定の使用を選択できます。

スタジオは自身の OCIO 設定を作成する必要があります。しかしこれらの設定の大半、例えばカメラや標準の色空間などの OCIO 情報はスタジオ間で完全に同じで、スタジオはこの問題を解決したいと思っていますが、多分このことは OCIO の範疇にはないため、OCIO に含まれるようにはならないと思われます。（訳注：この辺あやふやです。要は共通情報はテンプレ化したいが、そこは OCIO の守備範囲ではない…という話だと解釈しました）

VFX リファレンスプラットフォーム

VFX リファレンスプラットフォーム（https://www.vfxplatform.com/）は、（以上とは）全く別の物です。オープンソースプロジェクトではありませんが、バイナリ互換性を確実に向上する、ソフトウェアバージョンにおける標準化のための業界の試みの一つです。理想では、単一のコードベースまたはバイナリから、複数のアプリケーションで実行するアドオンの開発が行えます。

業界が一丸となり、Python 2から Python 3への移行のような、非常に難しい問題について話し合えることが、この手のプラットフォームの力です。

数年前（Blender 2.5、2009年）、Blender も（Python 移行を）行いましたが、私の経験によれば、これは非常に難しいタスクです。私はスタジオとソフトウェアベンダー間の議論の方法に感銘を受けました。
その結果、2019年ではメジャーなソフトウェアパッケージは Python 2と3の両方に対応されるようになり、スタジオは自身のパイプラインの移行が開始できます。目標は2020年に Python 3が標準になることです。

Blender にとってこのリファレンスプラットフォームは私たちが待ち望んでいた物で、スタジオへのサポートが改善できるでしょう。