PxrOSL
PxrOSL
効率性が下がっても柔軟性を追加したいユーザーは、PxrOSLノード経由でOSLへアクセスしてください。 PxrOSLノードには、2つの操作モードがあります:
Single Shader Mode:
- 1つのOSLシェーダと、オプションでそれに相当する.argsファイルを書く
- (oslcで)コンパイルする
- .osoファイル名をPxrOSLに渡すことで、 より大きなPxrPattern/PxrBxdfネットワークにノードを格納する
Network Instance Mode:
- いくつかのOSLシェーダを書く
- それらのシェーダを(oslcで).osoにコンパイルする
- 手動で、またはできればノードオーサリングシステムを使って、それらをまとめて"接続"する
- OSLネットワークのXMLファイルを作成して、ノードの相互接続を記述する
- オプションの.argsファイルを作成して、ネットワークのインターフェスを表示する
- そのネットワークをpatter/bxdfネットワークへ格納する。通常、これは1つのPxrBxdfターゲットのみで、ネットワークファイルの名前(.xmlの拡張子なし)をPxrOSLへ渡す
PxrOSLパターンは、現在、OSLの多数の機能をサポートしていますが、クロージャの使用はサポートしていませんので、注意が必要です。 その代わりにプラグインが設計され、OSL出力を他のパターンに接続し、同時にOSLシェーダの結果をいろいろなBXDFの入力へ送ることで、その後利用できるパターン結果を作成します。
このサンプルを以下に用意しています。 ここでは、2つの異なるOSLシェーダが使用されています: 1つは("Advanced RenderMan"からの)木のテクスチャを作成するシェーダで、 もう1つはカーボンファイバーのように見える2層のマテリアルを作成するシェーダです。 各サーフェスタイプでは、同じPxrDisneyシェーダが使用されていますが、 2つのまったく違うPxrOSLシェーダによって、異なるルックが作成されています。
上図のRIBファイルは、RenderMan Pro Serverインストールディレクトリの /lib/examples/RIS/scenes/pattern/osl/ディレクトリに、 OSLシェーダはその中の/shaders/サブディレクトリにあります。
PxrOSLパフォーマンスノート
PxrOSLの使用にあたり、注意が必要なパフォーマンスに関する考慮がいくつかあります。 まず、OSLは、他のPxrPatternノードのようなポイントのグリッドにわたってではなく、"垂直"にシェーダを実行します。 これにより、多数のテクスチャがアクセスを受け、テクスチャの設定がシェーディングポイントのグループ全体に連続して実行されている場合、効率性が低下することがあります。
また、シェーダとシェーダネットワークをランタイムでコンパイルするコストが著しく大きくなることがあります。 これは、特に、このコンパイルの段階により、複数のスレッドを最高効率で実行することが妨げられるためです。 普通、レンダーにしばらく時間がかかるシーンでは、このコストは事実上償却されます。 しかし、何十万もの一意のシェーダインスタンスがある場合、このコストは最終レンダー回数に影響を与えはじめます。
しかし、OSLを使用する利点の1つは、統一した入力パラメータにより、最適化された固有のマシンコードをシェーダに対して作成する機能があることです。 これらの最適化を活用するために書かれた複雑なネットワークやコードについては、パフォーマンスは著しく向上することになります。
既知の制約
現段階では、OSLのすべての操作をサポートしていません。以下については、まだサポートしていません:
- material closures
- textureinfo
- trace
- texture3d
- environment
- pointcloud_search
- pointcloud_get
- pointcloud_write
- setmessage
- getmessage
- surfacearea
- 16-bit textures
- arbitrary named transforms
尚、OSLテクスチャフィルターの3つの標準タイプのみサポートしています。
関連項目
- PxrOSLに関する技術情報および詳細な使用については、PxrOSLの使用を参照してください。