Results viewer: two-pass episode rendering so frame encoding cannot perturb the policy - #164
Merged
Merged
Conversation
merlerm
changed the title
merlerm
force-pushed
the
viewer-two-pass-render
branch
from
August 21, 2026 10:05
a46ce3b to
e6d6f66
Compare
tomsilver
approved these changes
Sep 1, 2026
Capturing a frame per step and encoding it into the GIF adds seconds to a rollout, and a generated policy that gates its behaviour on the wall clock then misses its own deadlines and fails an episode it solves during evaluation. A replay now rolls the policy out with rendering off and records its actions, and a second pass replays that tape into an identically seeded environment with rendering on. The reported metrics come from the first pass; a step-count mismatch between the two is logged as a divergence.
The recorder and playback shims implement the reset/step/update protocol run_episode drives, without inheriting BaseApproach's constructor state; the casts keep the annotation satisfied.
merlerm
force-pushed
the
viewer-two-pass-render
branch
from
September 2, 2026 09:14
e6d6f66 to
9c486b0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Render jobs used to call the policy with per-step
env.render()and GIF encoding inside the rollout loop. That slows the episode ~18x, and generated policies with wall-clock planning gates then fail episodes they actually solved: in transport3d run6a69a949/replicate_24, every recorded success (168-396 steps) rendered as a spurious run-to-horizon failure because the policy's 40 s internal deadline fired under render overhead (bare replays reproduce the recorded results exactly; the failure brackets between 1.3x and 1.5x slowdown).The worker now rolls the policy out once without rendering, recording the action tape — this pass supplies the reported metrics — then replays the tape into an identically seeded env for the GIF, so the policy's clock never sees frame encoding. A step-count mismatch between the passes logs a divergence warning without failing the job. Re-rendered, the four transport3d episodes come out at exactly recorded-steps+1 frames, and files shrink ~6x since divergent full-horizon renders are gone.