Xbox Series X: Raytracing bei Entwicklern offenbar unbeliebt

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.

Okay, da war meine Antwort vielleicht etwas zu vereinfachend, sie folgte allerdings auch auf eine sehr oberflächliche Aussage. DLSS wertet mehr Informationen als nur den abschließend ausgegebenen Frame aus, dass ist richtig, aber es greift nicht in Renderzwischenschritte ein. DLSS interessiert nur die fertig berechente Farbe, geometrisch ausgewertet wird die Szene vermutlich nur zur korrekten Positionsbestimmung. Aber ich wüsste nicht, dass aus temporären Zwischenschritten irgendwelche weiteren Rückschlüsse gezogen werden und es findet definitiv keine Berechnung zusätzlicher Inhalte statt (möglicherweise wird das Abtastmuster insgesamt optimiert – Nvidia schweigt sich ja geflissentlich dazu aus, wieviele reale Pixel überhaupt berechnet werden). Damit es für DLSS weiterhin egal, welches Renderingsprinzip zum Einsatz kommt, es besteht also kein Bezug zu RT. Und nur darauf kam es mir an.


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

Bei AO/IL als Screenspaceeffekt handelt es sich auch um einen billigen Oberflächeneffekt, der Geometriebezogen berechnet wird. Klar geht das unabhängig von allem anderen. 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? 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. 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.

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.

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 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. Man hat dafür viel Aufmerksamkeit erhalten, man hat dank Unterstützung Nvdiais vermutlich sehr wenig eigene Entwicklungszeit investieren müssen und man hat die Leistung sonst unnutzbarer, spezialisierter Hardware-Einheiten angezapft. Aber für eine einstellige Zahl an Lichtquellen mit mäßigen Fps in niedriger Auflösung kann man die gleiche Qualität schon seit Jahren über Stencilschatten erreichen, wenn sie einem denn wirklich so wichtig ist. Das wäre in der Auflösung zwar vermutlich auch sehr kostspielig, aber der Initialaufwand für RT würde sich in TR qualitativ erst auszahlen, wenn man auch noch Lichtstreuung oder zumindest eine nenneswerte Zahl an Reflektionen/Refraktionen korrekt berechnen wollte. Das wäre in einem Rasterizer sehr viel ineffizienter, bei gewölbten Oberflächen ggf. sogar unmöglich. Aber: Es verschlingt auch mit einem Raytraycer derart viel Leistung, dass es auf den aktuellen Karten in real-World-Auflösungen und Frameraten ebenfalls unmöglich ist, 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.

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.

Eine direkte Beleuchtung kann ich in RT selbst im Worst Case mit einem Primärstrahl pro Pixel und dann jeweils einem Sekundärstrahl pro Lichtquelle vollständig und korrekt berechnen. Mit mehreren Sekundärstrahlen zu flächigen Lichtquellen kann in einem weiteren Schritt auch diffuse direkte Beleuchtung realisieren. 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. Bisherige Implementationen verzichten aber meist schon auf eine konsequente, dass heißt in ihrer Reichweite nicht deutlich unter die Ausdehnungen des Levels beschränkte Umsetzung des allerersten Schrittes, weil einfach die nötige Rechenleistung fehlt. Von einer mehrere 10er Potenzen aufwendigeren, komplett natürlichen Beleuchtung in Echtzeit ist aktuelle Hardware Lichtjahre entfernt.
Beispiel direkt aus dem Leben: Neben mir lieg ein Netbook, in dessen schwarz glänzendem Deckel sich die helle Unterseite einer Schreibtischlampe spiegelt, deren primäre Beleuchtungsquelle das von Aluelementen des Schreibtischs zurückgeworfene, durch eine dünne Wolkenschicht gestreute Sonnenlicht ist. Zwei Brechungen gefolgt von zwei diffusen Streuungen und einer sauberen (naja: staubigen :)) 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...

Es gab zwar mal RAM mit Backside-Interface, aber selbst wenn man so etwas extremes wieder auflegt: Es würde nicht als zusätzliche Karte funktionieren. Dann müssten jeder einzelne Hit-Request via PCI-E übertragen werden und auch wenn diese unabhängig voneinander laufen können, kannst du in 5-10 ms einfach nicht so viele Anfragen übertragen. Und am Ende des Tages muss so eine Lösung nicht nur technisch machbar sein, sondern pro Euro schneller als einfach alle Einheiten in eine größere GPU zu packen. Das wird sie aber sicherlich nicht sein und wenn wir von einem kompletten Raytraycer mit mehreren tausend Sekundär-/Tertiär-...-Strahlen pro sichtbarem Pixel reden würde selbst die Transferrate an sich schon ein Problem darstellen. Mal ein Extrembeispiel für Grafikqualität des Jahres 2025-2030: 8K, Streuungsberechnung mit 1° Abtastgenauigkeit bis auf Tertiärebene ohne temporale Schmiereffekte, bei Reflexionen auch weiter: 8.251.200 Primärstrahlen, bis zu 267.338.880.000 Sekundärstrahlen und 8.661.779.712.000.000 Tertiärstrahlen. Noch ein paar Refraktionen dazwischen, für die einzelne Strahlen mehrfach berechnet werden müssen und wir sind bei 10 Billiarden Hits pro Frame, für die im simpelsten Fall (gespeicherte, direkt abfragbare statt on-the-fly mit Shader ermittelte Oberflächeneigenschaften) Reflektions-, Streuungs- und Transparenzgrad für drei 10-Bit-Kanäle abgefragt werden. Ich komme überschlagen auf rund ein Exabyte an Daten. PRO FRAME.

Fazit: Physikalisch korrekte Beleuchtung werden wir entweder noch sehr lange nur vortäuschen oder aus Caches heraus berechnen müssen. ;-)
 
Die AI rekonstruiert Details, die sogar ein natives 4k Bild nicht abbilden kann.
Ja und die AI lässt auch Details weg, die ich in nativer Auflösung sehe. Das vergessen wir schnell.

Letztlich geht es nicht darum, sondern der RT Impact ist einfach zu hoch (BVH viel zu langsam oder zu rechenintensiv auf Middleware), und das AI/KI Rendering verwendet man um Zielauflösungen zu erreichen, die man für sich bewerben kann (wie 8K). Erinnere dich mal, was ich schon vor Monaten dazu geschrieben habe. Wenn Nvidia solche Standards nicht eingeführt hätte und sich daran gehalten was sie mit DLSS/DLAA wollten, nämlich höher als native Auflösung rendern, wäre alles gut gewesen. Da hat man die Pandorra geöffnet und jeder äfft das AI Upscaling jetzt nach. Ich bin schon auf den Matsch im Matsch gespannt.

Düstere Zeiten für DXR, wenn Konsolenentwickler Raytracing in dieser Form nicht wollen und eine Konsole vergleichsweise soviel kostet, wie eine ausgewachsene Raytracing Enthusiast GPU, Spiele teurer werden, weil der Entwicklungsaufwand immer größer wird. Für'n paar Schatten oder Reflektionen...die einem in den meisten Spielen nicht mal auffallen und die ganze Welt jetzt spiegeln muss...
 
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.

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.:lol:

Das sind Qualitätsdiskussionen hier.

Ich bin schon auf den Matsch im Matsch gespannt.

Viele der Beiträge hier erinnern am Matsch, Matsch im Cerebrum.:D
 
Zuletzt bearbeitet von einem Moderator:
Ja und die AI lässt auch Details weg, die ich in nativer Auflösung sehe. Das vergessen wir schnell.

Was ich lustig finde ist das wir sowas ähnliches (Bildqualität für Leistung opfern) vor einigen Jahren noch als Schummelei betrachtet haben. Gab da ja mal einige "Skandale" was die Anisotropische Filterung betrifft. Heute wird uns so ein Kompromiss als Feature verkauft. Solange es dabei bleibt das man die Wahl hat es an- und abzustellen sehe ich da aber kein großes Problem. Außer natürlich für die Leute die Benchmarks erstellen. Für die könnte es irgendwann unübersichtlich und stressig werden wenn AMD nachzieht und man alles doppelt benchen und einigermaßen vergleichen muss.

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.
 
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.:lol:

Das sind Qualitätsdiskussionen hier.

Ja klar, weil das Raytracingbild ja nicht gerastert wird.:schief:

Wie oft soll ich das hier eigentlich noch schreiben, mit welcher Monitortechnologie gibst du ein Bild wieder, Laserhyperraytracing oder Pixel/Rasterengine? Der Großteil wurde hier schon verbl*det...

Raytracing ermöglicht vor allem naturgetreue Visualisierungen aus dem Blickwinkel des Betrachters (Montecarlo Methode), das ändert aber an der grundlegenden Technologie nichts (GPU, Monitore usw.). DLSS war als AA Methode gedacht, Glättung anhand des Pixelrasters mit spartialem Filter.

Jedes AA Verfahren verändert dabei den Groundtrue.
 
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.:lol:

Das sind Qualitätsdiskussionen hier.
Gehts noch? :daumen2:
Ich habe ursprünglich nur darauf verwiesen das DLSS technisch gesehen verlustbehaftet ist und wenn du solchen trivialen technischen Zusammenhänge nicht begreifst, steht Dir der Hildmann näher als du ihn bei anderen siehst. ;)

MfG
 
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.

Natürlich, nur ist es gar nicht so wie man behauptete. Man hat nämlich den Großteil aus OptiX übernommen und das dient zum Bsp. den Studios in dem Fall, Raytracingszenen in Filmen zu erstellen. Da hat die Hardware auch genug Zeit jedes einzelne Bild zu berechnen und in diesem Fall reicht auch BVH völlig.

Man sah es schon in BF-V, dass das eigentlich eine Standbildtechnologie ist, man musste nämlich Anteile der dynamischen Geometrie entfernen, damit der Impact nicht zu groß ausfällt.

Wie begegnet dem Nvidia jetzt? Siehe Ampere, riesig, vermutl. energiehungrig und vermutl. auch teurer als einem lieb ist. Das kannst du auf Konsolen nicht 1 zu 1 übertragen, weil dort der Preis eine wesentliche Rolle spielt. Ein Kühlkonzept in den Abmaßen eines Schukartons nur begrenzt umgesetzt werden kann.

Das AI/KI Inferencing nutzt man jetzt um den Impact höherer Auflösungen abzufedern und spart sich an der Hardware tot, wobei Nvidia jetzt ganz andere Wege geht, big->bigger->biggest.

Treiberoptimierung, die gibt es doch schon immer, das LoD Gespiele auch. Ja früher war sowas verpönt, heute egal.
 
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 [...]

Um Äpfel-mit-Birnen-Vergleiche zu vermeiden, sollte man an der richtigen Stelle natürlich auch die bestmögliche und effizienteste Technik verwenden. Nicht alles muss mittels Raytracing implementiert werden.
Auf der anderen Seite ist dieses Ziel jedoch auch gegen den verbundenen Arbeitsaufwand abzuwägen, denn dutzende unterschiedliche Techniken zu implementieren nur um einige temporale, kleine Effekte effizient zu realisieren geht ebenfalls zulasten der Gesamtimplementation. Hat man bereits Raytracing in der Engine, macht es dann ggf. doch wieder Sinn einige Kleinigkeiten dennoch mittels Raytracing berechnen zu lassen, auch wenn man ggf. mit zusätzlichem Entwicklungsaufwand grob gleichwertig mit klassischen Methoden faken könnte.

Eine entsprechende Abwägung siehst du bspw. in der Neon Noir Demo, in der am Ende von den sieben Patronenhülsen nur vier eine Reflektion im Pfützenwasser haben. Wie die Entwickler später erklärten, lag das schlicht daran, dass die Hülsen im Vergleich zur verwendete Voxelgröße relativ klein waren und diese drei daher durchs Raster fielen.
Mit "regulärem" Raytracing hätte man der Material-ID der Pfütze dagegen eine reflektierende Eigenschaft gegeben und damit hätte jedes gerenderte Pfützen-Pixel einen Strahl in die Szene geschickt und hätte automatisch jede Patronenhülse in der BVH gefunden, da diese direkt auf den originalen Szenendaten beruht. Da hier jedoch einige Hülsen in den Voxeldaten fehlten, konnten diese nicht gerendert werden, weil der Voxeltree eine (volumentechnisch) gröbere Abstraktion des Szenenraums darstellt, was überhaupt erst der Grund ist, warum die Cryengine eine GI ohne derart viel Rechenleistung berechnen kann.

Anmerkung: Crytek's Voxelansatz gibt es experimentell bereits seit Cryengine 3.8. Und auch nVidia hatte schon lange vor Turing mit VXGI einen vergleichbaren Ansatz, der sich bspw. auch in die Unreal-Engine integrieren lies.
Nvidia VXGI in UE4 - Early Testin' - YouTube (2015)

Am technisch einfachsten wäre natürlich allen alten Rasterizer-Kram über Bord zu werfen und die gesamte Szene per Raytracing berechnen zu lassen und dann wäre man da angekommen, was J.Huang im Sept'18 vollmundig erklärt hat a la "einfach einschalten und alles funktioniert". Nur reicht dafür die heutige (und in nächster Zukunft absehbare Consumer-)Leistung bei Weitem nicht aus und daher führt auch weiterhin kein Weg an Hybrid-Renderverfahren vorbei.

Und wie schon zuvor erklärt, auf einer Mittelkasse-GPU hast du aktuell über die ALUs um die 10 TFlops zur Verfügung. Zieht man ohne zu übertreiben (Xbox MS/AMD 3x - 10x für Raytracing) nur die Blender/Octane-Beispiele heran, stehen dir (derzeit) über dedizierte Funktionseinheiten theoretisch bis zu 20 oder gar 30 TFlops zur Verfügung mit denen man natürlichererweise weitaus mehr anfangen kann. Ob einem das das zusätzliche Geld Wert ist, ist natürlich eine vollkommen andere Frage. ;-)

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

Hast du zu dem/den Screenshots auch noch die zugehörigen Fps? Denn interessant wird die Diskussion erst in Verbindung damit. Wohl kaum einer wird DLSS verwenden nur um seiner selbst willen. ;-)

Und genaugenommen "spielt" man in Videospielen auch nicht auf Standbildern und in Bewegtbildern, insbesondere bei hoher Abfolge fallen manche Details gar nicht auf, während andere im Zuge der Bewegung durchs Bild plötzlich eine deutlich höhere Bedeutung erlangen.
 
Zuletzt bearbeitet:
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.
 
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.
Mit einer Inter- Die Kommunikation á la infinity fabric sehe ich da kein Problem.
Wenn du das Bild wie bei Cinebench Tile- based zur Berechnung gibst kannst Du hochparallelisiert und mit vielen kleinen Caches das "Rechenproblem" in beliebig kleine Teile aufteilen.

Alles eine Frage der Organisation.

Dabei würde gar nicht mal viel hin- und herkommuniziert werden.
Geau das.

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...
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.
 
Natürlich ist es verlustbehaftet, wenn es nicht nativ ist. Zudem kann es noch durch die KI verfälscht werden.

Dann hast du noch nie mit DLSS gespielt. Guck dir den Test hier auf PCGH zu Wolfenstein an. Mit DLSS sind vor allem in der Ferne noch mehr und deutlicher die Details zu sehen, als nativ.

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.


Was für ein gequirrlter Bullshit. Mit anderen Worten was du plauderst ist nichts als heiße Luft. Bestätigst du damit selber.
 
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?
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.
Und da bleibt als Abfallprodukt eben dann doch mehr Information hängen, als man eigentlich beabsichtigt. Unter anderem kann man sich ohne großen Zusatzaufwand die Farbinformation, die in das andere Polygon "ausbluten" könnte greifen und überblenden.

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.
Das ist richtig, nur wie gesagt setze ich nicht voraus, dass ein AO Algorithmus nur aus Primärstrahlen besteht.

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.
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.
Das Prinzip bleibt beim RTRT gleich.

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
Gugg mal da:
GeForce.com Shadow of the Tomb Raider Ray-Traced Translucent Shadows Interactive Comparison: On vs. Off - Example #003
Links hast Du unterschiedliche Transparenzen inkl. Überlagerung bzw. Akkumulation.

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.
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...

Die Implementation von BFV ist, wenn man die mit der von Wolfenstein Youngblood vergleicht schlicht ineffizient. Wobei man natürlich berücksichtigen muss, dass die ersten Implementationen mit heißer Nadel und kaum Erfahrung gestrickt wurden.

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.
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.
Man muss dieser Technik aber auch eine entsprechende Entwicklung zugestehen. Und die oft vorherrschende Einstellung, dass man, lieber garnichts hätte, als schrittweise Verbesserungen kann ich so überhaupt nicht nachvollziehen. Denn demnch hätte es niemals eine Entwicklung in rasterbasierter Berechnung geben können.

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.
Oder Du gehst auf Schwellwertbasis bzw. Raylänge.

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.
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.

Schön, dass man hier auch tiefgreifender über die Themen diskutieren kann.
 
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.

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. Komplettes Spiel ist was ganz anderes als Haufen Daten nur in eine Demo-Level zu packen wo noch viele andere Dinge wie Gegner, Kameraden KI und NPCs fehlen.

Deswegen wird man erst mal sehen müssen welcher Aufwand dort wirklich entsteht wenn man mehr als ein Tech-Demo-Level will.
 
Wenn Raytracing wie beim PC nur in 2k brauchbar ist, kann es wegen mir auch wieder verschwinden.
Die paar wenigen PC Spiele die Raytracing unterstützen sehen zwar ganz gut aus, aber ich finde es wesentlich angenehmer in 4k zu zocken.
 
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.
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.

AMD hat extra für Microsoft, oder auf deren Wunsch die Rayaccel-Engine implementiert, die BVH ähnlich wie Nvidia über Units und genauso wie Texturen beschleunigen kann, nur wollen die Entwickler das geplante Balancing nicht aufgeben und den Anteil (Zuwachs), den man durch die Shader und das Caching von RDNA2 hinzugewinnt. Das ist über Jahre gewachsen.

Das bei der X von Microsoft kein RT zu Anwendung kommt, hat Grossman nicht gesagt. Der Fokus liegt aber auf dem Rendering, nicht Raytracing. Das liegt an dem Geometrie-/Hierachienmodell der Konsolen. Nvidia wird es vermutlich schwer haben, ohne Unterstützung der Konsolenentwickler RTX weiter im Markt zu etablieren, bzw. kommt es zu zeitlichen Verzögerungen über eine Konsolengen (also ca. 5 Jahre).

Die kleine Konsole kann das vermutl. gar nicht, da wird RDNA Light drin stecken. Es liegt auch nicht an AMD, die müssen gerade mal eine DCU=26DCU=52CU's (also zwei CU's deaktivieren). 7nm (egal welcher Prozess->N7P?) läuft also ziemlich gut, eine Redundanz wird es immer geben. Damit lässt sich aber auch nachträglich, nichts mehr freischalten was die Leistung noch steigern könnte.

Etwas in Hardware zu entwickeln ist das eine, nur muss der Markt es dann auch annehmen (können). Wenn das nicht geschieht, stagniert dieser Node zeitlich. Daher fokussiert sich Nvidia vermutlich massiv auf DLSS. AMD könnte auf Basis von Direct-ML nachziehen, vermutlich werden die Konsolenentwickler es nutzen um die imaginäre Auflösung per Upscaling (was Sony sowieso schon immer implementierte) oder die Framerate zu steigern.
 
Zuletzt bearbeitet von einem Moderator:
Zurück