Mittwoch, 21. Januar 2009

Newton-Problem

Weil ich sonst nichts zu tun habe, mir fad ist, mich der Newton-Typ wieder mal aufregt und ich das
Problem ohnehin gerne mal gepostet habe, geht es jetzt noch einmal kurz um das Newton-60-FPS-Problem:
Das Problem tritt nur bei Rechnern auf, die die 60-FPS-Grenze nicht schaffen, also für einen Zeichendurchlauf (Rendervorgang) mehr als 1/60 Sekunden benötigen. Lokal ist das ganze ja wunderbar und die Maßnahme erscheint (mehr oder weniger) sinnvoll. Wenn also jemand der NewtonUpdate-Funktion reportet, dass er 1/40 Sekunden für einen Renderdurchgang benötigt hat, macht Newton einfach 1/60 daraus und aus diesem Grund fliegt der Flieger so gesehen langsamer, weil wenn man in die Geschwindigkeitsgleichung (s = v * t) einsetzt, natürlich eine geringere Wegdifferenz heraus kommt.
Problematisch wird es aber über das Netzwerk: Normalerweise sollte sich alles "von selbst synchronisieren". Da die Newton-Update bei schnelleren Rechnern sowieso öfters aufgerufen wird und bei langsameren Rechnern weniger oft, aber dafür mit größeren Zeitwerten und es sich bei den Zeitwerten um reale Werte handelt, hat eigentlich jeder immer den Realzustand (Annahme: gleichbleibende Geschwindigkeit und Rotation!). Das Flugzeug würde sich also unter der Annahme, dass es gerade aus mit konstanter Geschwindigkeit bewegt, vollkommen gleich auf jedem Rechner fort bewegen. Mangelnde Leistung wird durch größere Fortschritte kompensiert. Newton allerdings drosselt bei einer Framrate unter 60 FPS und somit wird ein Flugzeug am langsameren Rechner langsamer und das selbe Flugzeug am schnelleren Rechner fliegt mit Normalgeschwindigkeit weiter. Positionspatches würden also zu "Rucklern" führen.
Mögliche Lösungen und ihre Probleme:

  • Auf andere Engine umsteigen, Problem: Welche Alternative? Nvidia PhysX => Probleme mit ATI-Karten, Havok? Aufwand? Zeitverschwendung?
  • Geschwindigkeit so manipulieren, dass langsamere Rechner "schneller" fliegen (mehr v); Problem: Kollisionsverhalten wird sich verändern und vor allem wird sich ein anderes Stoßverhalten ergeben, etc...
  • Geschwindigkeit so manipulieren, dass Flieger von langsameren Rechnern auf schnelleren Rechnern langsamer fliegen. Problem: wie oben, unterschiedliches Kollisionsverhalten
  • Gesamtes Newton drosseln? NewtonUpdate nicht mit Realzeit, sondern mit Realzeit / FAKTOR aufrufen? FAKTOR könnte Werte zwischen 2.f und 4.f annehmen? Problem dabei: Geschwindigkeit müsste dies kompensieren, eigentlich in dem Punkt nicht schwerwiegend; Allerdings bedeutet dies auch eine Verschiebung des Kollisionsverhaltens, jedoch ist dies überall gleich. Langsamere Rechner (Rechner, die unter 60 / FAKTOR Frames per Second kommen, müssten dann allerdings ausgeschieden werden oder man gibt sich mit Rucklern zu frieden. Generell könnte man sich hier auch mit Rucklern zufrieden geben, weil auch im Internet diverse Ruckler keine Seltenheit darstellen und langsame Rechner ab einer gewissen Überlastung sowieso "ruckeln".
    => currently the best solution
Zur Netzwerksynchronisation generell würde dies mit der Vorraussetzung gelöst werden, dass jeder die gleiche Zeit hat (Berkley-Algorithmus oder Algorithmus von Christian, etc.).
Aufgrund der vergangenen Zeit zwischen Absenden des Paketes vom Client und der jetztigen Zeit kann eigentlich ziemlich unschwer auf die aktuelle Situation geschlossen werden. Natürlich handelt es sich hierbei nur um eine Vorhersage und die Vorhersage muss natürlich auch nicht stimmen, jedoch in den meisten Fällen kann man davon ausgehen, dass das Flugzeug trotzdem weiter fliegt. Auch können nach Implementierung der physikalischen Eigenschaften diverse radikale Geschwindigkeitsänderungen nicht durchgeführt werden, da auch nach Absetzen der Kraft und des Schubes noch immer aufgrund der Trägheit, etc. das Flugzeug fliegt.

Um Interpolation und Extrapolation geht es auch hier, die Seite stimmt auch ziemlich mit unseren Vorstellungen von der Thematik überein!

Keine Kommentare:

Kommentar veröffentlichen