feat(review): deterministic walking capture, and the defect it exposed

The shot actor can now photograph a moving pawn: a per-shot ShotFollow flag re-places
the camera every frame at a fixed offset in the pawn's frame, and the walk is driven
per shot (SetReviewWalk) with the pawn returned to spawn after a follow shot, so the
fixed-camera shots later in the list still find it in place. With that, the capture
stopped depending on where a 4.5 m/s pawn happened to be.

Two further bugs fixed on the way:
- the engine's screenshot folder is cleared before each run. The collect step copies
  every review-*.png it finds in Saved/, so a shot retired from the camera list kept
  reappearing with byte-identical content from an older run - which is how a walk shot
  that was never captured looked like a captured one.
- UpdateBodyAnimation no longer calls SetAnimation every frame. Re-setting the same
  clip restarts it, which freezes the body on frame 0.

What the deterministic capture then exposed: the walk clip is applied but does not
advance - every walking frame shows the same pose (arms forward, legs together). The
stride shot is retired again rather than shipped, and TODO.md names the next step:
log GetCurrentAssetTime across frames and check the imported PlayRate. The harness
stays wired for when the clip plays.

Shots 6 and 7 were re-rendered after these changes and still pass; 7/7 verify.
This commit is contained in:
zwitschi committed 2026-11-09 12:11:24 +01:00
1 parent f84093adba
commit eeeabe56b1
42 files changed
+160 -68

No files matched your search

+1 -1
View File
@@ -32,7 +32,7 @@ Actionable task list for this project. This file is the single, central place fo
### Release checks
- [ ] Third-person traversal works end-to-end in the demo area. **Blocked on a capture harness, not on the game:** walking works (`-walk` holds forward input; the pawn crosses the sidewalk while the third-person rig follows), but a fixed review camera cannot catch a pawn moving at 4.5 m/s — three attempts framed it at a different distance each run and the last two missed it entirely. The stride shot was removed rather than shipped broken. Needs a camera that tracks the pawn (attach the shot camera to the pawn, or drive the capture from a recorded path), then re-add `demo-third-person-walk`.
- [ ] Third-person traversal works end-to-end in the demo area. **The harness exists now, the animation does not advance.** The screenshot actor can track the pawn (`ShotFollow`) and drive the walk per shot (`SetReviewWalk`), and the capture is deterministic — but every walking capture shows the body in one static pose (arms forward, legs together), so the walk clip is applied without playing. Next step: check whether the single-node instance is ticking at all (log `GetSingleNodeInstance()->GetCurrentAssetTime()` across frames) and whether `PlayRate` survived the import. Earlier note, superseded: walking works (`-walk` holds forward input; the pawn crosses the sidewalk while the third-person rig follows), but a fixed review camera cannot catch a pawn moving at 4.5 m/s — three attempts framed it at a different distance each run and the last two missed it entirely. The stride shot was removed rather than shipped broken. Needs a camera that tracks the pawn (attach the shot camera to the pawn, or drive the capture from a recorded path), then re-add `demo-third-person-walk`.
- [ ] No blocking animation or rig defects.
- [ ] Performance target still met at 1440p.
- [ ] Tag `v0.2.0` and write `CHANGELOG.md` entry; then remove this section.