The mech rendered with a live root and frozen limbs. Cause, and it is not in
the renderer:
L4VIDRND.CPP:1028 sets SINGLE_AXIS_HINGE True, so HingeRenderable pushes a
joint with dpl_SetDCSXAxis / YAxis / ZAxis -- three separate libDPL entry
points, each handed only (sine, cosine). The AXIS is carried by WHICH
FUNCTION WAS CALLED, and libDPL never puts it on the wire.
Confirmed against a live capture rather than argued: every articulation
record in joints_check.fifodump is 12 bytes, [handle][sin][cos], 26133 of
them, no axis field anywhere. And the renderer cannot recover it from
context either -- that capture contains ZERO action-0x22 name records, so a
DCS handle cannot be matched back to a .SKL node. vrboard was parsing those
records correctly and dropping them on purpose, with a comment saying so.
THE FIX is the archive's own alternative. The #else half of that same #if
(L4VIDRND.CPP:1153) builds a Quaternion from the Hinge and assigns it over
the DCS matrix -- the axis ends up IN the matrix, and it flushes as a
12-float pose the renderer already applies. That is precisely what
BallJointRenderable::Execute does unconditionally, with no #if at all, which
is why ball joints were never affected. So this is the branch the original
authors wrote and did not take, applied to hinges so they behave like the
ball joints beside them.
A DCS REMEMBERS HOW IT WAS LAST SET -- the part that cost a build.
The first attempt subclassed HingeRenderable and overrode only Execute. It
compiled, ran, and did not work: the wire still carried 12-byte records. What
it DID change was their contents -- the pair went from (sin, cos) to
(0.9990, 0.0000), which is m00 and m01 of the matrix being written. That is
the whole diagnosis in one number. The base ctor calls dpl_SetDCS?Axis before
the subclass gets control, which puts the DCS in single-axis mode, and the
flush then serialises two floats out of it no matter what goes in through
dpl_GetDCSMatrix.
So the axis setter must never touch this DCS. BTL4HingeRenderable therefore
derives from ChildOffsetRenderable, whose ctor builds the offset DCS and calls
no axis setter -- making it the exact hinge analogue of BallJointRenderable:
same base, holds its own attribute pointer plus a previous-value copy, writes
a full matrix in Execute. CODE/ untouched; Component::Execute is virtual
(CMPNNT.HPP:40) so the override dispatches normally, and shadowing 1900 lines
of L4VIDRND.CPP to flip one #define was not needed.
VERIFIED on the rig, torso-sweep conf, clean run:
before 26133 records, ALL 2-float, 1 handle, renderer applied NOTHING
after 7626 records, ALL 12-float, ZERO 2-float messages remaining,
22 handles emitted, renderer applied all 22 (anim_abs)
and the swept joint moves: handle 0x684, m00 across 1532 distinct values
from 0.1582 to 1.0000 -- cos of a 0..80 degree sweep, which is exactly what
BT_FORCE_TORSO drives.
LEG GAIT: NOT FIXED, and the earlier note claiming this would fix it was
wrong. The transport was necessary but not sufficient. On a walking run
(new pod_render_joints.conf = the arena mission with BT_JOINTS) all 22 joints
flush as matrices and the renderer applies them, but only handle 0x672 -- the
vehicle ROOT -- animates. The limbs emit their initial pose and never change.
Because nothing drives them. Joint::SetHinge / SetRotation exist, and the
ONLY caller anywhere in the reconstruction is TorsoSimulation
(BT/TORSO.CPP:382, horizontalJointNode->SetRotation). That is why the
torso is the one thing that moves. MAD.SKL declares JointCount=25 --
jointhip, jointlthigh, jointrthigh, jointtorso, jointshakey, jointeye and
the rest -- and the gait that should walk them is simply not reconstructed
yet. Separate piece of work, now unblocked rather than done.
HARNESS CAVEAT: pose_probe frames on "the last-articulated root" in
anim_abs. With 21 joint DCSs now landing there, that heuristic picks a joint
instead of the vehicle root and frames empty arena. The change invalidated
the assumption; the render is not evidence either way until it takes the root
handle explicitly. The counts above are the evidence.
FAULTS SEEN: two crashes during this work, both cr2=7000FA64 at host 66D9 --
the known parked load-window fault, address unmoved across a relink (which is
the standing test for "not ours"). They died at DIFFERENT points ([mer] 217
and [mer] 116), where a defect in new construction code would die
consistently. Third and fourth runs clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
f0f0e3d70e