Richtig, Raytracing hat zum allerersten mal Reflexionen ermöglicht, die nicht aus dem Bild gewischt werden müssen und von Artefakten geplagt sind, sobald sich die Kamera bewegt oder ein Objekt aus dem Sichtfeld verschwindet, ein Meilenstein.
Für jemanden, der anderen täglich Beleidigungen an den Kopf schmeißt, ist dein Wissen über 3D-Rendering jenseits der Nvidia-PR-Bubble erstaunlich beschränkt.
Zur Weiterbildung: Planar Reflections können Objekte außerhalb des Sichtfeld darstellen. Und Cube Maps prinzipiell auch, aber die nutzt man sowieso nicht, wenn einen solche Details interessieren. Beide Techniken gab es lange vor Raytraycing-Reflektionen in Spielen. Und auch vor den Screenspace Reflections, für die von dir beschriebene Artefakte typisch sind. Die Ärgernisse mit dieser bekanntermaßen billigsten, minderwertigsten Lösung überhaupt, kamen erst nachträglich in Spiele, weil sie so wenig Leistung kostet.
Planar Reflexions sind im Gegenzug zwar hinsichtlich den Eigenschaften der reflektierenden Oberfläche eingeschränkt. Paradoxerweise nutzen die meisten Spiele Raytraycing-Reflexionen bis heute aber nur in einer Qualität respektive an Positionen, für die Planars perfekt geeignet wären. Bestes Beispiel sind weiterhin die Bodenreflexionen in Alien: Isolation, die sich (wenn man die Qualität auf max dreht) vor Cyberpunk & Co kein bisschen zu verstecken brauchen, aber mit einem Bruchteil an Hardware-Leistung auskommen.
So funktionieren halt alle gängigen Engines und wenn man die weiter verwenden will, dann muss man sich irgendwie in die vorhandene Architektur einfügen.
Ich hatte ganz zu Anfang die naive Vorstellung, dass man in Zukunft quasi eine KI-Engine hat, die die herkömmlichen Grafik-Engines komplett ersetzt. Der sagt man dann nur noch, "da" "steht" ein "Stuhl", und "dort" "läuft" eine "Person" von "A" nach "B".
Klingt im ersten Moment toll, nur hätte man dann eine komplett eigene Engine, die nur auf kompatibler Hardware läuft. Und wie ein Stuhl konkret aussieht ("Creators Intent"), und dass das überhaupt ein Stuhl ist, wäre damit immer noch nicht geklärt. So wie ich das verstehe, ist ein Stuhl ein Asset für die Engine, in der Geometrie und Oberflächen mittels eines gerüttelt Maß an Polygonen (5-stellig!) und Texturen definiert wird. Das sind also ziemlich viele Daten pro Asset, und blöderweise steht da trotzdem nirgends inhaltlich verwertbar drin, dass das ein "Stuhl" aus "Buchenholz" ist, sondern das ergibt sich für den Betrachter aus den gerenderten Daten des Assets.
Damit das also "ohne Umweg" funktioniert wie von Dir vorgeschlagen, bräuchte man auch komplett neue bzw. überarbeitete Assets.
Daher erscheint mir der angebliche "Umweg" über das gerenderte Bild ziemlich sinnvoll und pragmatisch. Man könnte sagen, das gerenderte Bild enthält für das betrachtende Modell alle notwendigen Informationen, und das bereits komprimiert.
Moderne 3D-APIs arbeiten objektorientiert. Die Engine übergibt die Szene nicht Polygon für Polygon, sondern verwaltet die Polygongruppe, welche den Stuhl repräsentiert als ein Asset. Das geht soweit, dass ein zweiter Stuhl copy & paste auf der Grafikkarte erstellt werden kann, in dem man das gleiche Objekt mit einer neuen Koordinate und Ausrichtung ein zweites Mal rendern lässt, ohne es noch einmal übertragen zu müssen. Genauso werden Oberflächen seit der Einführung von physcial based rendering nicht mehr einzeln vom Texturdesigner gestaltet. Es gibt ein Layer (oder heutzutage eher Shader), der für "Metall" steht, einen für Holz, die Holzmaserung kann seit komplett auf der GPU erstellt werden, wenn gewünscht, und so weiter. Das heißt an dem Stuhl klebt vielleicht nicht das Label "Stuhl", dass man direkt in einen Bildgenerator werfen kann. Der Entwickler kann das Asset auch "StrikeMan5000" genannt haben. Aber jedes Mal, wenn der Stuhl gezeigt werden soll, wird dieses Asset geladen und die KI müsste nur einmal die Polygone analysieren und wüsste dann, um was es sich handelt – was sie ohnehin muss, schließlich können in Spielen auch komplett neue Objekte auftauchen, deren Umriss nicht im Trainingsmaterial war.
Die Formulierung, dass das Render-Bild eine komprimierte Version der gewünschten Ausgabe ist, stimmt aber. Der Fehler liegt halt genau darin: Komprimieren sollte man vor einer Einlagerung, nicht vor der Ausgabe. Da muss man dekomprimieren. Alles andere ist ein Umweg oder bestenfalls ein Zwischenschritt, der Lag und Fehlerquellen mit sich bringt.
Genau, und weil DLSS 5 Zugriff auf diese Daten hat Vektoren/Masken/Albedos hat ist es kein Filter und der Buchenholztisch wird genauso wenig mit der Birkenholzstuhllehne verschmelzen wie zwei völlig separate Objekt IDs in einer professionellen 3D Engine wie Unreal. Für den Algorithmus sind Tisch und Stuhl glasklar getrennte Instanzen.
Die Masken und Vektoren sind meinem Wissen nach, passend zur Arbeitsweise mit dem fertigen Bild, pixel- und nicht objektbezogen. Das heißt für jeden einzelnen Frame muss der Renderer zusätzlich eine Vektormap berechnen, welche die 2D-Bewegung von Bildelementen in für DLSS verständlicher Form wiedergibt, obwohl die zugrundeliegenden 3D-Bewegungen der Objekte in der Szene lange vorher und in viel präziserer Form vorliegen.
Was glaubst du eigentlich wie 2D zu 3D Konvertierungen im Jahr 2010 funktioniert haben? Das war händische Sklavenarbeit, ein Servercluster hat das nicht mit KI"berechnet", der hat nur die händisch freigestellten Ebenen gerendert. (Rotoskoping)
Das waren die besseren. Die schlechten haben aufeinanderfolgende Frames algorithmisch auf Paralaxen hin abgesucht, mit in der Regel grauenhaftem Ergebnis. Rotoskopie ist übrigens das genaue Gegenteil: Man bewegt einzelne Bildelemente tatsächlich dreidimensional, um die resultierenden Paralaxen korrekt in einem 2D-Bild wiederzugeben. Zum Beispiel die alten Disney-Filme waren Meisterwerke dieser Technik und haben teils ein dutzend Hintergrundebene physisch gegeneinander bewegt, um mit den immer gleichen gezeichneten Bildern ganze Sequenzen von hunderten Frames auf Film zu bannen.
Pathtracing ist nur ein Werbebegriff für Raytracing mit ner halbwegs anständigen Anzahl an Strahlen und Bounces. In Hogwarts Legacy konnte man z.B. vor dem Update mit solchen Optionen im Menü bereits über die ini Datei mit diesem Parametern effektiv einen Pathtracing Mod erstellen.
Jein: "Pathtracing" gemäß Nvidia-PR-Sprech ist ein Rendering des gesamten Bilds mittels Raytracing, während ein sogenanntes "Raytracing"-Bild gemäß Nvidia-PR-Sprech auch zu 99 Prozent aus Rasterizing bestehen kann. Man braucht also mehr Rays für sogenanntes "Pathtracing", aber das ist nicht der einzige Unterschied. Zusätzlich muss man auch die Anwendung auf das ganze Bild festlegen. Nur 10 mal mehr Strahlen auf den "RT"-Teil zu feuern würde nicht reichen, man muss ja auch den Rest sehen können.
Außerhalb des PR-Sprechs beschrieb Pathtracing übrigens mal Raytracing, dass jede Strahlenkette von der Kamera bis zu einer Lichtquelle oder umgekehrt verfolgt. Meinem Wissen nach ist das bei "Pathtracing"-Spielen weiterhin nicht flächendeckend der Fall, aber durchaus für einen Teil der Reflektions-Einblendungen in "Raytracing"-Titeln.
Das ist faktisch für den Einsatz in Spielen einfach falsch. Alles Raytracing in Spielen basiert auf dem Pathtracing Algorithmus.
Alle Rasterverfahren über Board werfen wiederum haben wir afaik genau ein Mal in einem Spiel gesehen, das war Minecraft RTX. Was übrigens wiederum nur mit Raytracing statt Pathtracing beworben wurde. Heute wäre der Mode-Begriff dafür "Full Pathtracing".
Nein, da ist kein Rasterizing mehr im Spiel. Aber es gibt jede Menge andere (KI-)Tricks, um nicht jedes Pixel in jedem Frame mit allen in Frage kommenden Lichtquellen verbinden zu müssen. Letzteres müssten neben Minecraft auch noch Quake II RTX und Verwandte machen. Portal RTX geht auch sehr weit (in den Keller mit der Performance). Alle drei Beispiele integrieren aber zusätzlich noch temporal, verfolgen also nicht jeden Strahl in jedem Frame bis zu Ende für Echtzeitberechnung.
Jein, es gibt einige Quellen, die von einer Verbesserung der Beleuchtung,
sowie der Materialen sprechen. Ich denke, so kennst du das auch?
Hier ist ein Quelle. Weitere lassen sich leicht googlen:
DLSS 5 ist seit dem gestrigen 16. März 2026 offiziell angekündigt. Anders als der Name zunächst vermuten lässt, handelt es sich aber nicht einfach um die nächste Ausbaustufe eines klassischen Upscalers, sondern um einen deutlich weitergehenden Ansatz. NVIDIA beschreibt DLSS 5 als Echtzeit Neur…
www.igorslab.de
Meine Interpretation ist, dass die Überarbeitung der Materialien zwangsläufig aus der verbesserten Beleuchtung resultiert. Wenn ich eine Texture mit Oberflächenstruktur und Lichtbrechung korrekt ausleuchte, bzw. die Farbwerte, das Sub Surface Scattering, die Mikroverschattung (aufgrund der Struktur), usw. richtig "berechne", ändert sich zwangsläufig die Anmutung aller Materialien. Anders geht es nicht. Wenn man die Materialien nicht anfasst, hat man keine realistische Beleuchtung umgesetzt. Wer hier nur an Schatten, Umgebungsverdeckung und Ganzpunkte denkt, denkt viel zu kurz.
Im Umkehrschluss bedeutet das, dass die Texturen im Grunde unverändert bleiben. Sie reagieren nur korrekter auf das Licht. Eine Baumrinde wird nicht plötzlich borkiger oder höher Auslösend. Das wäre ein Maß an generativer Freiheit, dass Nvidia ganz bewusst nicht haben will (Artist intent, usw.)
Dieser Auffassung musst Du natürlich nicht folgen. Aber hoffentlich ist verständlich geworden, was ich ausdrücken wollte.
Was du hier beschreibst, ist die
Intention dessen, was DLSS5 abbilden will (oder zumindest eine von mehreren), aber nicht die
Methode. Diese feinen Effekte tatsächlich zu berechnen wäre z.B. mit Normal-Mapping und verdammt vielen Rays möglich. Sowas macht DLSS aber allgemein nicht, es hat ja nicht einmal Zugriff auf die nötigen Geometriedaten die Ausrichtung von Wand und Lichtquelle zueinander definieren.
Stattdessen wertet DLSS das fertige Bild aus und gleicht es mit dem KI-Wissen darüber ab, wie eine derartige Szene aussehen
sollte, wenn sie mit allen Details gerendert worden wäre. Diese Details werden dann ergänzt. Übersimplifiziertes Beispiel: Wenn du den Umriss eine Autos renderst und die Räder vergisst, würde DLSS ein vollständiges Auto mit Rädern ausspucken. Aber es wäre ein KI-Bild eines solchen Autos, nicht ein Rendering des gewünschten Autos an der gewünschten Position. Daraus resultieren auch die typischen "Fehler" von DLSS, wenn zum Beispiel eine Person Instagram-like dargestellt wird, obwohl der Designer das gar nicht wollte. DLSS trifft eine falsche Annahme der Intention und setzt die um.
Dieses Dilemma ist übrigens nicht neu, sondern begleitet DLSS von Anfang an. Heute sind die Fehler in Mikrodetails zurückgedrängt, weswegen das Ergebnis nur "unnatürlich" wirkt. Aus den Anfangstagen kann ich mich zum Beispiel an Stadtpanoramen in Arkham Asylum erinnern, in denen schlechte Teile von Gotham City schlechter beleuchtet sein sollten. Aber DLSS1 hat einfach oben auf jeden Laternenmast einen grell weißen Blob draufgesetzt – "kaputte Laterne" kannte es noch nicht. Es ergänzte also ein "fehlendes" Detail, wo absichtlich etwas anderes gewünscht war.
