P2: projectile art and texture animation remain approximate

#53 · closed · 2 comments

View on GitHub ↗

STRML

- Flying disc is now blue/additive with a glow, and its orientation uses velocity plus projected world-up to remove cardinal-direction-dependent roll. Its plate is still procedural geometry; glow is a textured plane. - Blaster ball/trail and Chaingun crossed-ribbon tracers are approximations. Shrike bolts are blue, but the shot origin does not reproduce alternating twin muzzle emission. Inspect `weapons-view.ts` and sim `projectiles.ts`. - `disc-explosion.ts` now plays the original animated `disc_explosion` shape, camera-facing and additive. Texture lists (IFL) still use only their first frame, including weapon indicators and effect textures. A loading fallback remains. - Acceptance: source-frame comparisons for all five weapons and Shrike at several distances/headings, original texture sequence playback, and separate geometry animation versus texture-animation tests. Do not reapply world yaw to FP models. Continuation context: [docs/ISSUES.md](https://github.com/STRML/clans/blob/main/docs/ISSUES.md).

Comments

STRML

The playback machinery is real and tested (12-resource frame table at 30 Hz injected into `withVisibility`, keyed off the GLB's `ifl_sequence`/`ifl_duration`/`ifl_cyclic`, with a frame cache and clone rebinding). What is missing is the data: only frame-0 PNGs are committed under the shipped textures, so every sequence holds frame 0. Blaster ball and trail and the Chaingun crossed-ribbon tracers remain approximations, and the Shrike's alternating muzzle is a client-side tail shear rather than a sim-side per-side origin. Frame extraction is in progress. --- Status verified against the code at `d1ba6db` by an automated sweep over this backlog. Left open deliberately.

STRML

Closing against the code, with each item in the body checked separately. **IFL texture animation** -- done. The playback driver has a 12-resource frame table at 30 Hz, and all **104 sequence frames** are committed under the manifest keys, so the sequences advance instead of holding frame 0 (commit `e3f79ff`). **Blaster bolt** -- was the named approximation, now the datablock's own rendering. `EnergyBolt` (`weapons/chaingun.cs`'s sibling `blaster.cs`) gives `scale = "0.25 20.0 1.0"` for the stretched quad, `crossSize = 0.55` for the cross, and textures `special/blasterBolt` / `special/blasterBoltCross`; the bolt is now exactly those two quads at those sizes, and the positional-history line that stood in for the trail is deleted because the stretched quad IS the trail. `blasterBoltCross.PNG` (2,213 bytes) joins the manifest. Commit `c3aa30a`, with a browser case that asserts both sizes and both textures decoded, and a unit case pinning the same numbers. **Chaingun tracer** -- not an approximation: our values already are the source's own. `TracerProjectileData` (`weapons/chaingun.cs`) gives `tracerLength 15.0`, `tracerWidth 0.10`, `crossSize 0.20`, `tracerColor 211/215/120 @ 0.75` and `tracerTex = special/tracer00` + `special/tracercross`; `weapons-view.ts` uses 15, 0.10, 0.20, `0xd3d778` (211/215/120) and both textures. The crossed-ribbon geometry is how the source renders a tracer (`renderCross = true`, `tracerTex[1]` at `crossSize`), not a stand-in for it. **Shrike bolt** -- same finding. `ScoutChaingunBullet` gives `tracerLength 45.0`, `tracerWidth 0.55`, `crossSize 0.99`, `tracerColor "1.0 1.0 1.0 1.0"` and the `shrikeBolt`/`shrikeBoltCross` pair; our `SHRIKE_BOLT_LENGTH` 45, width 0.55, cross 0.99 and white all match. **Per-side Shrike muzzle origins** -- done. The simulation alternates the paired image slots as `%obj.nextWeaponFire` does, reports the side on the fire event, and carries it onto the projectile; the client uses the shot's own side rather than inferring one. The projectile record grew a byte for it, so that shipped as protocol 12 (commit `b949ba6`). What is NOT reproduced, from the blaster bolt's own datablock: its `hasLight` (radius 3.0, colour `0.5 0.175 0.175`) and its `blurLifetime 0.2` / `blurWidth 0.25` trail. Both are presentation details that do not affect where the bolt is, and they are named here rather than implied. Verified at HEAD: 1,300 unit tests, 40 browser cases, and `tsc -b`, `eslint .`, `prettier --check .` all exit 0. --- Verified against the code by an automated pass; reopen if that verification is wrong.