Snapshot Interpolation: Eine stabile Zeitachse für entfernte Objekte durch Pufferung

Flüssige Bewegung braucht eine Zeitachse

Pakete treffen selten in denselben Abständen ein, in denen sie gesendet wurden. Wird der jeweils neueste Zustand direkt dargestellt, wird das Paket-Timing als Bewegung sichtbar. Snapshot Interpolation rekonstruiert die Darstellung entfernter Objekte stattdessen auf einer bewusst verzögerten Zeitachse. [1] Die Entwurfsfrage lautet, wie viel Risiko fehlender Daten für ein bestimmtes Mass an visueller Verzögerung in Kauf genommen wird.

Puffern und eingrenzen

Snapshots nach Simulationszeitstempel geordnet halten und zwischen den beiden Snapshots sampeln, die die gewählte Darstellungszeit einschliessen. Mirror dokumentiert eine unabhängig testbare Implementierung von Snapshot-Puffer und Sampling. [2] Interpolation bleibt innerhalb bekannter Samples. Extrapolation schätzt dagegen über das neueste Sample hinaus und führt deshalb zu einer anderen Fehlerart, wenn sich die Bewegung unerwartet ändert.

Durchgerechnetes Beispiel

Angenommen, ein beispielhafter Client schätzt die aktuelle Serverzeit auf 2.16 s und wählt eine Darstellungsverzögerung von 0.12 s. Er stellt entfernte Objekte damit zum Zeitpunkt 2.04 s dar. Der Puffer enthält die Position 4.0 m bei 2.00 s und 5.0 m bei 2.10 s.

Der Interpolationsanteil beträgt (2.04 - 2.00) / (2.10 - 2.00) = 0.4, daraus ergibt sich die Position 4.4 m. Die Ankunftszeiten der Pakete kommen in dieser Formel nicht vor. Sie bestimmen, ob die benötigten Samples vorliegen.

Ist das Sample bei 2.10 s noch nicht eingetroffen, lässt sich dasselbe Ergebnis nicht als Interpolation bezeichnen. Dann ist eine explizite Strategie zu wählen: die zuletzt bekannte Pose kurz halten, innerhalb eines definierten Horizonts extrapolieren oder die Darstellungszeitachse anpassen. Die Verzögerung im Beispiel ist eine Entwurfsentscheidung und kein Richtwert für jedes Netzwerk.

Ablauf der Umsetzung

Festlegen, wie die Client-Zeit auf die Serverzeit abgebildet wird, und Zeitkorrekturen so gestalten, dass sie die Darstellung nicht abrupt rückwärts laufen lassen. Snapshot-Identität, Simulationszeitstempel und lokalen Empfangszeitstempel getrennt führen. Duplikate und veraltete Daten gemäss Protokoll verwerfen, nutzbare Samples in falscher Reihenfolge aber behalten, sofern das unterstützt wird.

Spawn, Despawn, Teleport und Wechsel von Attachments als Lebenszyklus-Ereignisse mit definierten Interpolationsgrenzen behandeln. Für Rotationen eine rotationsgeeignete Überblendung verwenden; bei diskreten Zuständen den Umschaltzeitpunkt festlegen, statt Bezeichner zu mitteln. Lokal vorhergesagte Steuerung (Prediction) von der verzögerten Darstellung entfernter Objekte getrennt halten.

Grenzen und Messung

Längere Pufferung fängt mehr Schwankungen der Ankunftszeit ab, erhöht aber die sichtbare Verzögerung. Sie kann weder beliebige Ausfälle ausgleichen noch eine extrapolierte Kollision verlässlich machen. Auch Bewegungskurven höherer Ordnung brauchen geeignete Eingabedaten und eine explizite Behandlung von Unstetigkeiten.

Gemessen werden sollten Pufferbelegung, Alter der Samples, Underruns, Korrekturdistanz und die gesamte Darstellungsverzögerung von Ende zu Ende. Zu testen sind Burst-Verluste, Paketumordnung, Taktdrift und ein Client, der aus einer Suspendierung zurückkehrt. Die Abstimmung erfolgt anhand aufgezeichneter Ankunftsmuster und der Bewegung des jeweiligen Spiels, nicht allein anhand der durchschnittlichen Ping-Zeit. Ein stabiler Algorithmus sollte nach einer Störung wieder eine brauchbare Zeitachse herstellen, ohne unbegrenzt Verzögerung aufzubauen.

Quellen

[1] Snapshot interpolation — Glenn Fiedler.

[2] Mirror snapshot interpolation — Mirror Networking contributors.