CydandClaude Fable 5
f0f0e3d70e
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>
Scene Restorations
Modern re-renderings of the Division dVS scenes recovered from the Glaze developer drive (see HISTORY.md) and this repo's CONTENT tree. The originals ran on Division Ltd.'s pixel-pipeline hardware in 1994–1997; these tools parse the original data files and re-render them in WebGL, in the browser.
Viewers (open in any browser, fully self-contained)
vwe-archive.html— the Scene Archive: 26 curated scenes across all projects — Star Trek (Enterprise-D, Klingon flyby), Hull Pressure (sea demos, fish schools, sunken temple), BattleTech (polar map with mech lineup, Ravine and desert maps, stadium), Red Planet (Blade arena, the Mars canal milestone demo), and the Canyon/Maya-temple Division demos. Fly camera: drag to look, WASD to fly, R resets.trek-scn.html— the original standalone Star Trek restoration (TREK.SCN and KLNGVID.SCN).
Toolkit
divformats.py— parsers for every Division format found on the drive: textVGF/VMF(DIV-VIZ2 geometry/materials, both the 1995VERSION 2:07and 199602:05dialects, with header SCALE support), binaryBGF/BMF(DIV-BIZ2) — the binary block-stream layout was recovered from Division's own reader source (DPL3/BIZREAD.C, 1994), including all 14 vertex layouts, pmesh/tristrip/polygon connectivity, LOD blocks (newer writers nest patches inside LODs; the largest LOD is taken), and embedded materials/textures/ramps — plusTGAand rawSVTtextures,SPLsplines, andSCNscene scripts.audit.py— scans every.SCNon the drive and reports what fraction of its geometry survives, and in which format.extract_all.py— extracts every scene with ≥60 % of its geometry recoverable (108 of 241 on the drive; the rest reference lost models) intoallscenes.json, resolving models/materials/textures across the drive and this repo's CONTENT dirs.gallery_build.py— curates scenes fromallscenes.jsoninto the self-containedvwe-archive.html(viagallery_template.html).convert.py/viewer_template.html— the original single-scene Star Trek pipeline.
Rebuild
python extract_all.py # requires the sda4/ drive dump beside this repo
python gallery_build.py
Fidelity notes
Faithful: vertices, triangles, material colors and shading ramps, textures,
fog and light parameters, spline motion, camera start positions. Approximated:
Division's rasterizer behavior, point sizes, timing (originals ran at 30 Hz).
Not simulated: event-driven SPECIALFX particles. A few dev scenes had camera
start positions inside geometry; those get overridden or auto-framed cameras
(see START_OVERRIDE in gallery_build.py). Scenes missing one or more
models from the drive say so in their header.