News Gears of War 4: Dynamic Resolution auf PC und Konsole

[Blubmann]

Dieses "echte 1080p" ist doch auch nur Augenwischerei, denn was nützt das wenn an manchen Stellen dafür die FPS auf einstellige Werte zusammenbrechen?

Das ist korrekt. Mein Punkt ist, ich möchte als Kunde nicht noch weiter/mehr verarscht werden.

 

[Jesterfox]

Was wäre demnach dein Lösungsvorschlag? Eine konstant laufende Auflösung und Framerate ist technisch nicht möglich das sich der Berechnungsaufwand je nach Situation immer mal unterscheiden kann... einfach mal dauerhaft die Qualität so weit zu reduzieren das man immer genug Luft hat kann ja auch nicht die Lösung sein, oder?

 

[MrZweistein]

Grundsätzlich beobachtet die Engine, wie lange die Frametimes sind. Wenn die Frametimes steigen, wird die Auflösung schrittweise reduziert, wenn die Frametimes kürzer werden, wird die Auflösung schrittweise erhöht.

Soweit ich weiß, gibts für VR eine ähnliche Methodik, die die Grafikdetails dynamisc reduziert, so dass immer exakt 90 FPS garantiert werden.

Natürlich braucht die Methode einen kleinen Leistungspuffer, so dass nicht jeder winzige Frametime anstieg gleich in einem FPS drop unter 60 FPS mündet. Auch wird man hin und wieder wohl einen einzelnen Einbruch auf 59 statt 60 FPS nicht vermeiden können, wenn die Last stark ansteigt, aber grundsätzlich ist das ganze rein logisch extrem einfach zu managen. Der Trick ist: Die Engine muss es beherrschen.

Die Engine muss das nicht beherrschen, das lässt sich sehr einfach über ein eigenes Skript einbauen, in welchem die Zeit für einen Rendervorgang gemessen wird. Dabei werden vorher die Schwellwerte für das Absenken und das Zurückkehren der Auflösung festgelegt, da es sich bei der verfügbaren Zeit ja um Konstanten handelt. Das macht das ganze selbst extrem einfach, da nur zwei Vergleiche zu berechnen sind:

gemessene Render Zeit größer oberer Schwellwert: Nächstes Frame Auflösung reduzieren (Horizontaler Pixelcount - k)
gemessene Render Zeit kleiner unterer Schwellwert: Nächstes Frame Auflösung erhöhen (Horizontaler Pixelcount + k)

Das Arbeiten mit zwei unterschiedlichen Schwellwerten erleichtert die Optimierung damit Auflösungen nicht zu oft wechseln. Ein andere Möglichkeit wäre noch den Vergleich auf den Durchschnitt der letzten x Frames zu machen um zusätzlich Höhen und Tiefen in den Zeiten zu glätten.

 

[Laggy.NET]

Genau das meinte ich ja. Die Logik dafür ist extrem simpel.

Aber wie gesagt, überhaupt die Renderauflösung während der laufenden Echtzeitberechnung wechseln kann wohl nicht jede Engine. In vielen Spielen muss z.B. vieles neu geladen werden, wenn man irgendwas an den Grafiksettings verstellt.
Schonmal in Anno was an den Grafikeinstellungen geändert, während das Spiel läuft? Schonmal in einem Source Engine Spiel die Auflösung gewechselt? Da hängt das Spiel erstmal für 5 Sekunden, bevor es weiter geht. Das ganze zu implementieren bzw. überhaupt zu ermöglichen, dass die Engine ohne Wartezeit die Auflösung wechseln kann ist sicherlich mit nem gewissen Aufwand verbunden.

Wenn die Engine das kann, ist das Script bzw. die Logik für das dynamische reduzieren der Auflösung in 5 Minuten geschrieben....

 

[ichmich2000]

gemessene Render Zeit größer oberer Schwellwert: Nächstes Frame Auflösung reduzieren (Horizontaler Pixelcount - k)
gemessene Render Zeit kleiner unterer Schwellwert: Nächstes Frame Auflösung erhöhen (Horizontaler Pixelcount + k)

Das kann sicher so schon einigermaßen funktionieren, aber wenn die Last schneller steigt als in deinem Beispiel "k", dann wirst du doch wieder Ruckeln haben.
Wäre interessant, wenn sich die Spielehersteller dabei ein wenig Hilfe aus der Regelungstechnik holen würden.

In der Sache steckt meiner Meinung großes Potenzial für ein rundes Spielerlebnis, wenn man die Auflösung denn wirklich gut abstimmt. Wer erinnert sich z.B. noch an Messiah? Da hat man schon mit so etwas experimentiert, allerdings wurde iirc die Polygonzahl der Charaktere während des Spiels geändert, was dann doch etwas seltsam aussehen konnte.

Neben der Auflösung könnte man auch einige Grafikeinstellungen einbeziehen, deren Änderung kurzfristig möglich und vor allem unauffällig ist. Z.B. Sichtweite, Schattenauflösung usw., Texturen eher nicht, die müssten ja erstmal in den Grafikspeicher nachgeladen werden, was langsam ist.

Wenn man sich vorstellt, dass ein Spiel eigentlich auf 50 fps fallen würde, dafür aber die Sichtweite um vielleicht 5% reduziert, die Schatten eine Stufe weniger genau berechnet und die vertikale Auflösung von 1080p auf 1000p heruntersetzt, dann wird das vielleicht reichen, um saubere 60fps zu halten, aber optisch kaum zu bemerken sein.

 

[Breitseite]

So schlecht fand ich das nie wobei man die spiele ja wieder entkoppeln und verkaufen konnte was leider nicht gut genug kommuniziert wurde. Ich gebe ja zu ausgereift war es nicht sprich onlinezwang aber die idee war generell gut
Aber zb einen win 10 code könnte ms ja problemlos beilegen evtl auch nur in die collectors edition (die eh vorbestellt wird)

Zum thema in quantum break auf der one war die dynamic resolution sehr gut umgesetzt, am pc macht es bei langsameren rechnern auch sinn gerade beim mp und stabile 60fps zu haben und solange es optional ist warum nicht?

 

[Blubmann]

Was wäre demnach dein Lösungsvorschlag? Eine konstant laufende Auflösung und Framerate ist technisch nicht möglich das sich der Berechnungsaufwand je nach Situation immer mal unterscheiden kann... einfach mal dauerhaft die Qualität so weit zu reduzieren das man immer genug Luft hat kann ja auch nicht die Lösung sein, oder?

Mehr LODs und weniger Partikel spawnen. Aber um ehrlich zu sein, vernünftige Konsolen und Publisher, die die Studios nicht auspressen wie Zitronen, wären schon was feines.
Dann ist die Explosion halt nicht super realistisch (was recht egal ist, weil so viel los ist). Was man aber durchaus bemerkt, ist wenn an der gesamten Auflösung (oder der Bildwiederholrate) rumgeschraubt wird.
Gerade bei Konsolen ist es möglich CPU und GPU gleich/konstant auszulasten aufgrund der gleichen Konfiguration. Das Problem hier ist nur die HW und das Zeitmanagement/die Auflagen, die die Studios bekommen.
So wie es jetzt ist, herrscht einfach keine Transparenz gegenüber dem Kunden. Es gibt Scheinzertifikate, die schon jetzt ausgenutzt werden um Leute zu verarschen (du sagst es ja gerade mit der Bildwiederholungsrate). Das wird durch solche "Fortschritte" schlechter und nicht besser.
Der Trend wird dann sein, dass ich in 1-2 Monaten ein "4K 60Hz"-Spiel für eine Konsole hole, und die 4K sind hochskaliert von allem zwischen 640x480 bis 720p, während die Bildrate zwischen 10-30FPS schwankt. Solche Pseudooptimierungen werden auch nicht dafür genutzt um ein flüssigeres Spielerlebnis zu ermöglichen. Da wird einfach das Maximalbudget inflatiert. "Hey, lass weniger optimieren. Der Publisher hat uns so schon am Arsch, da müssen wir einfach die Engine die Auflösung reduzieren lassen. Ich hasse meinen Job, aber irgendwie muss ich meine Brötchen verdienen, mich nicht massig krank-arbeiten und meine Familie ernähren. Oh ja, und Rente muss ich mir ja selber ansparen und hoffen, dass die Inflation die nicht killt."
"Dynamische Reduktion der Auflösung" - Wieder ein Aspekt der Kundenverarsche aus der ausbeuterischen Beziehung des Publishers gegenüber seiner unterworfenen Studios und der Kunden.

 

[s3bish]

1080 bei 30fps, Wow und das ist anscheinend Standard
On the road....

Als Optimalziel wohlbemerkt. Gut, dass die Anforderung an meine nächste Grafikkarte sein sollte, witcher 3 in 1080p mit minimal 120fps konstant darzustellen. Also passend zum 120Hz Monitor.

Keine Ahnung, wann wir wieder zu 60 geschweigedenn 30fps zurückgefallen sind?

Naja, vll schraube ich doch etwas runter und nehme die 1070. Aber bei 30 fps würde ich mit Zocken aufhören

 

[MrZweistein]

Genau das meinte ich ja. Die Logik dafür ist extrem simpel.

Aber wie gesagt, überhaupt die Renderauflösung während der laufenden Echtzeitberechnung wechseln kann wohl nicht jede Engine. In vielen Spielen muss z.B. vieles neu geladen werden, wenn man irgendwas an den Grafiksettings verstellt.
Schonmal in Anno was an den Grafikeinstellungen geändert, während das Spiel läuft? Schonmal in einem Source Engine Spiel die Auflösung gewechselt? Da hängt das Spiel erstmal für 5 Sekunden, bevor es weiter geht. Das ganze zu implementieren bzw. überhaupt zu ermöglichen, dass die Engine ohne Wartezeit die Auflösung wechseln kann ist sicherlich mit nem gewissen Aufwand verbunden.

Wenn die Engine das kann, ist das Script bzw. die Logik für das dynamische reduzieren der Auflösung in 5 Minuten geschrieben....

Ja das stimmt, die Engine muss es natürlich erlauben die Werte für x und y der Auflösung anzupassen.

 

[Blubmann]

Genau das meinte ich ja. Die Logik dafür ist extrem simpel.

Aber wie gesagt, überhaupt die Renderauflösung während der laufenden Echtzeitberechnung wechseln kann wohl nicht jede Engine. In vielen Spielen muss z.B. vieles neu geladen werden, wenn man irgendwas an den Grafiksettings verstellt.
Schonmal in Anno was an den Grafikeinstellungen geändert, während das Spiel läuft? Schonmal in einem Source Engine Spiel die Auflösung gewechselt? Da hängt das Spiel erstmal für 5 Sekunden, bevor es weiter geht. Das ganze zu implementieren bzw. überhaupt zu ermöglichen, dass die Engine ohne Wartezeit die Auflösung wechseln kann ist sicherlich mit nem gewissen Aufwand verbunden.

Wenn die Engine das kann, ist das Script bzw. die Logik für das dynamische reduzieren der Auflösung in 5 Minuten geschrieben....

Da sollte an sich nicht so kompliziert sein. Source braucht z.B. bei Auflösungswechseln so lange, weil VGUI neu initialisiert werden muss. Bei einigen weiteren Einstellungen muss das Materialsystem neu initialisiert werden.
An sich ist so ein Feature recht trivial, allerdings ist man halt nicht darauf ausgerichtet sowas on-the-fly zu tun.

 

[Jesterfox]

Das wichtigste ist es eigentlich die Renderauflösung von der dargestellten Auflösung zu entkoppeln und eine Skalierung zu integrieren (wobei das bei einem deferred Renderer evtl. schon vollautomatisch klappt, ansonsten geht's denk ich indem an diesen "Umweg" einfach mit einbaut)

 

[Blubmann]

Das Rendertarget zu wechseln ist mit 2 Zeilen gemacht, und Source macht das glaube ich schon so (aufgrund irgendwelcher Effekte). Zumindest gibt es für das Rendern von Cubemaps schon entsprechende Methoden, die denen das vereinfachen.

 

[thehintsch]

Das kann sicher so schon einigermaßen funktionieren, aber wenn die Last schneller steigt als in deinem Beispiel "k", dann wirst du doch wieder Ruckeln haben.
Wäre interessant, wenn sich die Spielehersteller dabei ein wenig Hilfe aus der Regelungstechnik holen würden. [...]

Ich nehme an, so wie Laggy.NET es beschrieben haben, dass das schon gemacht wird. Wenn konstant 60 FPS das Ziel sind, wäre es ja sinnvoll eine gewisse Hysterese für den Anstieg der Auflösung einzubauen. Nach dem Motto: "Lieber eine Weile in geringerer Auflösung rechnen und 60FPS halten, als zu schnell wieder hochzufahren und niedrige FPS riskieren".

Zu meinem vorherigen Post: Ja, wenn man sich das mit dem Frametimes überlegt, macht es wirklich nur einen "verlorenen" Frame aus, wenn ein Bild in zu hoher Auflösung berechnet wird, sofern das nächste Bild schon mit angepasster Auflösung berechnet wird. Das merkt man wahrscheinlich wirklich nicht. Da hätte ich ich eher schon drauf kommen können : o)