This latency cannot be covered up with animation

What it is

The wall drags behind a head turn; add a whoosh, a fade, motion blur, a camera ease, and the wall still drags. Motion-to-photon latency cannot be covered up with animation. The world is treated as a stationary reference. Any treatment that “lets the world animate along” performs the error rather than hiding it. A button may fade in; room geometry may not. Wrap the lag as a transition and people still see the reference slide — only more elaborately.

Animation can change how content itself moves. It cannot change the time that has already passed between the head and the photons.

Why it happens

Desktop motion works because the screen is an admitted object: easing and fades are behaviours of that object, while the bezel and the room stay put. In a headset what is late is the environment across the retina. Easing the environment is an announcement that the environment is moving — the opposite of “the environment should be still.” Motion blur paints smear into the pixels; the spatial error of the lag is still there, now plus a smear. Detection may be harder to put into words; the vestibular–visual conflict does not line up any better.

Camera animation (a landing, a hit shake, a cutscene push) is content motion, and it adds to head motion. Content motion can be designed; head-motion lag is a pose the system failed to honour. Covering system lag with content motion adds the two motions on the retina. The error grows; it does not cancel. The slide stops only when photons catch the head. Animation has no path to that.

Studying it

On a fixed suprathreshold delay, cross “cover-up animation / no animation”: a fade transition, full-screen blur, a brief camera shake, a UI whoosh. The task remains: turn the head and say whether the world stays stuck to it.

Independent variables: delay in milliseconds, kind and duration of animation. Dependent variables: detection of world slip, discomfort ratings, the share of talk that attributes the cause to “the effect” versus “delay.”

The expectation is that animation does not lower detection and often raises discomfort — because it turns a reference that should have been still into active motion. If some animation looks “better,” check whether it made people move their heads less (and so sample delay less), rather than truly covering the lag. Fewer turns is not a cover-up; it is the probe switched off.

Where it stops holding

Entrance animation that belongs to the content (a menu unfolding from the hand, a short dim on teleport landing) is not under this ban, provided it is not used to compensate head-motion lag and the rest of the world stays stuck to the head while it plays. Deliberate camera motion (a coaster, an explosion hit) is another class of nauseogenic stimulus. It is not a fig leaf for delay, and it should not be accepted in the same pass as delay. Darkening the periphery or shrinking the field can cut optic flow; that is a sickness-path change, not an MTP cover — the delay is still there, with less visual evidence. Viewers who are insensitive to animation and barely turn their heads can “not notice” both animation and delay; that viewing cannot sign off “we fixed latency with a transition.”

Applying it

• Ban camera eases, full-screen blur, and fade transitions as a “fix” for head-turn smear. The fix is to push delay back under threshold. There is no second path.
• Decouple content animation from head motion: while a cutscene plays, world pose still follows the head. Do not lock the world to a pre-baked track during a cutscene and pretend the person can still turn.
• In review, split “it looks more spectacular” from “does the world stay pinned on a head turn.” Pass the first and fail the second, and the animation is covering a failure.
• How to check: turn every entrance and transition animation on, and nod sharply. If the world still chases the head, turn all of them off and nod again. If it slides the same both times, animation covered nothing — turn them off and go fix delay. If turning them off makes people turn more and the slide show more clearly, the animation only reduced head turns, which is also not a cover-up.

Related

• Same group: N1.05.1 Latency from head motion to photon update must be extremely low · N1.05.2 Suprathreshold latency directly causes discomfort
• Nearby: N1.11 Render Latency and Motion-to-Photon Time · N1.12 Refresh Rate and Persistence
• Search terms: unmaskable motion-to-photon latency · world stability · camera animation vs latency