コンテンツにスキップ

カメラの切り替え

MR set 内で同時にターゲットカメラになれるのは 1 台だけですが、MR Set には Indirection Controller を使用して切り替えられる複数のカメラを含めることができます。

MR set のターゲットカメラは、MR set にルーティングされるビデオ入力を決定します。ただし、複数のカメラを MR set に追加できます。

xR でのカメラ切り替えでは、出力のすべての部分が同じフレームでビューを切り替えるように、システム内のすべての遅延を完璧に補正する必要があります。これには、ユーザーが切り替えを要求してから、その切り替えが出力に表示されるまでの間に遅延を導入する必要があります。

Disguise Controller には、6 種類の Indirection Controller タイプがあります。

  • DMXIndirectionController
  • ListIndirectionController
  • MachineListIndirectionController
  • ManualIndirectionController
  • SequencedIndirectionController
  • OSCIndirectionController
  • UDPIndirectionController

これらにより、Disguise 内でアクティブなカメラを切り替えるために複数のプロトコルを使用できるほか、外部トリガーに依存しない方法も使用できます。

これにより、Bank と Slot のメカニズムでカメラを選択できます。

  1. Disguise が DMX を受信するようにセットアップされていることを確認します。
  2. DMXIndirectionController を作成して MR Set に割り当てます。
  3. Sockpuppet bank editor で、Camera bank の一覧が利用可能になります。
  4. 選択したいカメラで bank と slot を登録します。
  5. Camera bank を選択したい Universe とチャンネルをコントローラーに入力します。
  6. slot は bank の直後の次のチャンネルなので、DMX センダーで 2 つのチャンネルを指定する必要があります。
  7. DMX 送信デバイスから、選択した Universe とチャンネルに、適切な 2 チャンネルの識別子を送信します。

これにより、0 ベースのインデックスでカメラを選択できます。

  1. ListIndirectionController を作成します。
  2. カメラを Resource として追加します。
  3. カメラの順序が Index Number になります。
  4. Index をスクロールして、アクティブなカメラを選択します。

選択される index は 0 ベースで、一覧の最初の項目は index 0 で選択されます。

選択された index を右クリックすると、index を制御する式を入力できます(例: 外部プロトコル からの制御を可能にする)。

選択された index が 0 未満、または一覧の要素数以上の場合、コントローラーは Resource として None を選択します。

これにより、特定のマシンが指定されたカメラの視点のみを出力できます。これのユースケースは、Front plate と Back plate のレンダリングを複数のマシンに分割する場合です。

  1. ManualIndirectionController を作成します。
  2. カメラを選択します。

これは IndirectionControl レイヤーのキーフレームによって制御されます。indirection control モジュールにより、indirection をタイムライン上でシーケンスできます。1 つの indirection control モジュールが 1 つの indirection を制御します。

indirection をシーケンスするには:

  1. indirection の controller フィールドに SequencedIndirectionController を追加します。
  2. タイムラインに IndirectionControl レイヤーを追加します。
  3. Indirection control モジュールでコントローラーを選択します。

これにより、OSC 経由でカメラを強制的にアクティブにできます。

  1. OSCIndirectionController を作成します。
  2. OSC Device を作成します。
  3. OSC device をコントローラーに追加します。
  4. OSC address フィールドから $ 記号を削除します。
  5. カメラをアクティブに呼び出すための文字列は、Disguise 内のカメラの名前です。現在、OSC indirection controller では、選択するオブジェクトの完全なパスを使用する必要があります。例:

path: /d3/indirection/osc

value: objects/camera/cam1.apx

これにより、UDP 経由でカメラを強制的にアクティブにできます。

  1. UDPIndirectionController を作成します。
  2. 必要な数の Resources を追加します。これはシーン内のカメラの数になります。
  3. そのアクティブなカメラをトリガーする Key を追加し、Virtual Camera となる resource を追加します。
  4. UDP センダーからの受信ポート番号を追加します。
  5. Disguise にコマンドを送信し、Current Target が変わるのを確認します。Verbose Logging をオンにして、コンソール (alt+c) で受信文字列を確認します。


カメラスイッチングのデバッグ

Section titled “カメラスイッチングのデバッグ”

XR でのクリーンなカメラスイッチングは、システム全体が正しくキャリブレーション・構成され、期待どおりに動作していることに依存します。スイッチングは、トラッキング、キャリブレーション、カメラ設定、レンダリング、システムタイミングの複合的な精度に基づいて行われます。そのため、問題はそのチェーンのどこからでも発生する可能性があります。

このセクションを使って、カメラスイッチングの問題を調査し、最も可能性の高い根本原因を特定します。

カメラスイッチングにはいくつかの前提条件があります。さらに診断を進める前に、満たされていないものを修正してください。

  • システムが完全に Genlock されている必要があります。
  • システムがフレームをドロップしていない必要があります。
  • カメラの遅延がキャリブレーションされている必要があります。
  • 各カメラが、キャリブレーションウィジェットで白のフルフレームをちょうど 1 つだけ捉えている必要があります。
  • RenderStream アセットが、フレームをドロップせずにスムーズに動作している必要があります。

デバッグは Camera Switching Debugger を使って実行できます。これには次からアクセスできます:

  • MR set → Delay Calibration → Camera Switching Debugger

カメラスイッチングデバッガー カメラスイッチングデバッガーウィジェット

ウィジェットを開くと、MR set 内のカメラスイッチを自動的に検出し、それに応じて更新します。frame フィールドのインデックスを変更して、スイッチ前後にレンダリングされたフレームをステップ実行します。すべてが正しければ、フレーム -10 の間でクリーンなスイッチが見られるはずです。

モジュールレンダリングと XR コンポジットの問題

Section titled “モジュールレンダリングと XR コンポジットの問題”

上記の前提条件が満たされると、カメラスイッチングの問題は 2 つの領域に分けられます:

  • モジュールレンダリング(例: RenderStream レイテンシーの補償)
  • XR コンポジット(LED ウォールとセットエクステンション間のコンテンツの同期)

エラーがどちらの領域から生じているかを診断するには、backplate にマッピングした単一の Video レイヤーでカメラスイッチを試みます。それがクリーンであれば、問題はモジュールレンダリングから生じている可能性が高く、そうでなければ XR コンポジットから生じているはずです。

  1. まず、システムが Genlock されており、フレームをドロップしていないことを確認します。
  2. 遅延キャリブレーション ツールを使って、各カメラの遅延がキャリブレーションされていることを確認します。
  3. 遅延キャリブレーション中に、各カメラがスクリーン上で白のフルフレームをちょうど 1 つだけ捉えていることを確認します。そうでない場合は、そうなるまでカメラのシャッター設定を調整する必要があります。 良好な遅延キャリブレーション 白のフレームが 1 つ捉えられている(良好) 不良な遅延キャリブレーション 白のフレームが 2 つ捉えられている(不良)
  4. 遅延キャリブレーションウィジェットの sync check ツールを使ってみてください。

問題が解決しない場合、ソフトウェアのバグ、ハードウェアの問題、またはその両方の組み合わせである可能性があるため、サポートの支援が必要になることがあります。

この段階に達した場合は、サポートに連絡し、以下を含む診断ログを送信してください:

  • ハードウェア構成。
  • 上記の手順の結果。
  • 各カメラの frontplate 再投影モード(特に “Minimal Latency” を使用しているものがあるかどうか)。

モジュールレンダリングの問題の診断

Section titled “モジュールレンダリングの問題の診断”

これは RenderStream モジュールのレイテンシー補償が原因である可能性が最も高く、多くの場合ストリームグラフから診断できます。

画面右下隅の FPS カウンターをクリックしてアクセスできるパフォーマンスモニターで、ストリームグラフを表示します。

ストリームグラフ ストリームグラフ

このグラフは 3 つの個別のパフォーマンス指標を追跡します:

  • Latency: 各フレームの連続的な受信レイテンシー。比較的安定しているべきで(完全に平坦である必要はありません)、高すぎないことが望まれます。
  • Active latency: モジュールの総レイテンシーで、ストリームレイテンシーの変動を吸収するバッファーを含みます。(上記とは異なり)安定しており、latency 値より高いことが望まれます。
  • Render frame delta: 各フレーム間の受信時間の差。比較的安定しており、レンダーフレーム間の予想される差の付近にあることが望まれます。

グラフが active latency に問題を示している場合、プロジェクト設定で ‘Active Latency Override’ 値を設定できます。グラフを見て、予想されるすべてのレイテンシースパイクを吸収できる十分に高い値に設定します。その後、active latency が設定値で平坦な線になるのが見られるはずです。

レンダースキューグラフ レンダースキューグラフ

  • Active latency error は、ストリームレイテンシーが active latency を超えた期間を示します(上記参照)。これはゼロであるべきで、そうでなければフレームドロップが発生する可能性が高くなります。
  • Render skew は、バッファーから取得したフレームフラグメントの予想時間と実際の時間の差を示します。これはゼロであるべきです。

グラフがストリームのパフォーマンスに問題を示している場合、シーンが十分に最適化されていない可能性があります。より軽いシーンで再現を試みて、それが原因かどうかを確認してください。より軽いシーンでも問題が解決しない場合は、開発者またはサポートによる調査が必要になることがあります。診断ログを送信し、以下の情報を含めてください:

  • ハードウェア構成
  • ストリームグラフとレンダースキューグラフの画像
  • カメラは frontplate 再投影モードに ‘Minimal Latency’ を使用していますか?
  • 1 以外のフレームレート分数を使用しているモジュールはありますか?