Mehr Realismus: 4D-Engines

Die meisten Spiele setzen heutzutage auf 3D-Engines. Mit der neuen Konsolengeneration wird der Detailgrad noch einmal erhöht. Aber ist das Realismus? Gerade bei Weltraumshootern ergibt sich oftmals die geradezu absurde Situation, dass man sehen kann, wo sich die Gegner befinden – und nicht, wo sie sich befunden haben, als Licht von ihnen ausgesendet wurde. Und obwohl man angeblich mit nahezu Lichtgeschwindigkeit c durch den Raum jagt, bekommt man keine Farbverschiebung zu sehen.

Letzteres ist leicht zu realisieren: Man müsste einfach abhängig von der Relativgeschwindigkeit einen Farbfilter über das Bild legen. Klassische 3D-Engines berechnen aber immer alle Ereignisse, die im Moment der Anzeige passieren – und geben sie direkt auf den Bildschirm. Das klappt natürlich nicht, wenn man jeweils sieht, “was da mal war“.

Die Figuren bewegen sich fast mit Lichtgeschwindigkeit, sodass der Spieler zu T2 an einem Ort ist, an dem sich gerade das Licht befindet, dass der Gegner bei T1 ausgesandt hat (pinker Kreis).
Die Figuren bewegen sich fast mit Lichtgeschwindigkeit, sodass der Spieler sich zu T2 an einem Ort befindet (pinker Kreis), an dem sich gerade das Licht befindet, dass der Gegner bei T1 ausgesandt hat.

Für eine 4D-Engine könnte man also alles im Arbeitsspeicher behalten, was der Spieler noch sehen könnte. Oder aber man berechnet Ereignisse in der Vergangenheit erst, wenn sie für die Spielergegenwart relevant werden. Für statische Objekte ändert sich praktischerweise ohnehin nichts, Bewegungen müssen parametrisiert werden. Eine Kugel, die zu einem bestimmten Zeitpunkt abgeschossen wurde, ist ein sehr einfaches Beispiel. Wenn diese nicht zwischenzeitig mit anderen beweglichen Objekten zusammentrifft, ist ihre Position zu jedem beliebigen Zeitpunkt leicht zu ermitteln. Doch eine statische Welt, in der ohne Zutun des Spielers nicht passiert, ist eher langweilig, sodass auf Simulationen außerhalb der Sichtweite nicht verzichtet werden sollte.

Doch wie hält man den Speicherbedarf gering? Ständig von jedem Punkt virtuell Photonen aussenden zu lassen ist sehr aufwändig. Wenn man sie nur in solche Richtungen abstrahlen lässt, in die der Spieler kommen könnte, bevor das Licht diese Stelle passiert hat, reduziert sich der Aufwand merklich. Im Grenzfall eines sehr langsamen Spielers wäre man bei klassischem Raytracing angelangt. Ist der Spieler aber schnell, müsste man quasi Raytracing für alle Orte machen, an die der Spieler noch kommen könnte. Keine besonders effiziente Idee.

Rettung verspricht schließlich die gute alte Demo, wie man sie aus dem E-Sport kennt. Dort werden alle Bewegungen der Spielfiguren aufgezeichnet, um das Spiel im Nachhinein noch einmal ansehen zu können. Und zwar nicht nur aus der Perspektive des Spielers. Für eine 4D-Engine muss nun allerdings die Anzeige von der Berechnung der Bewegungen abgekoppelt werden: Was gerade passiert, hat auf dem Bildschirm nichts zu suchen. Angezeigt wird nur, was sich vor einer beliebigen Zeit T genau im Abstand c×T vom Spieler befunden hat.

Frames per Second sind irrelevant

Die Leistungsfähigkeit z.B. von Grafikkarten wird oft in Bildern pro Sekunde (FPS für Frames per second) gemessen. Dabei wird unter 30 FPS angenommen, dass ein Spiel ruckelt . Das galt sehr lange Zeit als unumstößliche Wahrheit bis irgendwann mehrere Grafikkarten zusammen geschaltet wurden. Plötzlich war von „Microrucklern“ die Rede, die reinen Bilder pro Sekunde sind aber weiterhin das Maß aller Dinge – zumindest für Systeme mit einer Grafikkarte.

Faktisch zeigen allein die benötigten 30 FPS, dass das komplette Modell kaum zu gebrauchen ist: Das menschliche Gehirn kann nur 14 bis 16 Bilder pro Sekunde verarbeiten, was auch bis zu den ersten Tonfilmen im Film Standard war. Erhöht wurde die Wiederholrate dort vor allem, um die Tonqualität(!) zu erhöhen[1]. Warum aber ist ein Film mit um die 20 FPS flüssig, während ein Computerspiel über 20% mehr Bilder braucht?

Der Grund ist sehr einfach: Bei Bildern pro Sekunde handelt es sich um einen Mittelwert. Und während im Film jedes Bild immer im gleichen Abstand auf dem Schirm erscheint, kann die Berechnung in Computerspielen auch unterschiedlich lange dauern. Selbst wenn mal eine ganze Sekunde lang kein einziges neues Bild erscheint, bleibt die Framerate auf zehn Sekunden gemittelt bei 30 FPS, solange vorher und nachher jede Sekunde 33 Bilder gezeigt werden. Von einem flüssigen Spielerlebnis kann aber nicht mehr die Rede sein.

Im Film sind alle Bilder gleich verteilt, beim Spiel kann es zu Rucklern kommen.
Ruckeln entsteht, wenn zwischen Bildern zu viel Zeit gebraucht wird.

Eine einfache Lösung wäre, neben der Bildwiederholrate auch eine Standardabweichung anzugeben. Auf diese Weise arbeiten Naturwissenschaftler. Ein Kinofilm hätte hier 24±0 FPS, das oben genannte Computerspiel käme auf 30±10 FPS. Leider ist auch dieser Wert erst dann aussagekräftig, wenn man auch die Verteilung kennt. Sprich: Wie schlimm das subjektive Ruckeln ist, kann auch so nicht gesagt werden. Hätte man die Hälfte der Zeit 20 FPS, die andere Hälfte 40 FPS, käme man auf 30±11 FPS, wird aber trotz schlechterem Wert kein Ruckeln feststellen können.

Neulich habe ich[2] aber bei techreport.com eine Lösung entdeckt: Dort wird (unter anderem) die Zeit angegeben, die länger als 50 ms für einen Frame gebraucht wird. 20 FPS entsprechen genau 50ms pro Frame. Der einmalige Megaruckler von einer Sekunde würde in diesem System einen Wet von 950 ms bekommen, Kino und ruckelfreies Computerspiel bekämen einen Wert von 0 ms. Vorteil ist, dass man auf diese Weise auch sogenannte Microruckler zählbar machen kann.

So kommen eine Geforce GTX 660 Ti und eine HD 7950 auf etwa gleich viele FPS, bei der Grafikkarte mit zwei Grafikchips ist allerdings die Zeit mit „verspäteten Frames“ deutlich höher (je nach Spiel z.B. 15 ms zu 30 ms). Bekannt ist dieses Problem schon seit mindestens 2007. Damals wurde bei 3dcenter vor SLI gewarnt. Ein Nutzer berichtet, die Grafikkartenverdoppelung liefere immer zwei Bilder fast gleichzeitig, wodurch sich die Framerate natürlich verdoppelt, das Spiel aber weiterhin genau so flüssig/ruckelig bleibt wie mit nur einer Karte.

Auch wenn das Problem bei Multi-GPU-Karten mittlerweile nicht mehr ganz so schlimm zu sein scheint, halte ich es für ein Armutszeugnis, dass weiterhin an reinen FPS-Angaben festgehalten wird, obwohl diese doch in Wirklichkeit kaum etwas aussagen.

  1. [1]vgl. Bildfrequenz bei Wikipedia
  2. [2]Danke an Chemical_Brother von Linuxgaming.de für den Hinweis.