Stream of ImprovedTerseUpdateObject vs. Moving Objects = Object that jitter/stagger/jump mid-flight

[Martin-Pitt]

Environment

Firestorm 7.2.5 (82079)
Parity with Second Life Viewer: 26.3.0
Second Life RC Magnum 2026-08-03.30838755483

but this issue is not new and has existed for decade(s) across viewers and sim versions as someone familiar with the visual bug from the combat community

Description

Fast moving objects can exhibit a visual glitch where they seem to jump around constantly along their travel path.

This is because the sim is sending a constant stream of ImprovedTerseObjectUpdate / OUT_TERSE_IMPROVED packets but sim, network/geography, and viewer conditions can all interact to cause them to arrive inconsistently. Simply put, the packet lacks a timestamp, so as the viewer processes each update, the object shifts with a correction assuming the time the packet arrived at is the correct time, instantly moving updating its position and moving it along the updated extrapolation / network interpolation. The next update hits and the process repeats.

In perfect conditions, we might see a smooth continuous flow of packet updates. In reality, I see a bullet zig-zagging as it moves.

In reality this is a stretched exaggeration of an effect that already affects every physical objects' motion across second life.

So a fix for this at the root cause (lack of timestamped updates) would improve the motion accuracy and shared experience everyone perceives. (Actually giving a lot of the different packet updates a timestamp in one big sweep would help resolve a lot of syncing issues, e.g. starting animations; Then the viewer team can implement code to use it over time)

Alternatively a viewer workaround to solve the issue for now may be possible by checking if the timing arrival of an object update was a little off compared to the last update(s) within a narrow time slice and the expectations of position, velocity and acceleration. By computing what the ideal timing should have been and then accepting it as historical reality if it fits. Well thats just an idea.

Here is a screenshot, taken after firing a single bullet moving at 200m/s upwards and stepping to the side to see it in parallax. The bullet is travelling to the right / parallel upwards from the cursor, so top left is the closest and oldest packet. With the Show Updates to Objects debug setting enabled, we can see the network updates are not a consistent line, but arriving at different times or maybe even missing. Without the debug enabled, what the users ends up seeing is a single bullet visually occupying multiple spots like mirages because the jitter happens so extremely fast.

Reproduction steps

1. Shoot a physical object from mouselook
   • upwards so it is easier to see as it can travel longer distance, the effect exists horizontally as well
   • the object should move fast like 200m/s, with 0 gravity in its settings
   • you can modify the popgun from the library for this, with a larger object for testing purposes
2. Observe the object jumping around as it travels
   • assuming you have a non-optimal network conditions; I'm from London, UK for reference
   • make sure to have max draw distance enabled
3. Developer -> Show Info -> Show Updates to Objects
4. Shoot another object from mouselook and quickly strafe to the side a bit so we can see from a slight parallax
5. Observe the object leaving a trail of blue rectangles that are not consistent or timely placed can causing the jumping around

[Martin-Pitt]

I've generated a little benchmark that tests the jitter for a simulated bullet across sim, network and viewer conditions: https://gist.github.com/Martin-Pitt/690ff8598f96412cb558dc7fb258dd60

Benchmark complete (bullet_interp_bench.py + diag scripts). Setup: 45 Hz sim with divergence-triggered terse updates (threshold 0.05 m, velocity-only prediction credit), U16 quantization, 20 ms packet flush with bundling ≤6, PDX→LHR path (8,100 km geodesic × 1.35 route factor → 54.7 ms propagation; 16 hops with exponential queuing + 2 congested hops; bufferbloat episodes; 0.5% loss + bursts; sim stalls), 60 fps viewer with hitches stamping updates at pump time. 8 seeds × 12 s flights. spd err = rms rendered-speed error vs truth — the stagger metric:

scenario / mode	wobble rms	p95	max	spd err (m/s)	snaps>1m
A harsh vanilla	4.51	10.26	13.69	61.0	66
A ping_only	5.17	12.19	16.40	71.7	65
A blend (TC 0.15s)	5.28	11.26	22.81	20.2	15.5
A timing	2.59	4.74	5.12	6.0	0.4
B clean: vanilla / timing	2.86 / 2.05			45.8 / 1.0	67 / 0
C quiet sim: vanilla / timing	0.009 both			0.003	0

Verdict: vanilla renders a 200 m/s bullet whose instantaneous speed swings ±61 m/s (30%!) frame to frame — your stagger, reproduced. Timing inversion drops it to 6.0 m/s (3%) on the harsh link, 1.0 m/s (0.5%) clean, with snaps essentially eliminated — and it never engages when the sim is quiet (C), so slow-object behavior is untouched. Notably, blind ping_only is worse than vanilla (72 m/s) — empirically confirming why the original devs disabled it ("much jumping and hopping around").

This seems to reflect my experience, per the harsh vanilla case, and also explains why ping interpolation failed to address the issue.