Forward+ vs Deffered Rendering

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Antworten
Andy90
Beiträge: 76
Registriert: 08.10.2023, 13:02

Forward+ vs Deffered Rendering

Beitrag von Andy90 »

Hallo, ich würde gerne mal eine kleine Diskussion zu dem Thema Forward+ und Deffered Rendering starten. Ich habe mich die letzten tage etwas schlau gemacht über deferred rendering und die Meinungen scheinen wohl stark auseinander zu gehen. Aktuell nutze ich einen Forward+ renderer. Das bedeutet das ich vor dem eigentlichen rendern noch ein Light Culling durchführe um nur die lichter zu erhalten die sich in dem Bereich der Kamera befinden. Ich kann da tatsächlich schon recht gute Resultate erzielen. Ich habe 500x500 lichter der scene hinzugefügt um komme auf ca. 615FPS und einer Darstellung Latenz von 1.2ms. Dabei sind immer ca. 9-12 lichter aktiv, welche ich dann mit einem SSBO an den shader binde.

In dem sinne noch einen schönen ersten Mai :)
Benutzeravatar
Jonathan
Establishment
Beiträge: 2667
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Forward+ vs Deffered Rendering

Beitrag von Jonathan »

Ich hab deferred rendering noch nie selbst gemacht. Tausende Lichtquellen sind vielleicht die Standardmotivation, aber ist das heutzutage immer noch der beste Grund? In wie vielen Szenen hat / braucht man die wirklich?

Ich glaube ein anderer Grund könnte sein, das es schwer ist Overdraw gänzlich zu vermeiden. Gibt ja schon so Ideen wie "pre Z pass" und Fragmente zu ignorieren, wenn man sie dann eh nicht sehen würde. Dann ist vielleicht die nächste Überlegung, das es billiger ist die Normale und einen Texturindex pro Fragment zu speichern, anstatt das gesamte Beleuchtungsmodell zu evaluieren, das geschieht dann im nächsten Schritt nur für die sichtbaren Fragmente.

Was ich damit sagen will: Das ist dann effizient, selbst wenn man nur eine einzige Lichtquelle, aber massiven Overdraw hat. Den Fall würde dein kleiner Benchmark aber überhaupt nicht abdecken und ich denke, er ist viel relevanter. In einer Außenszene bei Tag hat man vlt. nicht viel mehr als eine dominante Lichtquelle (die Sonne) und da braucht man erst gar nicht mit Lightculling anfangen. Aber man hat vielleicht 20 Bäume in einer Reihe, also viel Overdraw.

Der große Vorteil beim Forwardrendering ist natürlich, dass man Multisampling relativ günstig bekommt. Das geht bei Deferred-Rendering dann nicht mehr (weil man nur Farben und keine Normalen oder Materialindexe interpolieren kann) und dann hast du entweder Treppen, oder musst irgendetwas anderes einbauen.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Matthias Gubisch
Establishment
Beiträge: 507
Registriert: 01.03.2009, 19:09

Re: Forward+ vs Deffered Rendering

Beitrag von Matthias Gubisch »

Dann fang ich mal an:

Deffered Rendering ist daraus entstanden das man festgestellt hat dass bei vielen Lichter der Beleuchtungspart im Shader sehr teuer wurde.
Wenn man viel Overdraw in der Szene hat macht man die Lichtberechnung potenziell viele male umsonst.
Um zu erreichen dass diese teure Berechnung nur 1x ausgeführt wird sind findige Menschen auf die Idee gekommen man könnte ja alles was für beleuchtung nötig ist berechnen und dann die Beleuchtung in einem extra Shader machen, aber im klassischen Deffered Ansatz werden immer noch alle Lichter für jeden Pixel berücksichtigt
Klingt erstmal logisch hat aber ein paar Nachteile:
- Kein MSAA mehr möglich (also nicht sinnvoll) -> alternative Lösungen für Anti Aliasing nötig -> TAA als Quasi Industriestandard, gibt aber noch andere Lösungen
- Sehr Speicherbandbreitenintensiv -> war glaube ich in den Anfängen weniger das Problem mittlerweile ist der Speicherdurchsatz mehr und mehr das Bottleneck
- Transparenz ist schwierig da natürlich kein Alphablending vom Output Merger gemacht werden kann.

Um diese Probleme zu umgehen haben sich wiederum andere schlaue Leute Forward+ (eigentlich nur ein fancy Marketingbegriff) ausgedacht:
Das Prinzip:
1 -> Depth Prepass, nötig für Lightculling (eigentlich mehr einsortieren in Tiles anstatt culling) und um Overdraw zu vermeiden
2 -> Lights in Tiles einsortieren
3 -> Normales Forward Rendering wobei nur die Lichter des aktuellen Tiles berücksichtig werden.

Jetzt ist es aber so, dass weder der DepthPrepass noch das "Lightculling" Alleinstellungsmerkmale von Forward+ sind. Das lässt sich beides mit relativ wenig Aufwand auch in einem Deffered Renderer anwenden und damit ähnliche Performance erziehlen.

Es gibt sowohl für das eine als auch für das andere gute Gründe und es kommt ein wenig darauf an wie der Rest der Pipeline aussieht.

State of the Art ist ein Visibility Renderer (prominentestes Beispiel hier dürfte Naninte aus UE5 sein)
Hier geht man nochmal einen Schritt weiter und schreibt im ersten Pass nur einen 64 bit Wert pro Pixel (32Bit Depth und 32Bit Triangle ID)
Das Shading wird dann in einem Compute Shader gemacht der erstmal das Dreieck rekonstruiert und sich da Barycentrics und Derivatives ausrechnet.

Danach kann man dann wieder je nach belieben mit Forward ähnlich (Material und Lighting in einem Shader) oder Deffered (GBuffer aus den VisibilityDaten erzeugen und Lighting in extra Shader) weitermachen. Auch hier gilt LightCulling kann man problemlos anwenden.
Dieser Ansatz hat viele Vorteile aber auch ein paar ungelöste Probleme.
Overdraw und HelperLanes bei kleinen Dreiecken sind "kein" Problem mehr da der Pixelshader der ersten Stufe maximal einfach ist und die eigentliche Arbeit nur 1x pro Pixel gemacht wird. Auch wird wesentlich weniger Speicherbandbreite benötigt.

Soweit kurz zu den Techniken.

Ein pauschales besser oder schlechter gibt es nicht da es von zuvielen Faktoren abhängt, aber hier mal ein paar grobe Anhaltspunke:
- Deine Target GPU ist ein sog. Tiled Renderer (meist Mobile, fast nie auf dem Desktop) -> Forward+
- Viele Transparende Objekte in den Szenen -> Forward+
- Viele Screenspace Postprocessing Effekte oder einzelen Raytracing Effekte -> Deffered weil man dann in den GBuffer Informationen reincodieren kann die dann dort nützlich sind.

Aktuell sind meines Wissen alle großen (Player, Unity, UE5, Dice,...) mit Ausnahme der IdTec, Deffered Renderer oder Visibility Renderer.
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
NytroX
Establishment
Beiträge: 406
Registriert: 03.10.2003, 12:47

Re: Forward+ vs Deffered Rendering

Beitrag von NytroX »

Wollte noch ein paar Punkte ergänzen:
Deferred Shading/Lighting/Rendering ist zu einer Zeit entstanden, zu der GPUs sehr schnell rendern konnten. Die wurden immer besser, und man ist quasi das Problem der Fillrate (also die Grafikkarte schafft einfach die Anzahl Pixel nicht mehr) fast los geworden.
Jeden Pixel 5 oder 8 Mal rendern war auf den größeren Karten kein Problem mehr.
Dann konnte man natürlich die Extra-Power für andere Sachen verwenden (z.B. SSAO, Edge Detection für Schatten, uvm) was dann eine bessere Bildqualität am Ende ergibt.

Ein weiterer Vorteil ist halt, dass man zuerst "Einzelteile" rendert, also nur Licht, nur Geometrie, nur Schatten, usw. und das am Ende dann zusammenführt. Das ist natürlich auch nett, weil man Bugs leichter analysiert bekommt usw. ("oh, da sieht der Depth-Buffer aber komisch aus, kein Wunder dass das Endresultat da nicht stimmt")
Meiner Meinung nach ist das leichter zu verstehen und man kann es leichter ändern / Effekte rekombinieren.
Soweit also aus meiner Sicht erstmal ein klarer Vorteil, der aber auch nicht mehr so gewaltig ist, wenn man eine "fertige" Engine nutzt.

Aber:
Dann kamen irgendwelche Leute mit Smartphones oder Laptops, deren "Grafikkarte" halt eine Performance von vor 15 Jahren hat.
Und dann kommen auch noch irgendwelche detailverliebten Deppen (also ich :-) und kaufen 4k oder 8k Monitore.
Nun rendern wir also jeden Pixel mit dem Deferred Renderer eh schon 5 bis 8 Mal, und jetzt haben wir auch noch das 4 bis 8-fache an Pixeln.
Und tadaa... bei 8 * 8 = 64 mal der Menge kommt plötzlich das Problem mit der Fillrate zurück. Und schlimmer noch: die Bandbreite zur Grafikkarte macht plötzlich auch schlapp...

Also muss man halt wieder neu überlegen, Forward+ ist so ein Ergebnis.
Vielleicht kommt man aber auch mit einer Art Deferred Rendering weiter, wenn man es schafft, mehr pro Pixel in einem Pass zu machen.

Dabei kommt es halt auch stark auf das Spiel an, oft ist die Grafik halt auch nicht so wichtig (viele spielen mit DLSS oder FSR).
Nur die großen Spielemacher (oder Engine-Bauer) versuchen noch das maximum rauszuholen, wenn überhaupt.

Daher IMHO: Es kommt auf das Spiel und die Zielplattform an, und an die Mindestanforderungen, die man seinen Kunden zumuten möchte.
Benutzeravatar
Schrompf
Moderator
Beiträge: 5171
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Forward+ vs Deffered Rendering

Beitrag von Schrompf »

Ich hab zu dem Thema keine Meinung, aber ich sehe ein paar spannende Ideen darin, manche Teile der Bildberechnung deferred zu machen.

Beispiel: Schatten! Wenn man den Sonnen-Schatten deferred macht, könnte man nicht nur in halber Auflösung arbeiten. Man könnte auch die Sonnen-Schattenmatrix jittern und so ne virtuell viel höhere ShadowMap-Auflösung erreichen.

Hat natürlich die klassischen Nachteile eines Deferred-Renderers: Transparenz stinkt, Antialiasing ebenso. Aber da kam ja schon die Erkenntnis, dass heutzutage niemand mehr klassisches Super Sampling benutzt, sondern alle nur noch über mehrere Frames temporal jittern. Also ist AntiAliasing eigentlich ein gelöstes Problem. Transparenz ist weiterhin schwierig. Dafür schreibt man irgendwie immer einen Fallback-Forward-Renderer, und mir fällt dann schwer zu argumentieren, warum man dann nicht gleich alles Forward macht.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2667
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Forward+ vs Deffered Rendering

Beitrag von Jonathan »

Schrompf hat geschrieben: 30.04.2025, 23:57 Beispiel: Schatten! Wenn man den Sonnen-Schatten deferred macht, könnte man nicht nur in halber Auflösung arbeiten. Man könnte auch die Sonnen-Schattenmatrix jittern und so ne virtuell viel höhere ShadowMap-Auflösung erreichen.
Warte, wie jetzt? Für die Shadowmap mache ich ja immer nur depth-only, und der Schattentest ist ja Teil vom Shading selber (Ambient braucht man ja immer noch). Was bedeutet es dann, nur den Sonnenschatten deferred zu machen?
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Schrompf
Moderator
Beiträge: 5171
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Forward+ vs Deffered Rendering

Beitrag von Schrompf »

Das ist nur so ein Furzgedanke von mir, im Screen Space die Sonnenschatten auszurendern. Hab ich mal fix versucht, nachzustellen:
screenshot0028.png
Und der Gedanke ist, dass wenn man die Sonnenschatten - oder warum auch nicht Schatten im Allgemeinen - im Screen Space ausrendert, ergeben sich da Optimierungsmöglichkeiten, die man vorher nicht hatte. Z.B. die Schatten mit den vielen Samples nur in halber Auflösung zu rendern. Das müsste bei dem Detailgrad immer noch genau genug sein. Und wenn Du das Bild dann einfach behältst und die Standard Back Projection machst, die auch das ganze Temporale AntiAliasing heutzutage antreibt, dann könntest Du einfach in jedem Frame die ShadowMap-Projection im Subpixel-Bereich zappeln lassen und so stochastisch eine höhere ShadowMap-Auflösung erreichen.

Das Jittern der ShadowMap-Projektion kannst Du auch einfach so machen und das TAA frisst die Unterschiede. Die LowRes-Option hast Du dann aber nicht.

Da man wohl immer noch nicht in nen R8-Buffer rendern kann, sondern immer A8R8G8B8 nehmen musst, hast Du theoretisch noch 3 Kanäle frei für drei weitere Lichtquellen. Gefühlt sind das aber bei weitem zu wenig.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Andy90
Beiträge: 76
Registriert: 08.10.2023, 13:02

Re: Forward+ vs Deffered Rendering

Beitrag von Andy90 »

Vielen Dank nochmal für die super detaillierten Antworten, dass Ganze ist wirklich spannend zu lesen! Auch die Idee mit den Showmaps finde ich großartig. In meinem alten Renderer hatte ich leider mit stark kantigen Schatten zu kämpfen, was vor allem an der zu niedrigen Auflösung lag. Für Post-Processing-Effekte bringt ein Deferred Renderer natürlich den Vorteil mit sich, dass bereits alle notwendigen Informationen vorliegen.

In meinem aktuellen Forward+ Renderer habe ich das Light Culling etwas optimiert: Statt sämtliche Lichter in der Szene zu durchgehen, unterteile ich sie nun in sogenannte „Chunks“ – ähnlich wie es in Minecraft bei der Weltstruktur gemacht wird. Vor dem Culling bestimme ich, in welchem Chunk sich die Kamera befindet, sowie die direkt benachbarten Chunks. Nur die Lichter innerhalb dieser Bereiche werden anschließend berücksichtigt. Klar, 2500 Lichter sind erst mal etwas übertrieben, aber durch dieses Vorgehen lässt sich die Anzahl relevanter Lichter deutlich einschränken und vor allem die CPU-Last spürbar reduzieren.

Falls ihr Interesse habt, könnt ihr euch den Code gerne anschauen:
https://github.com/Andy16823/GFX-Next/b ... Manager.cs

Aktuell ist das Ganze zwar noch für 2D umgesetzt, aber eine Erweiterung auf den 3D-Raum wäre unkompliziert – man müsste lediglich die Chunk-Aufteilung um die Z-Achse ergänzen.
Matthias Gubisch
Establishment
Beiträge: 507
Registriert: 01.03.2009, 19:09

Re: Forward+ vs Deffered Rendering

Beitrag von Matthias Gubisch »

Das mit den Chunks für Lichter halte ich für fragwürdig
Wenn deine Lichter einen kleinen Radius/Reichweite haben mag das funktionieren, im allgemeinen verliert man aber ja nach chunkgrösse schnell relevante Lichter

Ich mache es z.b. so das ich auf der GPU mit einem compute shader durch alle lichter blase und sie in die screen tiles einsortiere
Da sind dann auch ein paar 10k Lichter kein Problem mehr
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Andy90
Beiträge: 76
Registriert: 08.10.2023, 13:02

Re: Forward+ vs Deffered Rendering

Beitrag von Andy90 »

Ok, soweit bin ich noch nicht. Ich habe noch nie einen compute shader erstellt oder genutzt :)
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 604
Registriert: 05.07.2003, 11:17

Re: Forward+ vs Deffered Rendering

Beitrag von Lord Delvin »

Schrompf hat geschrieben: 30.04.2025, 23:57 ... Also ist AntiAliasing eigentlich ein gelöstes Problem. ...
Ja: Kleines 4k Display kaufen und immer ausschalten ;)
Sorry, aber die Pöbelei musste sein. Ich kann ehrlich gesagt nicht nachvollziehen, warum es das noch gibt oder warum viele spiele das per default anschalten, wenn sie glauben mein Rechner hätte genug Power dafür. Ist einfach nicht mehr erforderlich. Wenn das Spiel ein bisschen tiefe hat denkt man sich nicht "oh wie schön wäre es, wenn die Kante da ein kleines bisschen weniger zu sehen ist", während man mit der Nasenspitze einen Fettfleck auf's Display macht ;)
Ehrlich gesagt verstehe ich genauso nicht, warum irgendwelche Sachen dann mit halber Auflösung gerendert werden oder man irgendwelche Screenspace-Effekte nicht mehr ausschalten kann. Gerade Reflection und SSAO sind oft so störend falsch, dass es besser wäre, das Meer wäre eine blaue Platte und der Schatten halt irgendwie falsch, aber konsistent. Schatten im Screenspace zu berechnen ist genauso grauenhaft, weil sie störend rumploppen, wenn man durch die Welt läuft und irgendwas großes nicht mehr im Sichtfeld ist, aber einen Schatten werfen müsste. Das sind so große Fehler, dass sie einen tatsächlich rausreißen, weil man sofort intuitiv merkt, dass irgendwas falsch ist.

EDIT: https://www.youtube.com/watch?v=6DkFV8DkTv8 bei 3:40 unterm flügel; ist also in UE 5 immer noch drin und nicht gelöst und genauso abstrus. Und bei 4:30 dann schönn die Reflexionen. Wenn das Spiel an sich nicht Probleme hätte würde ich vermutlich wie bei Talos 2 irgendwelche komischen Dateien irgendwo anlegen und tunen bis man's anschauen kann ohne einen Vollanfall zu bekommen.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
NytroX
Establishment
Beiträge: 406
Registriert: 03.10.2003, 12:47

Re: Forward+ vs Deffered Rendering

Beitrag von NytroX »

Bei 3:29 sieht man dass der "Schatten" erst aus Punkten besteht und dann detaillierter wird, ohne das sicher der Charakter bewegt.
Da frage ich mich halt immer was das ist. SSAO mit Dithering? Raytracing? Temporal AA? AI?
Habe ich bei fast allen Techniken schon so ähnlich gesehen.

Btw wo ist in dem Video eigentlich der echte Schatten? Das sieht alles komisch aus.

Aber generell ist Self-Shadowing ja auch noch ungelöst, da macht man genau das, was du im letzten Satz ansprichst (rumprobieren), egal welche Technik. Für mich ist es ähnlich bei SSAO - es ist oft schlecht implementiert - aber ohne sieht es halt auch falsch aus.
Keine Ahnung was da am Besten ist, vermutlich macht jeder was ihm gefällt; für mich persönlich sieht das rechte Bild besser aus.
(aber im Hintergrund pfuschen sie auch. ein einfacher Depth-Test würde das beheben)
ssao.png
Aber es macht ja halt auch keiner mehr selbst, nicht mal das tunen. Effekt Einkaufen - draufhauen - fertig - sieht scheiße aus aber passt schon.
Achja: Und temporal AA hat das gleiche Problem wie Screen-Space Zeugs: es ändert sich beim Bewegen. Damit ist aus meiner Sicht also das Problem noch lange nicht gelöst.

Aber am Ende ist es halt so: die Rechenleistung reicht nicht für echte Licht-Berechnungen. Also muss man irgendwo Faken/Cheaten, so gut es eben geht - und jeder empfindet andere Sachen schön oder eben störend.
Alexander Kornrumpf
Moderator
Beiträge: 2158
Registriert: 25.02.2009, 13:37

Re: Forward+ vs Deffered Rendering

Beitrag von Alexander Kornrumpf »

Lord Delvin hat geschrieben: 01.05.2025, 21:46
Schrompf hat geschrieben: 30.04.2025, 23:57 ... Also ist AntiAliasing eigentlich ein gelöstes Problem. ...
Ja: Kleines 4k Display kaufen und immer ausschalten ;)
Sorry, aber die Pöbelei musste sein. Ich kann ehrlich gesagt nicht nachvollziehen, warum es das noch gibt oder warum viele spiele das per default anschalten, wenn sie glauben mein Rechner hätte genug Power dafür. Ist einfach nicht mehr erforderlich. Wenn das Spiel ein bisschen tiefe hat denkt man sich nicht "oh wie schön wäre es, wenn die Kante da ein kleines bisschen weniger zu sehen ist", während man mit der Nasenspitze einen Fettfleck auf's Display macht ;)
Also ich habe neulich Witcher 3 installiert und die nicht geglätteten Kanten waren wirklich nicht zu ertragen. Ich war auch nicht ganz sicher wieso das Spiel die Einstellungen vorgeschlagen hat, die es vorgeschlagen hat.

Ich schätze die Hardware ist ca. 5 Jahre alt, das Spiel eher so 10 (?). Weiß ich nicht was da schief lief, jetzt wo du es sagst war der Staircase Effekt schlimmer als man es bei der Pixelgröße vermuten sollte.
Wenn das Spiel an sich nicht Probleme hätte würde ich vermutlich wie bei Talos 2 irgendwelche komischen Dateien irgendwo anlegen und tunen bis man's anschauen kann ohne einen Vollanfall zu bekommen.
Falls sich das auf Talos Principle bezieht, kann ich vermelden, dass ich komischerweise von The Witness und The Talos Principle 1 furchtbarste Motion Sickness bekomme. Aber das kann ja nicht am Genre liegen. Ich führe es darauf zurück, dass die Spiele extrem hell beleuchtet sind.
Benutzeravatar
Krishty
Establishment
Beiträge: 8352
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Forward+ vs Deffered Rendering

Beitrag von Krishty »

Lord Delvin hat geschrieben: 01.05.2025, 21:46Ich kann ehrlich gesagt nicht nachvollziehen, warum es das [Antialiasing] noch gibt
Ich kriege literally Migräne, wenn die Kanten flimmern. Ist für mich auch ein echtes Problem mit Retro-Spielen. Ab einem bestimmten Blocking ist es zu ertragen (640×400 oder so) aber bei höherer Auflösung ist es wie Millionen Ameisen auf dem Bildschirm. Ich weiß umgekehrt nicht, wie man so spielen kann :D
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 604
Registriert: 05.07.2003, 11:17

Re: Forward+ vs Deffered Rendering

Beitrag von Lord Delvin »

NytroX hat geschrieben: 01.05.2025, 22:24 ... für mich persönlich sieht das rechte Bild besser aus.
Das ist genau mein Punkt und meine Beobachtung. Die Entscheidungen werden basierend auf Screenshots, also unbewegten Bildern getroffen. So gesehen ist das alles nachvollziehbar und in dem Kontext wäre ich auch bei dir. Mein Problem ist aber, dass ich die Technologie in einer Simulation konsumiere, in der ich mich frei bewege. Und es halt irgendwie irritierend ist, wenn ich an was hellem vorbei auf was glänzendes zulaufe und die Reflexion deutlich erkennbar verschwindet. Im Prinzip dasselbe wie früher ordentliches LoD bei Terrain. Da hat auch jeder gejammert, wenn plötzlich 15m vor einem ein Berg aufgetaucht ist.
Krishty hat geschrieben: 01.05.2025, 23:22 Ab einem bestimmten Blocking ist es zu ertragen (640×400 oder so) aber bei höherer Auflösung ist es wie Millionen Ameisen auf dem Bildschirm. Ich weiß umgekehrt nicht, wie man so spielen kann :D
Finde ich schräg, weil ich AA bis full HD verwenden würde und darüber nicht mehr. Den Effekt habe ich ein Stück weit auch, aber mein Hirn kommt gut damit klar. Mit Blur der nicht da sein sollte tatsächlich nicht und auch noch nie. Wenn man den Blur ausschaltet sind die ganzen Screenspaceartefakte zugegebenermaßen aber auch viel deutlicher zu sehen als mit. Ohne sieht man leider auch, dass das zweistufige Detailmapping gerade bei Gelände nicht mehr gemacht wird, was mega kacke aussieht und einen auch aus der Illusion rauswirft, wenn man genau auf die Achse schaut.
Alexander Kornrumpf hat geschrieben: 01.05.2025, 23:19 Ich schätze die Hardware ist ca. 5 Jahre alt, das Spiel eher so 10 (?). Weiß ich nicht was da schief lief, jetzt wo du es sagst war der Staircase Effekt schlimmer als man es bei der Pixelgröße vermuten sollte.
Also mit neuer Engine hab ich in letzter Zeit nur Talos 2 gespielt. Bei Ark 2 hatte ich mir Videos angeschaut und die Teile im Wald haben mich tatsächlich den Kauf neuer Hardware erwägen lassen. Am Meer sah's letztlich aber ähnlich aus wie früher. Ist sicher auch ein Problem von Ark, dass die Spielmechanik einen dazu bringt alle Bodeneffekte auszuschalten, damit man die kleinen Eier findet und man viel und schnell über Gewässer fliegt.

Ich denke ein hässlicher Punkt für die Optimierung ist tatsächlich, dass sich die Wahrnehmung bei Menschen sehr stark unterscheidet. Die nervtötenden Epilepsiewarnungen sind ja irgendwo auch nicht grundlos da.
NytroX hat geschrieben: 01.05.2025, 22:24 Aber es macht ja halt auch keiner mehr selbst, nicht mal das tunen. Effekt Einkaufen - draufhauen - fertig - sieht scheiße aus aber passt schon.
Das ist vermutlich der Punkt. Wahrscheinlich müsste man sich ernsthaft anschauen, was man da zusammenkonfiguriert hat und dann säuberlichst darauf achten, dass Spielmechanik und Leveldesign damit klarkommen. Doom 3 war ja auch einfach ein langer Schlauch als Marsbasis getarnt, weil's halt das war, was damit ging. Vermutlich bekommt man mit modernen Engines atemberaubende Wälder, Wüsten und Hölen hin; Seen halt eher nicht. Und Szenen mit vielen Lichtquellen halt auch eher nicht. Würde mich tatsächlich interessieren, wie gut ein Spiel in der Dunkelheit mit keinem echten Schattenwurf aber vielen kleinen Lichtquellen wirkt. Keine Ahnung ob man's wirklich merken würde. Vermutlich müsste man dann auf Gebäude oder Wände verzichten :)

Vielleicht baut ja jemand in den nächsten Jahren ein funktionierendes Masterlight Konzept auf, dass gut rät, welche Lichtquellen das Bild oder den Eindruck davon am meisten beeinflussen. Damit könnte man dann mit der RT hardware vielleicht eine bessere Lösung bauen. Bis jetzt waren die Berichte der Kollegen aber zu negativ als dass ich Lust hätte in meinen Rechner Hardware für 600W reinzubauen um's dann am Ende immer auszuschalten.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Antworten