G
gaussmath
Guest
Wenn die Leute sagen, dass die DLSS Implementierung von Battlefield V und Metro Exodus kompletter Shit ist, ok, aber Death Stranding??
Soweit ich weiß, ist DLSS nicht nur Post Processing. Es muss wegen der temporalen Effekte an mehrere Stellen des Renderprozesses reinoperiert werden. Ich denke auch, dass es ansonsten schon viel mehr verbreitet wäre. DLSS 2.0 ist ja ziemlich universell und muss nicht auf ein konkretes Spiel angelernt werden.
AO kann unabhängig einer GI laufen. Lief im Übrigen in allen Szenarien bis jetzt so. Das geht, weil Du nur die Szenenteile abdecken musst, in welchen sich Polygone/Dreiecke an einer Kante annähern.
Die Abtastung kann dann gezielt punktuell in diesen Bereichen erfolgen. So funktionieren ja auch die ganzen Techniken, nur dass sie mal mehr (VXAO) oder weniger (meist performanceschonende SSAO- Varianten) Strahlen- bzw. Schrittweite erhöhen.
Und wie gesagt- Mit dem AO könntest Du ohne große Zusatzberechnung eben auch immer die Aufhellungen, also das indirect lighting mit abgreifen. Dies gemittelt mit den Farbwerten der Umgebung und schon kriegst Du light-/Color Bleeding noch mit dazu.
Die Grundberechnung, also der Raycast bleibt der gleiche. Du wertest nur im Shader das Ergebnis mehrfach aus, was eben aber kaum Zusatzperformance kostet.
ENB, Reshade und MartyMCFly machens im Screenspace vor.
Fallout 4 - ENB 0.307 - Ambient Occlusion & Indirect Lighting | Overview, Config & Performance - YouTube
In Tomb Raider ist man einen Weg gegangen, den ich ehrlich gesagt nocht so ganz nachvollziehen kann. Da hat man wirklich ein full- space Schatten Raytracing inkl. AO (das fällt auch kostenlos bei einer reinen RT Schattengenerierung ab). Den Rest der Information hat man (fast) links liegen lassen. So hätte man ohne weiteres nicht nur die billige translucency darstellen können, sondern diese auch ohne weiteren großen Aufwand color- based machen können.
Sprich Sonne scheint auf das grüne Blatt. Der Schatten unten erhält einen grünlichen Wert.
Bei der Implementation von SOTTR habe ich aber generell das Gefühl, dass der Entwickler nicht genau gewusst hat, was er überhaupt genau will und dass man eher froh war, das ganze Thema irgendwie halbwegs funktionierend für sich abschließen zu können. Das sieht man auch schön, wenn man sich die Buffer ansieht, in die die Schatten auch teils nicht sauber reingefaked wurden (trotz voller RT- Abtastung).
Wenn Du da die virtuelle Kamera verschiebst, fällt die Konsistenz der Schatten in sich zusammen.
Indirekte Beleuchtung ist eine Teilmenge einer RT- Gestützten Beleuchtungstechnik, die letztendlich durch die Wertebestimmung einer Ambient Occlusion additiv und nicht substraktiv wirkt.
Pathtracing ist die Meisterklasse, weil da alle primär dargestellen Pixel auf Rayabtastung beruhen. Auch hier gilt wieder- Hohe Anfangskosten, gerade was die Auflösung anbelangt, dafür mit steigender Komplexität der Szene höherer Grenzertrag an Performance.
) Reflektion, zwei davon mit Einfluss auf die farbliche Zusammensetzung, wären ein Paradebeispiel und im direkten Strahlengang ein Klax für Raytraycer. Aber aus den Tiefe 5 (wenn man den Durchgang durch die Fensterscheibe als Strahlwechsel berechnet sogar 6) möglichen Millionen denkbarer Wege, über die Licht mein Auge erreichen könnte, alle auf Relevanz zu prüfen ist praktisch unmöglich.Ich hatte die Idee vor etwas längerer Zeit auch mal erwähnt hier im Forum . Mir wurde begegnet, dass das wegen der Latenzen unmöglich sei. Dabei würde gar nicht mal viel hin- und herkommuniziert werden. Der Shader stoppt, wenn er die Daten eines Hits braucht. Es geht ein Ray hin und es kommt ein Hit-Result zurück. Das kann doch eigentlich nicht so dramatisch sein. Das ganze setzt natürlich voraus, dass so ein Co-Prozessor einen eigenen Zugriff zum VRAM hat und zwar mit voller Bandbreite. Das dürfte dann das Problem sein. Ein zweites Speicherinterface nur für den Co-Prozessor? Hmmm...

Ja, dass kann ich machen aber es ändert doch nichts in der Sache, dass ich dem was du schreibst doch technisch gar nicht widerspreche!Bitte, DaStash, schau Dir das Video an. So viel Zeit wirst Du doch haben. Wenn Du schon diskutieren willst, dann solltest Du wissen, worüber Du diskutierst.

Funktioniert DLSS eigentlich auch mit Ultrawide Monitoren z.B. mit einer Auflösung von 3440x1440?
Ja und die AI lässt auch Details weg, die ich in nativer Auflösung sehe. Das vergessen wir schnell.Die AI rekonstruiert Details, die sogar ein natives 4k Bild nicht abbilden kann.
Egal, wird das Bild künstlich verfälscht, in dem Informationen entfernt werden(Komprimierung) oder dazugerechnet werden, wie durch DLSS beispielsweise, ist es verlustbehaftet, da nicht mehr Original.

Ich bin schon auf den Matsch im Matsch gespannt.

Ja und die AI lässt auch Details weg, die ich in nativer Auflösung sehe. Das vergessen wir schnell.
Verstehe, wenn das Bild also die originalen Fehlerchen der Rastertechnik besitzt und dadurch flimmert wie die Hölle, sieht dennoch besser als mit DLSS aus, da DLSS verlustbehaftet und nicht Original ist.
An dir ist auch ein Hildmann verloren gegangen.
Das sind Qualitätsdiskussionen hier.

Gehts noch?Verstehe, wenn das Bild also die originalen Fehlerchen der Rastertechnik besitzt und dadurch flimmert wie die Hölle, sieht dennoch besser als mit DLSS aus, da DLSS verlustbehaftet und nicht Original ist.
An dir ist auch ein Hildmann verloren gegangen.
Das sind Qualitätsdiskussionen hier.


Funktioniert DLSS eigentlich auch mit Ultrawide Monitoren z.B. mit einer Auflösung von 3440x1440?
DLSS (2.0) ist grundsätzlich schon sehr beeindruckend, genau wie RTX, aber beeindruckend reicht halt nicht wenn es Jahre nach der Vorstellung immer noch fast nirgends eingesetzt wird.
Das muss du mir mal genauer erklären, warum das so sein muss.
Würde behaupten das hängt eher davon ab, wie man das RT berechnet [...]

In Death Stranding kommt DLSS meiner Meinung nach [...]

Mit einer Inter- Die Kommunikation á la infinity fabric sehe ich da kein Problem.Ich hatte die Idee vor etwas längerer Zeit auch mal erwähnt hier im Forum . Mir wurde begegnet, dass das wegen der Latenzen unmöglich sei.
Geau das.Dabei würde gar nicht mal viel hin- und herkommuniziert werden.
Ich würde wie oben erwähnt eine zentrale I/O und Steuerungseinheit integrieren, die das zerlegen in Tiles durchführt und auch zeitgleich die Speicherverwaltung kontrolliert.Der Shader stoppt, wenn er die Daten eines Hits braucht. Es geht ein Ray hin und es kommt ein Hit-Result zurück. Das kann doch eigentlich nicht so dramatisch sein. Das ganze setzt natürlich voraus, dass so ein Co-Prozessor einen eigenen Zugriff zum VRAM hat und zwar mit voller Bandbreite. Das dürfte dann das Problem sein. Ein zweites Speicherinterface nur für den Co-Prozessor? Hmmm...
Natürlich ist es verlustbehaftet, wenn es nicht nativ ist. Zudem kann es noch durch die KI verfälscht werden.
Nehmen wir an, du triffst die Aussage:
"Im Ozean ist Wasser"
.... und dein Gegenüber würde rufen:
"Wo sind die Quellen? Link!? Wer hat das bestätigt!?"
Wuerdest du dir ehrlich die Zeit nehmen, fuer sowas noch Quellen zu verlinken?
Ihr überseht das Offensichtliche doch ganz bewusst und gewollt.
Weil Du auch bei AO immer mehr Rays zur Abtastung verschiessen musst, als sie dann tatsächlich auch zum gewünschten Effekt beitragen. AO ist ja ein Flächeneffekt, der in dem Falle rekusrsiv auch zusätzlich über die Auswertunge aus dem Z- Buffer angestossen wird.Aber wie willst du die AO mit Rays ermitteln, wenn du gar keine gestreuten Sekundarrays verschießt, weil du RT nur für Schatten nutzt?
Das ist richtig, nur wie gesagt setze ich nicht voraus, dass ein AO Algorithmus nur aus Primärstrahlen besteht.Ein Primärstrahl hat keine Ahnung, wo die nächste benachbarte Polygonkante liegt und ob es danach mit einem Innenwinkel oder einem weiten Raum weitergeht.
Exakt- Das Beispiel mittels Screenspace AO sollte nur dazu dienen, dass man sich eben die geringen Mehrkosten durch die Zusatzauswertungen der von mir genannten Effekte schön ansehen kann, da die APIs meist einen Debug Modus besitzen und man sich auch die dekompilierten Shader zu gemüte führen kann.Natürlich kannst du sowas per Shader an der vom Primärstrahl getroffenen Stelle zu ermitteln versuchen, aber das ist keine Berechnung von AO mittels RT und es ist auch nicht "kostenlos". Nur sehr billig, auch im Ergebnis, genau wie wenn du genau den gleichen Algorithmus in einem Rasterizer einsetzt, weil eben keine RT-basierte, physikalisch richtige Berechnung dahinter steckt.
Gugg mal da:Wenn ich mich richtig erinnere, arbeitet TR mit einer ganz primitiven Verdeckungstechnik: "Besteht Sichtverbindung des Ray-Endpunktes zur Lichtquelle, oder ist Geometrie dazwischen?" Maximal wird noch auf komplette Transparenz geprüft, aber unterschiedliche, gar farbabhängige Transparenzeigenschaften sind nicht mit drin
Bei SOTTR wäre in der Tat mehr drin gewesen. Dennoch interessant, wie sich teils die Offscreen- Verschattung auch von dynamischen Objekten auf das Bild auswirkt. Das hat schon was. Nur muss man halt sehr genau drauf achten, wo man nach den Unterschieden sucht...und das Ganze funktioniert auch nur mit wenigen Lichtquellen (wie sie für das Spiel allerdings auch typisch sind). Für mich, genauso wie die flächigen Spiegelungen in Battlefield V, ein klassisches Beispiel für beinahe sinnlosen RT-Einsatz.
Wie bereits weiter oben angemerkt ist bei RTRT die Optik nur ein Faktor von vielen, die eine mögliche zukünftige Spieleentwicklung beeinflussen wird. Dies auf einen "simplen Effekt" zu reduzieren, wird den Auswirkungen dieser Rendertechnik nicht im Ansatz gerecht.weswegen man solche Stunts gar nicht erst versucht hat. Stattdessen gibt es einen simplen Effekt !!!in RT!!! statt in einer anderen Technik, was 95 Prozent der Nutzer visuell nicht einmal dann identifizieren können, wenn man ihnen sagt, worum es geht.
Oder Du gehst auf Schwellwertbasis bzw. Raylänge.Aber indirekte Beleuchtung, AO und Farbübertragung habe ich dann aber nicht. Möchte ich das ebenfalls korrekt via RT erhalten, muss ich die gesamte Lichtausbreitung berechnen und nicht nur eine große Zahl Sekundärstrahlen zu jeder potenziell reflektierenden oder streuenden Fläche im Spiel schießen, sondern bis zu einer gewissen Oberflächenhelligkeit auch noch quartäre, quintäre, etc. Strahlen hinten dran hängen.
Ist ja das schöne am rekursiven Raytracer bzw. Pathtracer, dass dieser, sollte jede weitere Streuung/Strahlenverfolgung keinen großen Beitrag mehr zum Farbwert beitragen, dieser einfach als fertig berechnet gilt und nicht mehr weiter gesamplet wird.Aber aus den Tiefe 5 (wenn man den Durchgang durch die Fensterscheibe als Strahlwechsel berechnet sogar 6) möglichen Millionen denkbarer Wege, über die Licht mein Auge erreichen könnte, alle auf Relevanz zu prüfen ist praktisch unmöglich.
Das Problem ist, es geht einfacher -> wie Epic mit Lumen (UE5) zeigt, indem man CAD Scans nutzt, wobei man sich um die Skalierung dann nicht mehr kümmern muss, also ein wesentlicher Optimierungsgrad weg fällt. Bei ausreichend großer Bibliothek ist auch das Programmieren in vielen Richtungen kein Problem. Faktisch kostet das 3D Texturmodell fast nichts und ist auf Konsolen lauffähig. Optisch ist es wegen Photogammetrie in 8K wirklich ansprechend. Tatsächlich wird eine LoD Skalierung überflüssig, wobei Verschattungen mit diffundiertem Licht in Echtzeit, auch völlig ohne Raytracing berechnet werden. Sieht also kaum schlechter aus und läuft sogar auf Tablets.
Sony plant einen Wechsel in 2021, da setzt niemand auf Raytracing (Methoden wie Nvidia). Wenn kann das nur Microsoft selbst sein, wobei die X kostet und Leistung verpulvert.
Absolut nicht. Die Sony Studio's entwickeln heute auf Basis der UE v4.25, die sich inklusive der beschriebenen Feature nach v5.0 portieren lässt. Ich schreibe es nochmal, sieht düster aus. Genau deshalb braucht die PS5 auch viel weniger DCU (RDNA2), was natürlich auf den Verkaufspreis niederschlägt.Nur dass sich selbst Entwickler von Sony Studios gemeldet haben und sich fragen wer sowas in einem ganzen Game in vollem Umfang einbauen soll? Allein auch von der Datenmenge.