フレームとペイロードのアルゴリズム

このページでは、実行時のデータ フローについて概要を説明します。これは、エンコーダ/デコーダの変更を確認したり、テストを追加したり、フレームに含まれるメッセージが予想よりも少ない理由をデバッグしたりするときに役立ちます。

エンコーダのフレームフロー

EncodeNow
  -> collect active TSMPNetworkBehaviour targets
  -> begin network payload
  -> for each behaviour:
       call TSMPBeforeEncode
       write enabled TransSync fields
       cancel empty VariableState messages
  -> write queued RPC messages, if any
  -> patch message count
  -> write frame header with CRC
  -> ask codec to draw header and payload into output texture

重要な行動:

• 空の VariableState メッセージはロールバックされます。
• RPC のみのフレームが許可されます。
• キューに入れられた RPC は複数のフレームにわたって繰り返すことができます。
• ペイロード コピーと FEC は現在のワイヤ形式の一部ではありません。
• 選択されたコーデックは、ペイロード開始行、容量、シンボル モード、およびオプション バイトを提供します。

ネットワークペイロードのレイアウト

+-----------------------+-----------------------------+
| Network frame header  | Message 0 | Message 1 | ... |
| 8 bytes               | variable state or RPC       |
+-----------------------+-----------------------------+

ネットワークフレームヘッダー:

オフセット	サイズ	分野
0	1	ネットワークのメジャー バージョン。
1	1	ネットワークのマイナーバージョン。
2	2	メッセージ数。
4	4	順序。

メッセージヘッダー:

オフセット	サイズ	分野
0	2	ネットワークID。
2	1	メッセージの種類。
3	1	フラグ。
4	2	メッセージシーケンス。
6	2	体長。

変数状態メッセージ

+----------------+------------------+------------------+
| Variable count | Variable value 0 | Variable value N |
| 2 bytes        | 7-byte header + data                 |
+----------------+------------------+------------------+

変数値ヘッダー:

オフセット	サイズ	分野
0	4	変数ハッシュ。
4	1	値のタイプ。
5	2	値のバイト長。

デコーダは、変数ハッシュとネットワーク ID を、生成されたバインディング エントリと照合します。

エンコーダー ルール: 動作に対して変数が書き込まれなかった場合、メッセージはキャンセルされ、メッセージ数は増加しません。

RPC メッセージ

+----------+----------------+----------------+----------------+
| RPC hash | Argument count | Argument 0     | Argument N     |
| 4 bytes  | 1 byte         | 3-byte header + data             |
+----------+----------------+----------------+----------------+

RPC 引数ヘッダー:

オフセット	サイズ	分野
0	1	値のタイプ。
1	2	値のバイト長。

デコーダはペイロード データを通じてメソッド名を解決し、TSMPBehaviour.SendCustomEvent を通じてイベントを送出します。

RPC イベントは、テクスチャ フレームの損失を許容するために、エンコーダによって少数のフレームに対して繰り返されます。

ヘッダーの検証

デコーダの検証順序:

1. バッファ範囲。
2. 魔法。
3. ヘッダーのサイズ。
4. メジャーバージョン。
5. ヘッダー CRC32。

CRC はヘッダー バイト 0..51 に対して計算されます。保存された CRC はバイト 52..55 にあります。不一致がある場合、ペイロード処理の前にフレームが破棄されます。

デコードの流れ

以下は初回・フォールバック経路です。既定の予測経路は両方のバイトパスを先に実行して1回 readback し、現在のヘッダーを検証してから payload を採用します。メタデータまたは正確な payload 長が変われば、同じスナップショットで通常の payload デコードを行い、CRC 不一致ではフレームを破棄します。カスタムコーデックと送信形式は変更しません。比較フィールド・バッファ構造・所有権は予測 readbackを参照してください。

Update / decode tick
  -> 入力を decoder 所有のスナップショットへキャプチャ
  -> スナップショットからヘッダーを読み取る
  -> validate header and CRC
  -> choose codec by codecId
  -> 同じスナップショットから PayloadSize 分の payload を取得
  -> decode network frame header
  -> iterate messages
  -> apply variable values or dispatch RPC calls
  -> update diagnostics

不正な payload を検出すると後続の処理を停止し、診断を記録します。ただし、それ以前に適用した変数や RPC の効果は巻き戻しません。フレーム全体の原子的な適用は別の課題です。

各バイトパスの GPU 準備

ヘッダーパス（Luma4）と選択した payload コーデックは、どちらも次の順で実行します。

ApplyDecodeOptions
  -> 今回のバイトマテリアルを設定
  -> PrepareDecode(source, byteMaterial)
       -> 前の LUT キーワードを解除
       -> 必要なら基準シンボルを float LUT に記録
       -> LUT を接続し、バイトシェーダー variant を有効化
  -> 準備パスと同じスナップショットからバイト Blit
  -> 個別 readback、またはヘッダー/payload をまとめて予測 readback 1回

LUT がなければ、バイトシェーダーは payload シンボルの判定中に基準ブロックを繰り返し読みます。LUT があれば、有効な各パスで基準値を一度計算し、payload のサンプリングと判定は維持します。追加パスの費用が削減する反復処理より小さい場合だけ有効です。小さい payload と大きい payload の両方で、準備とデコードの合計を測定してください。

Luma4 は有効サンプルサイズが1より大きい場合に16項目を準備し、単一サンプルでは従来経路を使います。生成テクスチャは linear ARGBFloat（各チャネル32-bit float）、Point フィルター、mipmap なしです。Half・8-bit 量子化は境界で判定を変える可能性があるため使いません。

再利用するのは割り当てであり、フレーム間の値ではありません。有効な各バイトパスで描き直します。リソース不足では従来のシェーダー経路を維持します。コーデックは生成した LUT を所有し、無効化・破棄時に解放します。マテリアルの所有権は別途管理します。

TSMPDecoder はヘッダーパスの前に、各スロットが所有する同じサイズの入力形式を維持する再利用可能な RenderTexture へ入力をキャプチャします。ヘッダー・キャリブレーション・payload の全パスは処理終了までこの画像を読みます。元画像が更新・差し替えられても異なる時点の画像が混ざりません。空きスロットはキャプチャ前にサイズを変更できます。無効化すると使用中のスロットを取り消し、空きリソースを解放します。保留中の要求は適用せず完了を待ち、その後リソースを解放・再利用できます。破棄時は所有テクスチャを解放します。キャプチャ失敗時は更新中の元画像へ戻らず処理を拒否します。

受理したデコード試行ごとに画像全体の GPU Blit が1回、割り当て済みスロットごとに形式に応じて1ピクセル4・8・16バイトのスナップショットメモリが必要です。CPU readback や通信形式のフィールドは追加しません。既定で有効な制限付き重複実行は独立した要求状態で最大2フレームを保持し、キャプチャ順に適用します。後の結果が先に完了しても前のフォールバックを待ちます。容量が埋まると新しいキャプチャをスキップし、無制限のキューは蓄積しません。判別可能な8-bit・half-float 入力は保存精度と色解釈を維持し、Float32 と不明な入力は Float32 を維持します。Udon は RenderTexture 以外の入力に保守的に Float32 を使います。所有権とリソース条件は decoder API を参照してください。入力済みの壊れた画像を修復したり、変数・RPC の適用をトランザクションにしたりする機能ではありません。

フック、マテリアル設定、ライフサイクル、フォールバックは実装ガイド、シェーダーガイド、準備 APIを参照してください。

テストを追加する場所

以下のプロトコル テストを追加します。

• ヘッダー CRC の生成と拒否。
• メッセージ数のパッチ適用。
• 空の変数メッセージのロールバック。
• RPC 専用フレーム。
• ペイロード容量の境界。
• 重複フレームおよび重複 RPC 処理。