サポートチケットを作成する
フォローする

Q100311:レンダラープラグインへのライブレンダリングの実装

概要

この記事では、ライブレンダリングをレンダラープラグインに実装する方法について説明します。 取り上げる事項は次のとおりです。

  • 属性の規約
  • RendererInfoプラグイン関数
  • プラグイン関数をレンダリングする
  • Pythonユーティリティ
    - LiveRenderAPI
    -
    LiveRenderActions
    - コールバック
  • ガッチャ
    - シングルサンプルアップデート
    - 非持続的アップデート

LiveRenderingの一般的な説明についてはレンダリングタイプの Katanaオンラインヘルプのセクション、およびレンダリングの実行のライブレンダリングの開始と停止のサブセクション 、およびライブレンダリングの制御のセクションを参照してください。

レンダラプラグインの他の部分の詳細な説明、およびLiveRenderingに直接関連しないRenderAPIの他の機能のドキュメントは、Katanaオンラインヘルプのレンダラプラグイン」セクションにあります

詳しくは

属性の規約

KatanaのLive Renderingシステムは、シーングラフの属性によって強化されています。効率の観点から、レンダラーを更新するために必要な属性のみがレンダリングプラグインに送信されます。これらがどの属性であるかを判断するための属性規約があります。

liveRender <updateGroup> <属性名>

<updateGroup> - これは、属性を単一の更新にまとめるために使用されるGroupAttributeです。

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

RendererInfoプラグイン関数

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

ノードグラフで上記の属性規約を設定することは可能ですが、Live Renderの起動時に自動的に属性を設定するには、RendererInfoプラグインのfillLiveRenderTerminalOps()関数を使用するほうがより便利です。この関数には、(std :: stringとしての)op型と(GroupAttributeとしての)op引数を含むstd :: pairオブジェクトをまったく含まないstd :: dequeである、terminalOpsという引数が渡されます。

例:以下のコードは、 / 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がいくつかあります。

LiveRenderFilter

ライブレンダリングのためにどの属性を監視する必要があるかを示すために使用されます。複数の属性を単一のLiveRenderFilterで監視することができ、それらのいずれかが変更された場合はすべて単一のGroupAttributeとして送信されます。これは、 上記の liveRender 属性の規則 を設定するための標準的な方法です

OpArgs

- attributeNames (StringAttribute) - 属性の名前は変更を監視し、変更があるたびに単一の更新としてレンダリングプラグインに送信する必要があります。

- location (StringAttribute) - この操作が適用される最初の場所を定義するCEL式。それはそれからすべての子供の場所で適用されます。

- exclusions (StringAttribute) - (オプション)除外された場所の種類のリスト。このopは実行しません。

- typeAlias (StringAttribute) - (オプション)レンダリングプラグインに送信される 'type'属性の名前。設定されていない場合は、代わりに場所の種類が使用されます。

- type (StringAttribute) - (オプション)設定されている場合、opはこのタイプの場所でのみ実行されます。

- collectUpstream (IntAttribute) - (オプション)ゼロ以外の場合、各親ロケーションの各モニター対象属性の値もライブレンダリング更新に含まれます。

LiveAttribute

この操作は、(操作が完了してパラメータが確定されるのを待つのではなく)操作中にビューアマニピュレータによって生成されている値を格納します。この操作は、Live Renderingモジュールによって特に検索される特別なケースです。

OpArgs

この操作の引数は、Live Renderシステムによって自動的に設定されます。手動で設定しないでください。

LocalizeXform

ある位置のxformをそのすべての先祖からxform.matrixと呼ばれる単一のワールド空間の行列に平坦化します。

OpArgs

- excludeCel (StringAttribute) - opが適用されるべきではないシーングラフの位置を記述するCEL式。

- addMaterialHash (IntAttribute) - (オプション)古いバージョンのライブレンダリングに対する従来の動作。ゼロ以外の場合、 'material'属性のハッシュ値は 'materialHash'として保管されます。

- outputAttrName (StringAttribute) - (オプション)新しいローカルxform属性を格納するために使用する名前。デフォルトは 'xform'で、既存の属性を上書きします。

LocalizeLiveAttributeXform

ビューアでの操作中は、位置の実際のxform属性は変わりません(ペンアップまで)。代わりに、LiveAttribute opを使用して、一時xformをliveAttributes.xformの下に格納します。この操作はlocalizeXformのように機能しますが、このliveAttribute規則を認識しているため、xformの代わりにliveAttributes.xformが存在する場合はそれが使用されます。これにより、操作中に位置xformを更新できます。当然、この操作はLiveAttribute操作の後に適用する必要があります。

OpArgs

- addMaterialHash (IntAttribute) - (オプション)古いバージョンのライブレンダリングに対する従来の動作。ゼロ以外の場合、 'material'属性のハッシュ値は 'materialHash'として保管されます。

LocalizeLightListLiveRenderFilter

このOpは、ライトリストでの使用に特化した、標準のLiveRenderFilter opの特殊化です。各位置でlightList属性に関する追加情報を作成する点を除けば、LiveRenderFilter opと同じように動作します。この情報には、ライトへのパス、現在の場所でライトリンクが有効になっているかどうか、および親の場所でライトリンクが有効になっているかどうかが含まれます。この情報は "lightLink"アップデートとしてrenderプラグインに送信されます。

OpArgs

- attributeNames (StringAttribute) - 属性の名前は変更を監視し、変更があるたびに単一の更新としてレンダリングプラグインに送信する必要があります。

- location (StringAttribute) - この操作が適用される最初の場所を定義するCEL式。それはそれからすべての子供の場所で適用されます。

- exclusions (StringAttribute) - (オプション)除外された場所の種類のリスト。このopは実行しません。

- typeAlias (StringAttribute) - (オプション)レンダリングプラグインに送信される 'type'属性の名前。設定されていない場合は、代わりに場所の種類が使用されます。

- type (StringAttribute) - (オプション)設定されている場合、opはこのタイプの場所でのみ実行されます。

- collectUpstream (IntAttribute) - (オプション)ゼロ以外の場合、各親ロケーションの各モニター対象属性の値もライブレンダリング更新に含まれます。

CoordinateSystemLiveRenderFilter

これは標準のLiveRenderFilter opのもう1つの特殊化です。座標系で使用するためのものです。 LiveRenderFilter opと同じように動作しますが、現在の場所が/ root / world /のglobals.coordinatesystems属性にリストされているかどうかを最初に確認し、それが真の場合にのみ実行を継続します。

OpArgs

- attributeNames (StringAttribute) - 属性の名前は変更を監視し、変更があるたびに単一の更新としてレンダリングプラグインに送信する必要があります。

- location (StringAttribute) - この操作が適用される最初の場所を定義するCEL式。それはそれからすべての子供の場所で適用されます。

- exclusions (StringAttribute) - (オプション)除外された場所の種類のリスト。このopは実行しません。

- typeAlias (StringAttribute) - (オプション)レンダリングプラグインに送信される 'type'属性の名前。設定されていない場合は、代わりに場所の種類が使用されます。

- type (StringAttribute) - (オプション)設定されている場合、opはこのタイプの場所でのみ実行されます。

- collectUpstream (IntAttribute) - (オプション)ゼロ以外の場合、各親ロケーションの各モニター対象属性の値もライブレンダリング更新に含まれます。

レンダラプラグイン関数

 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 - この更新が対象としているシーングラフの位置。
  • attributes - 変更された属性の値場所が削除されている場合、これには deleted という名前の属性が含まれます。

この関数は、ライブレンダリング更新の受信専用の専用スレッドで呼び出されます。

 bool  hasPendingDataUpdates() 

適用する必要があるqueueDataUpdates()でキューに入れられたライブレンダリング更新があるかどうかこの関数はrenderbootプロセスに伝えます。

 int  applyPendingDataUpdates()  

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

Pythonユーティリティ

KatanaのUIには、以下に示すLive Renderingエクスペリエンスの向上に役立ついくつかのユーティリティがあります。

LiveRenderAPI

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

LiveRenderActions

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

コールバック

ライブアップデートまたはライブレンダリングコマンドをレンダープラグインに送信する前に、KatanaはそれぞれonLiveRenderUpdateまたはonLiveRenderCommandという名前のコールバックをトリガーします 。これらのコールバックには、レンダリングプラグインに渡されようとしているcommandまたはupdate属性が渡されます。これは主に監視を目的としているため、レンダープラグインに渡されるデータを調べることができますが、例外が発生してメッセージが送信されないようにすることもできます。しかしこれはKatanaのメッセージログにエラーメッセージを表示します。

ガッチャ

シングルサンプルアップデート

レンダリングが開始されると、geolibはモーションブラーなどを可能にするためにマルチサンプルアトリビュートを生成します。ただし、Katana UIでは、アトリビュートは通常1つのサンプルを使用してのみ取得され、Live Renderの更新はKatana UIから行われます。これは、ライブ更新中に送信される属性には通常、1回限りのサンプルしかないことを意味します。

非持続的アップデート

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

この記事は役に立ちましたか?
/

We're sorry to hear that!

Please tell us why.
0人中0人がこの記事が役に立ったと言っています

コメント