Kacha schrieb:
Ich tippe darauf, dass du aus dem Game Design Bereich kommst?
Da bin ich nebst dem Bereich eines Engine Techies inzwischen gelandet...
Du redest von vorhanden Informationen, bzw., dass man sie errechnen kann. Das stimmt aber so nicht.
Mit Errechnen ist in diesem Sinne nicht gemeint, etwas Neues zu berechnen, sondern bereits bekannte Informationen mittels neugewonnener Informationen zu kumulieren. Du setzt ja nur ein Mosaik unter Einsatz von Jitter wieder zusammen.
Was vorhanden ist sind im Endeffekt sehr komplexe Formeln, die mit einer gewissen Genauigkeit etwas berechnen koennen.
Exakt, deswegen hat das DLSS- Bild ja auch nicht durchgehend bessere Qualität. Ursächlich dafür ist meist nicht konsistentes berechnetes Ausgangsmaterial. Wenn man zum Beispiel im Post- Processing anfängt, im Screenspace rumzufummeln oder da etwas nachträglich einzublenden.
Dort geht dann dem DLSS die essenziell wichtige Bewegungsinformation flöten sprich die Mosaiksteinchen werden nicht mehr an den richtigen Platz gesetzt und es gibt Fehler.
Und nein, die Genauigkeit ist nicht 100% und wird sie auch in Zukunft nicht sein.
Muss sie auch nicht sein, da durch die Nutzung der Bildinformation von 3 Bildern so viel Pixelmaterial vorhanden ist, dass es, wenn ordentlich programmiert auch mit Deutungsfehlern in der Praxis noch höher aufgelöst ist als nativ.
Dass das Netz ein paar mehr Informationen als das Bild benoetigt ist nicht weiter verwunderlich und dient nur dazu die Genauigkeit zu erhoehen. Erhoeht halt auch die Komplexitaet.
Was das Teil macht ist ein besserer "educated guess". Was dann halt zu Texturfehlern, bzw. teilweise auch zu verschwindenden Texturen fuehrt. Je nachdem wie man danach nochmal filtert.
Werden die Framebuffer richtig übergeben, ist es das nicht. Du kannst durch die Motion- Vektoren zielgerichtet bestimmen, wo die kumulierten Pixel anzuordnen sind.
Zudem scheinst Du bei DLSS1.0 stehengeblieben zu sein. Ich beziehe mich auf DLSS2.0. Dort werden die Texturen nicht angerührt. Die bleiben in voller Auflösung erhalten. Sollten da irgendwelche Texturen verschwinden, ist es schlampig oder fehlerhaft implementiert.
Aufgrund dieser letzten Aussage von Dir muss ich vermuten, dass Du Dir meinen Link nicht durchgelesen hast, in dem alles erklärt wird.
Das was du postest ist hauptsaechlich Nvidia Marketing und laesst halt die Probleme weg. Ist kein Problem wenn es nicht dein Themengebiet ist, aber so einfach wie du es darstellst ist es eben nicht und die anderen sind eben keine Geisterfahrer.
Wenn Du unter dem Terminus "nvidia Marketing" den faktischen technischen Ablauf der Bildgenerierung durch DLSS 2.0 verstehst, dann hast Du recht. Das habe ich gepostet.
Da ich den ganzen Spaß gerade in unsere Engine integriere, kann ich Dir halt einfach nur erklären, was technisch Sache ist. Das kannst Du annehmen, musst es aber nicht.
Und doch- Es ist so einfach, wenn man eben vor der Verarbeitung durch DLSS saubere Renderinformation liefert.
Da spielen aber die alten Gewohnheiten der Optimierung vor dem TAA- Aufruf oftmals Streiche.
Die Programmierer gehen im Augenblick da noch einen Kompromiss ein. Denn noch müssen sie dafür Sorge tragen, dass die Spiele auch ohne DLSS möglichst performant laufen.
Deswegen wird getrickst. Dass es dann deshalb hier und da zu Artefakten kommt, nimmt man derzeit aufgrund der noch nicht allumfassenden Verbreitung von RTX- Karten noch billigend in Kauf.
Dort das Fass einer zweiten, fehlerfreien Renderpipeline nur wegen DLSS 2.0 aufzumachen ist ökonomisch einfach auch derzeit noch Unsinn. In Zukunft kann man aber grundsätzlich mit DLSS "in mind" planen. Dann werden auch sehr gute bis perfekte Implementationen dabei rumkommen.