CydandClaude Fable 5 ed218483ec BT410 5.3.81: the canopy question answered -- our wire is right, the bridge cannot decode it ...

Decoding the articulated run's fifodump settles it, and the answer is not in
our code.  26133 vr_flush_dcs_artic records this run (was ~200), every one
n=1 with a 12-byte body: [handle][sine][cosine].  Sample: handle 0x684,
sine -0.04536 cosine 0.99897 = -2.60 deg, then -7.60 deg.  That is the torso
twist sweeping, authentically encoded -- our HingeRenderable emits exactly
what the 1995 engine emits.

vrboard's 0x1f parser accepts record widths 12, 2 and 5 floats but only
applies the 12-float form: "joint sin/cos records: axis semantics unknown --
the flushed matrix stands (mech limbs won't articulate yet)".  So the canopy's
DCS never rotates in the bridge's scene while its camera picks the twist up by
another route, and the two diverge -- the artefact.  anim_abs reading 0 in the
same run is innocent: the root only re-flushes when localToWorld changes, and
this mech is deliberately stationary.

The axis genuinely is not on the wire: dpl_SetDCSXAxis/YAxis/ZAxis all take
(dcs, sin, cos) and all produce the same record (DPL_VPX.H:23-25), so the
board carries it per node.  A stream-only decoder cannot recover it.

Two ways forward, both legitimate: tell the bridge the axis out of band (the
.SKL's Type=hingex/y/z names it per node -- a handle->axis map at scene-build
time, and this fixes the leg gait too), or use the engine's other hinge path
(HingeRenderable::Execute is written both ways behind #if SINGLE_AXIS_HINGE;
the #else branch writes a full matrix, producing the 12-float records the
bridge already applies).  Both are the shipped engine's own code.

The reconstruction's articulation work is done and correct as of 5.3.80; what
remains is a decoder gap in the viewing tool.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-29 20:53:26 -05:00

3.0 MiB

Raw History

View Raw