[GuvenHuso]

A rocket launcher's melee was drawn at 30 Hz at any frame rate.

The first-person pose (render_interpolation_first_person) was blended between ticks only while no node moved more than 0.25 world units relative to the camera in a tick. That limit was there to tell another weapon's skeleton from this one moving, but the rocket launcher's melee, and other wide, fast animations, move further, so the whole pose snapped on every tick of the swing.

Changes

• The pose remembers the weapon and the animation graph it was of, and blends only from the same weapon's and graph's pose of the tick just before. A weapon switch still snaps, even between two frames of one tick, while the weapon's own animations blend however far they move. The distance limit is gone; a position that is not a number still snaps the pose.
• A node whose two rotations are about half a turn apart (the rocket launcher's barrels set back after a shot) snaps alone, since which way it turned cannot be told. The other nodes still blend.
• first_person_weapon_build_node_matrices passes the weapon and its first-person animation graph (a port: change in source/interface/first_person_weapons.c).

Only what is drawn changes, nothing the machines send or agree on, so the network version is unchanged.

Checked

• ninja windows.
• tools/harness/tests/test_first_person_interpolation.py: 8 cases (melee, weapon and graph switches, a switch within a tick, a gap, a node not a number, a half turn, a 170° turn) and 6 negative controls that must fail, the old 0.25 limit among them.
• The whole harness on Windows fails the same tests as testing does there (the Windows environment's) and passes the 14 new ones.
• Not built for Android or the web locally; CI builds both.

🤖 Generated with Claude Code