まとめ

この記事では、ライブ レンダリングをレンダラー プラグインに実装する方法について説明し、次のトピックについて説明します。

• 属性規約
• RendererInfo プラグイン関数
• レンダリングプラグインの機能
• Python ユーティリティ
  - LiveRenderAPI
  - LiveRenderActions
  - コールバック
• 落とし穴
  - 単一のサンプリングされた更新
  - 非永続的な更新
  

LiveRendering の一般的な説明については、 Katanaユーザー ガイドの「レンダー タイプ」セクションを参照してください。また、「レンダリングの実行」の「ライブ レンダリングの開始と停止」サブセクション、および「ライブ レンダリングの制御」のセクションも参照してください。

レンダラー プラグインの他の部分の詳細な説明、および LiveRendering に直接関係しない RenderAPI の他の機能のドキュメントについては、 Katana開発者ガイドのレンダラー プラグインのセクションを参照してください。

詳しくは

属性規約

Katanaのライブ レンダリング システムは、シーン グラフの属性を利用しています。効率の名のもと、レンダラーの更新に必要な属性のみがレンダー プラグインに送信されます。これらがどの属性であるかを決定するための属性規則があります。これは次のとおりです。

ライブレンダー。 <更新グループ> 。 <属性名>

<updateGroup> - これは、属性を 1 つの更新にグループ化するために使用される GroupAttribute です。

<attributeName> - これは監視する最上位属性の名前です。上の画像では、 liveRender.geoXform.xform属性は、ライブ レンダー システムに対して、変更を最上位のxform属性に送信するように指示しています。これは StringAttribute であり、その値は通常 updateGroup と一致しますが、これはレガシーな理由によるものですが、通常は内部で使用されないことに注意してください。同じ更新グループで複数の属性が指定されている場合、それらの属性のいずれかが変更されるたびに、それらはすべてレンダラーに送信されます。

RendererInfo プラグイン関数

void fillLiveRenderTerminalOps( OpDefinitionQueue & terminalOps ,
                               const FnAttribute::GroupAttribute& stateArgs )

ノード グラフで上記の属性規則を設定することは可能ですが、通常は、RendererInfo プラグインのfillLiveRenderTerminalOps()関数を使用して、ライブ レンダーの開始時に属性を自動的に設定する方が便利です。この関数には、ターミナルOpsと呼ばれる引数が渡されます。これは、op タイプ ( std::stringとして) と op 引数 ( GroupAttributeとして) を含むstd::pairオブジェクトをまったく含まないか、複数の std::pair オブジェクトを含む std std::dequeです。

例えば。以下のコードは、 /root/world/lgtの下にあるライトの場所のxform属性の変更を監視します。

 FnAttribute::GroupBuilder opArgs;
 opArgs. set ( "type" , FnAttribute::StringAttribute( "light" ));
 opArgs. set ( "location" , FnAttribute::StringAttribute( "/root/world/lgt" ));
 opArgs. set ( "attributeNames" , FnAttribute::StringAttribute( "xform" ));
 terminalOps.push_back( std ::make_pair( "LiveRenderFilter" , opArgs.build()));

Katanaに同梱されている、ここで役立つGeolib3 Ops がいくつかあります。

レンダラープラグインの機能

int startLiveEditing()

 int stopLiveEditing()

これら 2 つの関数はKatanaから呼び出され、ライブ レンダリングがアクティブであることと、位置の更新が予想されることを通知します。

 int processControlCommand( const std::string & command )

この関数は、 Katana UI からレンダリング プラグインへの通信方法です。 UI は、Python LiveRenderAPI.SendCommand()関数を介してコマンドを文字列として送信でき、これを任意の目的に応じてレンダリング プラグインで処理できます。

 int queueDataUpdates(FnAttribute::GroupAttribute updateAttribute)

監視対象の属性が変更されると、その新しい値がこの関数を介してレンダリング プラグインに渡されます。渡された属性には 3 つの子属性が含まれます。

• type - 更新のタイプ (これは、属性規則セクションで上記にリストされている<updateGroup>です)
• location - この更新の対象となるシーン グラフの場所。
• 属性- 変更された属性の値。場所が削除されている場合は、 deleted という名前の属性が含まれることに注意してください。
  
  

この関数は、ライブ レンダー更新の受信専用の専用スレッドで呼び出されることに注意してください。

 bool hasPendingDataUpdates()

この関数は、適用すべきライブ レンダー更新がqueueDataUpdates()のキューに入れられているかどうかをレンダーブート プロセスに伝えます。

 int applyPendingDataUpdates() 

この関数はメインのレンダリング スレッドで呼び出され、キューに入れられたライブ アップデートを取得して実際に適用する必要があります。 hasPendingDataUpdates() true を返した場合にのみ呼び出されます。

Python ユーティリティ

Katanaの UI には、ライブ レンダリング エクスペリエンスの向上に役立ついくつかのユーティリティが含まれています。以下に示します。

LiveRenderAPI

この API を使用すると、 LiveRenderAPI.SendCommand()およびLiveRenderAPI.SendData()関数を使用して、カスタム コマンド (文字列) またはライブ アップデートを実行中のライブ レンダーに送信できます。また、ライブ レンダー サブシステムによって使用されている端末操作のリストをクエリおよび変更するためのさまざまな関数も備えています。これらの端末操作は、(ノードによって生成された) 現在のシーン グラフに変更を加えるのではなく、位置がいつ変更されるかを決定するために使用されます。これは、 RendererInfo::fillLiveRenderTerminalOps()への呼び出し中に渡された操作を変更する効果的な方法です。

LiveRenderActions

plugin_apis/python/BaseLiveRenderAction.py のクラスを使用して、独自のカスタム メニュー項目で [レンダリング] > [ライブ レンダリング] メニューを拡張できます。 BaseLiverRenderAction クラス (クラス自体はQtGui.QActionから派生) から派生し、メンバー関数をオーバーライドするだけです。これにより、クラスは LiveRenderAPI を含むKatanaの Python API を利用できるようになり、カスタム コマンドや更新をレンダリング プラグインに送信できるようになります。 LiveRenderActions のインスタンスは、UI セッション中にのみロードが試行されるように、$KATANA_RESOURCES/UIPlugins ディレクトリに配置する必要があります。

コールバック

ライブ アップデートまたはライブ レンダー コマンドをレンダー プラグインに送信する前に、 Katanaそれぞれ onLiveRenderUpdate または onLiveRenderCommand という名前のコールバックをトリガーします。これらのコールバックには、レンダリング プラグインに渡されるコマンドまたは更新属性が渡されます。これは主に監視を目的としており、レンダリング プラグインに渡されるデータを検査できますが、例外を発生させてメッセージの送信を防ぐこともできます。ただし、これによりKatanaのメッセージ ログにエラー メッセージが記録されます。

落とし穴

単一のサンプリングされた更新

レンダリングが開始されると、geolib はモーション ブラーなどを可能にするマルチサンプル属性を生成します。ただし、 Katana UI では、通常、属性は単一のサンプルを使用してのみ取得され、ライブ レンダーの更新はKatana UI から取得されます。これは、ライブ更新中に送信される属性には通常、単一の時間サンプルしか含まれないことを意味します。

非永続的な更新

レンダリングが開始されると、シーンを生成するための op ツリーがKatanaによってディスクに書き込まれ、独自の Geolib3 ランタイムを使用するレンダリング プロセスによって読み取られます。レンダリング プラグインには、シーン グラフとその属性をクエリするために、SceneGraphIterator へのアクセスが与えられます。ただし、このシーンは不変です。ライブ レンダー更新がKatanaから渡されると、Geolib3 ランタイムを更新できません。これは、レンダリング プラグインがライブ更新を受信した場合でも、SceneGraphIterators は常に元のシーンを返すことを意味します。したがって、SceneGraphIterator を安全に使用して追加情報を取得することはできないため、ライブ アップデート属性にはレンダー プラグインが必要とするすべての情報が含まれていることが要件となります。