Interpolación de snapshots: un búfer para mantener una línea temporal remota estable

La fluidez requiere una línea temporal

Los paquetes rara vez llegan con el mismo espaciado con el que se enviaron. Si se renderiza directamente el último que llega, el momento de llegada de los paquetes se convierte en movimiento visible. La interpolación de snapshots, en cambio, reconstruye la presentación remota sobre una línea temporal con un retardo deliberado. [1] La cuestión de diseño es cuánto riesgo de datos ausentes se acepta a cambio de una cantidad determinada de retardo visual.

Búfer y acotación

Mantén los snapshots ordenados por marca de tiempo de la simulación y muestrea entre los dos que acotan el instante de renderizado elegido. Mirror documenta una implementación de búfer de snapshots y de muestreo que se puede probar de forma independiente. [2] La interpolación se mantiene dentro de las muestras conocidas. La extrapolación, en cambio, estima más allá de la muestra más reciente y, por tanto, introduce otro modo de fallo cuando el movimiento cambia de forma inesperada.

Ejemplo práctico

Supongamos un cliente ilustrativo que estima el tiempo actual del servidor en 2.16 s y elige un retardo de presentación de 0.12 s. Renderiza los objetos remotos en 2.04 s. El búfer contiene la posición 4.0 m en 2.00 s y 5.0 m en 2.10 s.

La fracción de interpolación es (2.04 - 2.00) / (2.10 - 2.00) = 0.4, lo que da la posición 4.4 m. Los tiempos de llegada de los paquetes no aparecen en esa fórmula de posición; lo que determinan es si las muestras necesarias están disponibles.

Si la muestra de 2.10 s no ha llegado, el mismo resultado ya no puede llamarse interpolación. Hay que elegir una política explícita: mantener brevemente la última pose conocida, extrapolar dentro de un horizonte definido o ajustar la línea temporal de presentación. El retardo del ejemplo es una decisión de diseño, no un valor recomendado para cualquier red.

Flujo de trabajo de implementación

Establece cómo se corresponde el tiempo del cliente con el del servidor y evita que las correcciones del reloj inviertan bruscamente la presentación. Separa la identidad del snapshot, la marca de tiempo de la simulación y la marca de tiempo local de recepción. Descarta duplicados y datos obsoletos según el protocolo, pero conserva las muestras útiles que lleguen desordenadas cuando el protocolo lo permita.

Trata la aparición, la desaparición, el teletransporte y los cambios de anclaje como eventos de ciclo de vida con límites de interpolación definidos. Para las rotaciones, usa una mezcla adecuada para rotaciones; para el estado discreto, especifica el instante del cambio en lugar de promediar identificadores. Mantén el control predicho localmente separado de la presentación remota retardada.

Límites y medición

Un búfer más largo puede absorber más variación en las llegadas, pero añade retardo visible. No puede recuperar cortes arbitrarios ni hacer fiable una colisión extrapolada. Además, las curvas de movimiento de orden superior requieren datos de entrada adecuados y un tratamiento explícito de las discontinuidades.

Mide la ocupación del búfer, la antigüedad de las muestras, los vaciados del búfer (underruns), la distancia de corrección y el retardo de presentación de extremo a extremo. Prueba pérdidas en ráfaga, reordenamiento de paquetes, deriva del reloj y un cliente que vuelve de una suspensión. Ajusta los parámetros según patrones de llegada grabados y el movimiento propio del juego, no solo según el ping medio. Un algoritmo estable debería recuperar una línea temporal útil tras una perturbación sin acumular un retardo ilimitado.

Fuentes

[1] Snapshot interpolation — Glenn Fiedler.

[2] Mirror snapshot interpolation — Mirror Networking contributors.