vwemirror/TeslaRel410
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

BT410 5.3.52: frame rate measured properly -- the missing mech skeleton is the real gap

Browse Source 
The pod updates every few seconds.  Measured by sampling a head window every
2s (emulator/render-bridge/headrate.py): OURS changed in 5 of 12 samples,
SHIPPED in 1 of 12.  So the reconstruction is not slower than the shipped
binary -- the emulated board is just expensive.  Caveat recorded with it:
ours was being driven by the throttle hooks while the shipped exe ignores
them and sat parked, so treat those as same-order, not a win.

What did cost us 3x was mine: BT_MECH_LOG/BT_LAUNCH_LOG write per-frame lines
and DEBUG_STREAM=cout is redirected to COM3, so every one goes through an
emulated serial port.  Turning them off took the wire from 480 to ~1480
bytes/sec.  pod_render_quiet.conf is the conf to use for timing work.

And a correction to my own earlier framing: wire bytes/sec is NOT a frame
rate.  Shipped pushes ~8900 B/s against our ~1480 and the difference is
CONTENT, not speed -- shipped submits the mech and we do not:

    OURS:    L4VIDEO.cpp wrong video resource type for object mad.skl
    SHIPPED: (no such line)

The mech's model resource is a SKELETON.  The engine's default
MakeEntityRenderables accepts only Object/Rubble and rejects anything else
with exactly that message, because skeletons are the GAME renderer's job.  So
our arena renders but the MECH IS ABSENT, and with it the cockpit interior --
one unimplemented path explaining both the missing model and the lower wire
volume.

Next brick is now precisely scoped: answer MechClassID by reading the .SKL
notation pages into a dpl_DCS hierarchy and hanging the per-node .BGF
geometry off it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-28 14:04:35 -05:00
co-authored by Claude Fable 5
parent 09192367c0
commit 15d509c8a8
6 changed files with 136 additions and 2808 deletions
Download Patch File Download Diff File Expand all files Collapse all files
restoration/source410/RENDER-ROADMAP.NOTES.md
+43
View File
@@ -578,3 +578,46 @@ NEXT: drive it. With controls fed (vRIO is already running in this rig) the
mech should move and the scene should animate; then the mech's own model and
the cockpit-interior renderables are what to verify against the shipped
binary, which is a cheap A/B now (pod_render_shp.conf).
--------------------------------------------------------------------------------
FRAME RATE: measured properly, and what is actually missing from the scene
--------------------------------------------------------------------------------
The pod updates roughly once every several seconds. Measured by capturing a
head window every 2s and counting changed frames (scratchpad/headrate.py):
OURS 5 of 12 samples changed (~5s between updates)
SHIPPED 1 of 12 samples changed (~24s between updates)
So the reconstruction is NOT slower than the shipped binary here -- the
emulated Division board is simply expensive, and both run the pod at this
rate. CAVEAT on that comparison: ours was being driven (BT_FORCE_THROTTLE,
speed 14.4, gauges genuinely changing) while the shipped exe ignores those
env hooks and sat parked, so it had less to redraw. Treat the two numbers as
"same order", not as a win.
WHAT DID COST US 3x, AND IT WAS MINE: BT_MECH_LOG / BT_LAUNCH_LOG write
per-frame [sim]/[mppr] lines, and with DEBUG_STREAM=cout redirected to COM3
every one of them goes out through an emulated serial port. Turning them off
took the wire from 480 to ~1480 bytes/sec. Keep per-frame logging OFF for
anything timing-related -- pod_render_quiet.conf is that conf.
DO NOT READ WIRE BYTES/SEC AS A FRAME RATE. Shipped pushes ~8900 B/s against
our ~1480, and the difference is not speed -- it is CONTENT. Shipped is
submitting the mech; we are not:
OURS: L4VIDEO.cpp wrong video resource type for object mad.skl
SHIPPED: (no such line)
The mech's model resource is a SKELETON (mad.skl). The engine's default
MakeEntityRenderables only accepts Object/Rubble resource types and rejects
anything else with exactly that message (L4VIDEO.CPP:4265), because handling
skeletons is the GAME renderer's job -- RPL4VID.HPP's ReadSKLFile /
RecurseSKLFile. So our arena renders but the MECH IS ABSENT, and with it the
cockpit interior. That single unimplemented path explains both the missing
model and the lower wire volume.
NEXT BRICK, now precisely scoped: in BTL4VideoRenderer::MakeEntityRenderables
answer MechClassID (3001) by reading the .SKL notation pages (VIDEO/*.SKL are
in the mount) into a dpl_DCS hierarchy and hanging the per-node .BGF geometry
off it -- ReadSKLFile + RecurseSKLFile per the sibling header, content from
the BT411 donor.