Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

PCGH-Redaktion

Kommentar-System
Teammitglied
Jetzt ist Ihre Meinung gefragt zu Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Minecraft bekommt RTX-Support: Was seit Monaten bekannt ist, nähert sich nun der Zielgeraden. Nvidia und Microsoft gewährten der Presse einen Ausblick auf Minecraft RTX, während die Finalisierungsarbeiten an der öffentlichen Beta laufen. Minecraft RTX wird am 16. April allen Besitzern von Minecraft Windows 10 Edition kostenlos zur Verfügung gestellt. PCGH verrät, was Sie erwartet - und was Pathtracing eigentlich ist.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

lastpost-right.png
Zurück zum Artikel: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Ist aber schon etwas lächerlich wenn man sich die Vergleichsbilder anschaut.
RT scheint eher in Blöcke eine Glühbirne einzubauen und nicht mal Spiegel würde sowas verursachen.

Ich frag mich gerade könnte man nicht einfach die Blöcke genauso zum leuchten bringen und hätte dann ein ähnliches Ergebnis.
Weil da hat man wesentlich mehr gemacht als nur ein paar Strahlen im verlauf berechnet.

Realistisch ist das überhaupt nicht mehr Räume mit wenig Lichteinfall leuchten wie eine Disko.
Blöcke die getroffen werden leuchten wie eine Lampe, das würde einfacher genauso gehen.

Das ist doch viel mehr als nur RT das ein bisschen Bounce man die Blöcke geändert für ein extremes Ergebnis.
Realistisches verhalten sieht so auf jedenfalls nicht aus und das wollte man auch nicht. Im Grunde hat man die Parameter
so geändert das man eine komplett andere Optik hat Ansonsten könnten wir uns unsere ganzen Lampen sparen wenn alles
zum Leuchten anfangen würde wenn Strahlen drauf treffen.

Das wäre so ähnlich garantiert vorher gegangen ohne massive Einbußen. Wenn die Beleuchtung realistisch ist, suchst nämlich mit der Lupe
nach unterschieden und nicht selten ist RT dann sogar negativ. Weil Orte die Beleuchtet waren durch Fake dann es eben nicht mehr sind,
zwecks Sonnen stand.
Hier aber haben sie ganz einfach Promotion Overkill betrieben, Blöcke werden nicht nur einfach getroffen von den Strahlen sondern werden gleich mal
selbst zu einer neuen Lichtquelle!
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Ist aber schon etwas lächerlich wenn man sich die Vergleichsbilder anschaut.
RT scheint eher in Blöcke eine Glühbirne einzubauen und nicht mal Spiegel würde sowas verursachen.

Kann ich gar nicht nachvollziehen. Die Bilder sehen, bis auf das erste, für mich alle extrem gut aus. Bekommt man selber wieder lust in die Klötzchenwelt einzutauchen, was ich wohl auch machen werde für das RTX-Update.
Es sind halt so ausgewählte Bilder von Nvidia und nicht einfache irgendwelche random Aufnahmen. Wenn man sich die Kirche (#5) mal genauer ansieht, sind überall weitere Lichtquellen eingebaut, als nur die Sonne. Jede Menge Laternen, Lampen und selbst die grünen Blätterblöcke stehen auf einer art brennendem Ofen. Klar leuchtet dann auch alles, aber nicht etwa weil RT so extrem eingestellt ist.
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Würd ich ja gerne Spielen, aber eine RTX werd ich mir nicht holen und ohne Hardwarebeschleunigung geht die Leistung halt flöten.

RT scheint eher in Blöcke eine Glühbirne einzubauen und nicht mal Spiegel würde sowas verursachen.
Wie kommst du auf die Idee??

Ich frag mich gerade könnte man nicht einfach die Blöcke genauso zum leuchten bringen und hätte dann ein ähnliches Ergebnis.
nein - schlichtweg nicht möglich.
Weil da hat man wesentlich mehr gemacht als nur ein paar Strahlen im verlauf berechnet.
Und nochmals nein. Es wurde hier nur die Beleuchtung ersetzt.

Realistisch ist das überhaupt nicht mehr Räume mit wenig Lichteinfall leuchten wie eine Disko.
Blöcke die getroffen werden leuchten wie eine Lampe, das würde einfacher genauso gehen.
Bei welchem der Bilder?

Das wäre so ähnlich garantiert vorher gegangen ohne massive Einbußen.
Aber sicher doch.... klar. Wenn du sowas auch nur ansatzweise schaffst werden die die Entwicklerstudios die Tür einrennen und dich mit Geld geradezu niederschlagen.
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Respekt ! Sieht schon sehr KNORKE aus … :-)

MfG Föhn.
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Finde bestimmte technische Sachen interessant(auch wenn mich Klötzchenspiele nicht interessieren). Auch im Hinblick auf die Zukunft der Games(zumindest so ab 2021) inkl. RT-Technik.

Insgesamt 45 Prozent der pro Frame aufgewendeten Rechenzeit werden für das Denoising ("Spatiotemporal Variance Filters") aufgewendet. Diese sind aufgrund der stochastischen Berechnung der einzelnen Sekundärstrahlen elementar, um Rauschen herauszufiltern. Dafür kommen gleich drei Algorithmen zum Einsatz: einer für diffuse Oberflächen, einer für glänzende und einer für die Sonnenschatten. Ein jeder ist maßgeschneidert für seine spezielle Aufgabe und mit sinnvollen Performance-Kompromissen ausgestattet. Die Denoiser arbeiten nicht nur spatial (räumlich), sondern auch temporal (zeitlich), ergo mit Informationen vorangegangener Frames (Akkumulation). Alle genannten und weitere Bild-Teile werden am Ende, im Combine Pass, zusammengesetzt.

Braucht das nicht einiges an Leistung, das in angemessener Zeit pro Frame hinzukriegen ?
Ist hierfür die (extra RTX) Hardware von Nvidia's Karten zuständig, oder ist das rein DX-RT softwaretechnisch und von allen Karten gleichermaßen, AMD und Nvidia gleich möglich ?

Ich frage mich das gerade, weil ja AMD auch mit RT um die Ecke kommen möchte(zumindest in kommenden Highend-Modellen) und die Konsolen das auch können sollen, angeblich.

Wo hat denn RTX jetzt einen Vorteil, bzw. der spezielle Hardwareteil von RTX Karten ?
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Wieder nur ein Filter. Wann nutzt man endlich AI Denoising? Kein Wunder dass es 45% des Frames ausmacht. Die Turing Tensor Cores könnten das innerhalb kürzester Zeit durchpowern.
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Finde bestimmte technische Sachen interessant(auch wenn mich Klötzchenspiele nicht interessieren). Auch im Hinblick auf die Zukunft der Games(zumindest so ab 2021) inkl. RT-Technik.



Braucht das nicht einiges an Leistung, das in angemessener Zeit pro Frame hinzukriegen ?
Ist hierfür die (extra RTX) Hardware von Nvidia's Karten zuständig, oder ist das rein DX-RT softwaretechnisch und von allen Karten gleichermaßen, AMD und Nvidia gleich möglich ?

Ich frage mich das gerade, weil ja AMD auch mit RT um die Ecke kommen möchte(zumindest in kommenden Highend-Modellen) und die Konsolen das auch können sollen, angeblich.

Wo hat denn RTX jetzt einen Vorteil, bzw. der spezielle Hardwareteil von RTX Karten ?

So wie ich das verstehe beziehen sich die Angaben von Nvidia allein auf die neue "RTX-Grafik", also die neue, volumetrische Beleuchtung, die temporale Verrechnung, das Raytracing und das Denoising. Also alles abseits der eigentlichen Spielgrafik, die auch noch berechnet werden muss. Die 100 Prozent beziehen sich also meines Erachtens nur auf die "Nvidia-Effekte", die Renderzeit für die Polygone, die CPU-Berechnungen, Post-Processing, etc. sind da nicht mit drin (und fehlen auch in der Tabelle). Die gesamte Renderzeit wäre demnach also (unter Umständen deutlich) größer als 100 %, was wiederum bedeutet, dass das Denoising nicht 45 Prozent der Gesamt-Renderzeit ausmacht, sondern nur 45 Prozent der Berechnungszeit der "RTX-Grafik", was um den Faktor X weniger als die Gesamt-Renderzeit wäre (das X müsste man dann gesondert bestimmen, etwa bei Vergleichen zwischen RTX on und off - wobei da auch andere Faktoren, beispielsweise die CPU-Performance verzerrend wirken könnten). Deswegen steht da auch "Relativ".

tldr.: Die 45 % beziehen sich wahrscheinlich nur auf die zusätzliche Renderlast durch die RTX-Grafik (angeschaltet sind 100 %, ausgeschaltet sind 0 %), nicht die Gesamtrenderpipeline.
Im Endeffekt dürfte das Denoising deutlich weniger Renderzeit beanspruchen, wenn man die gesamte Render-Pipeline betrachtet.

Die RTX-GPUs können via RT-Cores schneller berechnen, wo sich ein Ray im Raum schneidet und sind effizienter bei der Erstellung und Handhabung von den benötigten Datenstrukturen (Bounding Volume Hierarchie, Turing hat außerdem größere Caches). Dabei ist es egal, ob das Ray- oder Pathtracing ist. Prinzipiell und theoretisch geht das alles aber auch regulär über Compute, man könnte also auch reguläre Shader nutzen, die sind bei Non-RTX-GPUs (bislang, die kommende AMD-Hardware außer Acht gelassen) aber nicht direkt für RT-Berechnungen ausgelegt und sind daher langsam.

Gruß,
Phil
 
Achja - vorher vergessen:
Path-tracing ist nur ein Spezialfall von Raytracing, nicht nur eine verwandte Technik.
"Raytracing" besagt nur das eine Berechnung auf Basis von Strahlen durchgeführt wird. Was genau bei einer Kollision geschieht ist nicht festgelegt. Es kann rein statistisch vorgegangen werden und Strahlen werden zufällig gesendet, oder heuristisch in gewisse Richtungen. Es kann nach der ersten Kollision schluss sein und nur die Farbe so berechnet werden oder Strahlen zu Lichtquellen geprüft werden.
Man kann einen einzelnen Strahl weiterführen ala depth-first (da fällt Path-tracing rein) oder aber bei jeder Kollision viele neue Strahlen (breadth-first) erzeugen (wie es beim altbekannten GLobal-Illumination photon rendering verwendet wird).

Und:
Pathtracing simuliert den physikalisch korrekten Weg eines Lichtstrahls durch die gesamte Szene
Ist ja auch nicht wirklich richtig weil es keinen "korrekten" Weg gibt. Es simuliert einen der unzähligen möglichen Wege.
Und Path-tracing funktioniert sehr wohl mit Punkt-Lichtquellen.

Der Vor und Nachteil von Pathtracing ist - es ist sehr Rauschanfällig, über die zeit gemittelt ergibt das aber eine hohe Qualität da das Rauschen keine "falschen" Werte sind sondern nur einzelergebnisse. Es lässt sich hervorragend temporär glätten.

Ist hierfür die (extra RTX) Hardware von Nvidia's Karten zuständig, oder ist das rein DX-RT softwaretechnisch und von allen Karten gleichermaßen, AMD und Nvidia gleich möglich ?
Die Strahlen werden per DXR berechnet, SVGF (das verwerten der Ergebnisse) ist rein Softwareseitig - also absolut alles auch auf AMD lauffähig - Wenn AMD DXR unterstützt.

Wo hat denn RTX jetzt einen Vorteil, bzw. der spezielle Hardwareteil von RTX Karten ?
Beim berechnen der Strahlen - das was eben wirklich viel aber simpelste Arbeit ist. AMD will das teilweise von den Texture-Einheiten erledigen lassen, viel in Software, da ist dann noch abzuwarten wie sich das Leistungstechnisch auswirkt.

Wieder nur ein Filter. Wann nutzt man endlich AI Denoising? Kein Wunder dass es 45% des Frames ausmacht. Die Turing Tensor Cores könnten das innerhalb kürzester Zeit durchpowern.
Was willst mit dem "AI" schrott?
Und das wird Nvidia sicher nicht machen - Das Spiel gehört MS und die werden eher wollen das es auch auf den Konsolen laufen kann - wenn fürs Denoisen die Tensor-Cores verwendet werden dann wars das mit AMD-Kompatibilität. Wär zwar schön wenn sie sowas optional machen würden, w#re aber wieder extra Aufwand und das zusammenspiel mit DLSS wäre wohl fraglich, je nach dem wann diese in der Pipline berechnet werden.
 
Zuletzt bearbeitet:
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

So überflüssig wie Goodride Reifen auf nem Porsche GT3:lol:
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Brauchen eckige Bäume eine korrekte Beleuchtung?
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Brauchen eckige Bäume eine korrekte Beleuchtung?
Also bitte, wenn ein Spiel von Path Tracing profitiert, dann doch wohl Minecraft. Bei Minecraft erschafft man doch ständig neue Lichtverhältnisse, d.h. die Welt ist sehr dynamisch. Perfekt also für Raytracing.
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Brauchen eckige Bäume eine korrekte Beleuchtung?

Ja, auch eckige Bäume. Auch die Bäume in zB Shadow of the Tomb Raider sind letztlich starke Vereinfachungen von echten Bäumen und den eckigen Bäumen in Minecraft viel ähnlicher als den realen Vorbildern draußen in den Wäldern.
 
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

So wie ich das verstehe beziehen sich die Angaben von Nvidia allein auf die neue "RTX-Grafik", also die neue, volumetrische Beleuchtung, die temporale Verrechnung, das Raytracing und das Denoising.
Also so weit gezeigt und beschrieben wurde ist das bereits die gesamte Berechnung. Es wird nicht nur die Spiegelung oder Beleuchtung sondern alles geraytraced - gut zu sehen an der verzerrten Darstellung wenn man unterwasser ist.
Es wird ja auch darauf eingegangen wie die physikalischen Texturen das Raytracing beeinflussen - das Texturen ihre eigenen Leucht und Spiegelungsinformationen haben die wiederum geraytraced werden müssen
 
Also so weit gezeigt und beschrieben wurde ist das bereits die gesamte Berechnung. Es wird nicht nur die Spiegelung oder Beleuchtung sondern alles geraytraced - gut zu sehen an der verzerrten Darstellung wenn man unterwasser ist.
Es wird ja auch darauf eingegangen wie die physikalischen Texturen das Raytracing beeinflussen - das Texturen ihre eigenen Leucht und Spiegelungsinformationen haben die wiederum geraytraced werden müssen

Ja, klar soweit.
Da sind trotzdem nicht die ganzen Berechnungen für die Geometrie mit drin. Man braucht außerdem das komplette Shading, damit man die Reflexions-Eigenschaften und die Färbung der Materialien und weitere ihrer physikalischen Eigenschaften überhaupt per Raytracing berücksichtigen kann... Das meine ich mit "regulärer Grafik". Da ist meines Erachtens nur abgebildet, was für Raytracing, die temporalen Verechungen und die volumetrischen Lichter nötig ist, bei letzteren eventuell nur die Verwaltung der Beleuchtungsdaten, nicht die eigentliche Berechnung der Beleuchtung. Die neuen God-Rays bzw. die Nebeleffekte sind außerdem meines Erachtens Post-Processing und kein Raytracing - und es ist ungewiss, ob das alles mit in der Rechnung enthalten ist.

Gruß,
Phil
 
Zuletzt bearbeitet:
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Ja, klar soweit.
Da sind trotzdem nicht die ganzen Berechnungen für die Geometrie mit drin. Das meine ich mit "regulärer Grafik". Da ist meines Erachtens nur abgebildet, was für Raytracing, die temporalen Verechungen und die volumetrischen Lichter nötig ist, bei letzteren eventuell nur die Verwaltung der Beleuchtungsdaten, nicht die eigentliche Berechnung der Beleuchtung. Die neuen God-Rays bzw. die Nebeleffekte sind außerdem meines Erachtens Post-Processing und kein Raytracing - und es ist ungewiss, ob das alles mit in der Rechnung enthalten ist.

Gruß,
Phil

Sie beschreiben wie das gesamte Rendering auf Rytracing basiert. Dreiecke auf 2D Bilschirmkoordinaten umwandeln kommt da nicht mehr vor. Es ist - so weit zumindest beschrieben - ein reiner Raytracer.
Wie gesagt erklären sie da wie die Farben eines jeden Objektes mittels der Strahlen berechnet wird, wie die Texturen die Farbe und die Aussendung von Strahlen beeinflussen, wie auch für die game-Logik nicht-Leuchtende Blöcke jetzt die Umgebung beleuchten können. Zwangsweise muss damit die gesamte Grafik fertig berechnet sein, da dann noch ein 2tes mal irgendetwas zu berechnen ergibt wenig Sinn.
Vor allem Effekte wie die gezeigten Unterwasser würden dann in der gezeigten Form nicht möglich sein - es hier wird physikalisch korrekte Brechung und Totalreflexion gezeigt.

GodRays und Nebel können durchaus auch als Postprocessing gemacht werden - kommt aufs Spiel an. Aber hier sieht man GodRays die von Objekten außerhalb des Blickfeldes beeinflusst werden und das ganze auch Unterwasser und für Schatten richtig.
Das Spiel erhält hier wirklich einen kompletten Render-Ersatz.
Wird sogar auf Nvidias Homepage erklärt:
Furthermore, path tracing delivers pixel-perfect dynamic god rays that move and change in step with the sun and moon’s position, and are affected by world geometry and the things you do and build.

Ich glaub das Bild verdeutlicht es am besten:
GeForce.com - Minecraft with RTX Beta - Imagination Island - Snell's Window - Ray Tracing Interactive Comparison: On vs. Off - Example #001
 
Sie beschreiben wie das gesamte Rendering auf Rytracing basiert. Dreiecke auf 2D Bilschirmkoordinaten umwandeln kommt da nicht mehr vor. Es ist - so weit zumindest beschrieben - ein reiner Raytracer.
Wie gesagt erklären sie da wie die Farben eines jeden Objektes mittels der Strahlen berechnet wird, wie die Texturen die Farbe und die Aussendung von Strahlen beeinflussen, wie auch für die game-Logik nicht-Leuchtende Blöcke jetzt die Umgebung beleuchten können. Zwangsweise muss damit die gesamte Grafik fertig berechnet sein, da dann noch ein 2tes mal irgendetwas zu berechnen ergibt wenig Sinn.
Vor allem Effekte wie die gezeigten Unterwasser würden dann in der gezeigten Form nicht möglich sein - es hier wird physikalisch korrekte Brechung und Totalreflexion gezeigt.

GodRays und Nebel können durchaus auch als Postprocessing gemacht werden - kommt aufs Spiel an. Aber hier sieht man GodRays die von Objekten außerhalb des Blickfeldes beeinflusst werden und das ganze auch Unterwasser und für Schatten richtig.
Das Spiel erhält hier wirklich einen kompletten Render-Ersatz.
Wird sogar auf Nvidias Homepage erklärt:


Ich glaub das Bild verdeutlicht es am besten:
GeForce.com - Minecraft with RTX Beta - Imagination Island - Snell's Window - Ray Tracing Interactive Comparison: On vs. Off - Example #001

Ich meine auch nicht die eigentliche Rasterization der 3D-Grafik. Du brauchst trotzdem die Koordinaten der Polygone im Raum, deren Shading und die Berechnung der Lichtquellen, sonst kannst du mit Raytracing nichts erfassen. Das kann ja durchaus die gleiche Renderpipeline sein, nur eben hintereinander. Erst Geometrie und Shading um die nötigen Daten zu haben, dann Raytracing.

Bei den God-Rays hast du übrigens Recht, das sollte ich eigentlich auch wissen, bzw. hab vergessen, dass die auch per Raytracing dargestellt werden. Die zeigen in ein paar Bildern Artefakte (z.B. Bild 6) und sehen manchmal etwas seltsam aus (Bild 4), weshalb ich fälschlich auf Post-Processing getippt habe. Die seltsame Optik bei Bild 4 (Licht ungleichmäßig auf den Materialien) liegt aber wahrscheinlich eher daran, dass da eine simplifizierte (Fake-)Beleuchtungsquelle zum Einsatz kommt, die im schwarzen Holz wiedergespiegelt wird, aber nicht tatsächlich licht wirft bzw. erhellt, wie die daneben liegende.


EDIT:

Path-tracing ist nur ein Spezialfall von Raytracing, nicht nur eine verwandte Technik.

[...]

Richtig, aber wenn ich das wieder zusammen unter einen Hut werfe, wird's nur noch unverständlicher ;) Ich hab's versucht und dann wieder verworfen, weil's zu diffus geworden ist. Ich arbeite auch noch an einem Print-Artikel, da werde ich etwas präziser formulieren. Ist hier so schon kompliziert und verwirrend genug, das müsste ich eigentlich besser und ausführlicher beschreiben, aber das sprengt den (auch zeitlichen) Umfang dieses ersten Launch-Artikels (richtig, weitere sind in Arbeit)

Ist ja auch nicht wirklich richtig weil es keinen "korrekten" Weg gibt. Es simuliert einen der unzähligen möglichen Wege.

Das stimmt. Ich hab's mal minimal angepasst.

Und Path-tracing funktioniert sehr wohl mit Punkt-Lichtquellen.
Nur, wenn ein Ray genau auf die Punktlichquelle fällt (was aufgrund der Größe der virtuellen Quelle nicht wahrscheinlich ist) oder diese als Volume (Kegel, Kugel, etc.) und nicht als Punkt behandelt wird. Leuchtende Texturen und ähnliche Rendertricks gehen natürlich auch, aber dann ergibt auch Pathtracing kein stimmiges Gesamtbild.
Hier, die World-of-Tanks-Entwickler haben für ihren Software-Raytracing-Ansatz extra die Beleuchtung angepasst...

Aber mit Raytracing ist das Ergebnis nun sehr nahe an der Realität, auch weil wir Lichtquellen nun als Volumes behandeln, nicht mehr als Punkte.

Gruß,
Phil
 
Zuletzt bearbeitet:
Danke Phil und Casurin für eure kundigen Antworten.

Ist insgesamt doch sehr spannend, was da alles parallel und hinternander berechnet werden muss, damit da ein einzelnes Bild bei rum kommt.
Manchmal ist das für mich, wie ein Wunder, dass da überhaupt was brauchbares bei raus kommt. Man nimmt das alles als einfacher Zocker so als selbstverständlich war, dass da wunderbare Bilder ablaufen und man das Gefühl hat, sich in virtuellen Welten zu bewegen.
Ich krieg' das kaum in meinen Schädel(im Sinne von Verstehen der ganzen Technik, die da im Zusammenspiel ist), ohne dass der anfängt zu qualmen. ;) :ugly:

Ist schon feine Technik. Und Hut ab, vor den Leuten, die sich sowas ausdenken und damit auch noch arbeiten können, um uns einfach schönere Spiele zu zaubern. :hail:

Wenn man das alles sieht, kommen mir die 7-900€ für eine neue GPU (die das alles auch super berechnen kann) gar nicht mehr so teuer vor.
Oder sehr aufwändige Spiele, die diese Techniken nutzen und gut umsetzen.

Es bleibt auf jeden Fall spannend, wie das auch in Zukunft weiter umgesetzt wird, auch von AMD.
Und natürlich von einer eventuellen 3080, die ich mir holen will. :D Aber mal schaun.
Bis Herbst/Winter is ja noch viel Zeit.

Freue mich jedenfalls auf alle neuen Sachen, die da kommen, sowohl was die Hardware angeht, als auch die Spiele.

Und danke Raff, für den spannenden Artikel. :daumen:
(Ohne den wir hier nix zu diskutieren hätten)


edit:

Interessant, dass ich einen Artikel spannend finde, nur wegen der Technik und überhaupt nicht wegen des Spiels.
 
Zuletzt bearbeitet:
AW: Minecraft RTX-Patch: Klötzengrafik trifft auf modernes Pathtracing und DLSS 2.0

Ich krieg' das kaum in meinen Schädel(im Sinne von Verstehen der ganzen Technik, die da im Zusammenspiel ist), ohne dass der anfängt zu qualmen. ;) :ugly:

Ich würde sagen der Ansatz von Raytracing an sich ist da sogar am einfachsten zu verstehen:
Man hat eine Szenerie die man als Bild darstellen will und der aller einfachste Weg ist Raytracing.
Du brauchst nur eine Position von der aus du das ganze sehen möchtests (Kamera), einen Ausschnitt den du Sehenmöchtest (Sichtfeld) und die Auflösung des Bildes. Und jetzt geht man von der kamera aus das gesamte Bild Pixel für Pixel durch und schaut was auf der verlängerten Linie von Kamera->BildPixel am Ende zu sehen ist. Da man jetzt quasi einen Strahl (ray) hat und diesen verfolgt (traced) hat man Raytracing. So mit nur einem Strahl hätte man jetzt nur die Textur von dem Objekt da, ohne Beleuchtung oder sonstiges. Da kann man jetzt mehr Raytracing nutzen - zB einen Strahl in Richtung jeder Lichtquelle schicken und schauen wie weit entfernt bzw ob sie Verdeckt ist - damit hat man die Beleuchtung. Oder weitere Strahlen für Spiegelungen ausschicken.

Einen Raytraced kann jeder Programmier-Anfänger von Grund auf schreiben ohne viel Mathematik zu können. Wie normalerweise gerendert wird ist da viel involvierter (man hat da Dreiecke bei denen jede Ecke 4 Koordinaten hat, muss das ganze dann mit irgend welchen Matrizen multiplizieren und bekommt davon dann die Bildschirmposition muss dann aber noch aufpassen was näher ist damit es nicht von weiter entfernten Objekten übermalen wird - funktioniert hervorragend und effizient, aber imo nicht so intuitiv)
 
Zurück