Minecraft RTX... - Das sagen die PCGH-Redakteure dazu

[PCGH_Torsten]

Tesselation hilft mit der GPU-Last gewaltig wenn entsprechend eingesetzt das es quasi eine Feinkontrolle von LoD Darstellt. Nicht nur die Übertragung von vielen Polygonen braucht Leistung, Culling und Vertex-shader genauso. Auch wird damit teils beträchtlich an Geometrie-Speicher gespart - wenn man es eben zur Leistungssteigerung einsetzen will.

Ich wüsste nicht, dass durch Tesselation erzeugte Polygone von den Vertex-Shadern anders behandelt werden als von der CPU generierte und das Risiko von Bildfehlern bei reduziertem Culling ist genauso groß wie immer, wenn man Aussagen über die Sichtbarkeit über Vereinfachungen ableiten statt konkret berechnen will. Aber auch hier gilt: Wenn du das Risiko eingehen möchtest, kannst du das auch mit von der CPU kontrollierten Polygonen. Ein LoD auf die GPU auszulagern erspart dieser keine Rechenzeit, sondern bestenfalls Entwickleraufwand, wenn er ein fertiges Tesselationsmodul nimmt, anstatt das eigene, CPU-basierte LoD feiner zu gestalten. Am Ende des Tages ist Tesselation aber nur eine alternative Verknüpfung zwischen Game-Engine und Shadern, bei der die Auflösung in konkrete Polygone zu einem späteren Zeitpunkt geschieht.
Edit: Damn. Vertex- und Geometry-Shader verwechselt.

Die Speicherthematik hat Eclipso sehr schön zusammengefasst. Ergänzen möchte ich noch, dass Geometrie-Daten meinem Wissen nach einen im Vergleich zu Texturen, Bildpuffern, Beleuchtung,... eher kleinen Teilen des VRAM-Bedarfs ausmachen. Selbst wenn du mit Tesselation 10 Prozent der gesamten Szene erst live generierst, würde ich keinen spürbaren Performance-Vorteil erwarten.

jein, RayTracing ist weitaus breiter einsetzbar und wird, zumindest in den Technischen Unterlagen, auch dafür erklärt. Man kann es zB für Partikel-Physik verwenden oder Umgebungseinflüsse auf Schall.
Für MC ging man den Weg die komplette Grafik umzustellen, andere Spiele verwenden es rein für Spiegelungen oder Global-Illumination.

Wenn die Rechenleistung schon nicht ausreicht, um das Verhalten von Licht zu berechnen, wer wird dann zusätzliche Ressourcen auf Schallwellen verschwenden, die bislang komplett stiefmütterlich behandelt werden? Selbst bei nahezu unbegrenzter Leistung würde ich Raytraycing dort für fragwürdig halten, da Schall sich nicht strahlen- sondern kugelförmig ausbreitet, was nur durch extrem viele Sekundärstrahlen korrekt simuliert werden kann.

Klar, Spiegelungen bringen am einfachsten ein "Wow" zustande, aber viel Sinnvoller wäre es für global-illumination. Da reicht sogar simpelstes Bruteforce noch für 4K 90FPS aus.
Es gibt schon ein paar Videos in denen Leute Linsen und Teleskope zeigen - sowas dynamisch und korrekt zu "faken" wäre für Minecraft sehr aufwendig (hab das mal vor Jahren zu modden probiert mit Spiegeln und Linsen - war eine Lustige Spielerei, aber auf ner r9 280x wars ne Slideshow auch bei 640*480 )

Ich spreche allgemein von den Möglichkeiten der Technik, da ich mit den Fähigkeiten der Minecraft-Engine nur bedingt vertraut bin. Wenn dieser fehle längst etablierte Elemente fehlen, ist es entwicklungstechnisch natürlich einfacher, diese über einen Raytraycer zu implementieren. Der muss, wenn man keine Rücksicht auf die Leistung legt, nur einfach Regeln der Reflektion und Brechung beherrschen, alles andere ergibt sich von selbst. Dieser vermeintlich elegante Code übersteigt aber in aktuellen Auflösungen die Rechenleistung verfügbarer Hardware bei weitem. Ich lasse mich da gerne eines besseren bezugen, aber echte Global Illumination mit vielen Lichtquellen, voller Sichtweite, sekundär-, tertiär- und quartär-Streuung und automatisch auch Schattenwurf habe ich noch nicht in UHD 90 Fps gesehen. Auch nicht in QHD 60 Fps. Und in komplexen Szenen nicht einmal in FHD 30 Fps. Was klappt ist der direkte Licht- und Schattenwurf einzelner Lichtquellen ohne, weitere Ausbreitung des Lichts. Aber das ist dann fast der technischen Stand von Rasterizern mit Stencil-Schatten und hat nicht einmal einen Ambient-Occlusion-Effekt mit drin, geschweige denn physikalisch korrekte, indirekte Beleuchtung der gesamten Szene. Die würde ich umgekehrt sogar als größte Herausforderung für Raytraycer betrachten, eben weil jede matte Oberfläche hunderte von Strahlen der nächst niederen Ordnung für eine korrekte Berechnung provoziert, während perfekte Reflektionen (oder Brechungen – gutes, wenn auch seltenes Beispiel) nur einen einzigen Sekundärstrahl generieren.

 

[ChrisMK72]

Auch nicht in QHD 60 Fps.

Das wär ja noch n Traum, in Spielen wie RDR2.
Mal schaun, was die 3000er so bringen.

 

[ZeroZerp]

Das wär ja noch n Traum, in Spielen wie RDR2.
Mal schaun, was die 3000er so bringen.

Womit Du eben genau den Finger auf die Wunde gelegt hast. Rasterisierung hat einfach ein Thema mit Szenenkomplexität, Berechnungstiming und dem "Faken" gewisser Effekte, die eben dann doch wieder ineffektiv mittels stochastischer "bruteforce"- Berechnungen abgehandelt werden müssen.
Deswegen sind selbst moderne Grafikkarten mit der Komplexen Welt einer AAA Produktion locker in die Knie zu zwingen.

Dieser vermeintlich elegante Code übersteigt aber in aktuellen Auflösungen die Rechenleistung verfügbarer Hardware bei weitem.

Man muss sich von den alten Denkschemata und den Grenzen lösen, die der rasterbasierte Ansatz in die Köpfe geprägt hat.

Bei einem reinen Path- Tracer könnte man nämlich allein schon eine Beschleunigung um den Faktor 4 erreichen, indem man auf eine Platine 4 GPUs steckt, mit einem verschwindend geringen Bruchteil der Nachteile des geringer werdenden Grenznutzens und der Synchronisationsthematik.
Durch den Per- Pixel- Ansatz kannst Du das Bild in beliebig viele Arbeitspakete einteilen (siehe auch Cinebench). Da steckst Du einfach mehr Prozessoren oder Kerne rein und es wird schneller, da pro Kern ein immer kleiner werdendes Arbeitspaket generiert werden kann.
Auch können die Arbeitspakete mit ansteigender Komplexität skalieren. Sind z.B. in einem Arbeitspaket viele für RT Rechenaufwändige diffus- spiegelnde Oberflächen, vorhanden, könnte man dort zusätzliche Worker spawnen bzw. das Paket nochmals unterteilen um den zeitlichen Berechnungsnachteil zu egalisieren.

Paralleler als diese Technik wirds in Sachen Grafik nicht mehr. Da könnte ein Big/Little Prinzip im Multigpu- Ansatz in Sachen Leistung aber -und das ist ein ebenso wichtiger Punkt- auch kosteneffizienz richtige Wunder wirken.
Ein großer Rechenblock für "klassische" Aufgaben, auch für die Steuerung und viele viele kleine, billige Rechenblöcke fürs Ray-/Pathtracing wären denkbar.

Man stelle sich eine zukünftige GPU vor (die von mir oben erwähnten Nachfolger der kommenden Generation), die, wenn man z.B. 4 GPUs auf die Platinen packt, dann die 16- Fache Tracing- leistung einer heutigen 2080TI liefert.
Reicht die Leistung nicht? -> Karte dazustecken, schon gibts die 32- Fache Leistung einer 2080TI.
Enthusiast? -> QUAD SLI hat wieder eine Berechtigung und belohnt einen mit 64- Facher Leistung.
Auch können unterschiedliche GPUs gemischt werden, so dass sich jeder User ganz individuell sein System fast ohne Aufrüstungsgrenzen zusammenstellen könnte.

Die alten Zöpfe abgeschnitten und rein auf Ray-/Pathtracing optimiert? Auch die Spieleengine darauf zugeschnitten/optimiert? ->
Dann steht dem ganzen Spaß in Realtime mit hoher Qualität und hoher Auflösung nichts mehr im Wege. Würde man die 2080TI vom Rastermüll und entsprechend einhergehenden Kompromissen (auch in Hardware) befreien, wäre sie bereits heute in der Lage UHD mit 20 Rays pro pixel zu befeuern.
Mit der oben erwähnten 64- Fachen Leistung wären wir bereits bei den 1280 Rays/Pixel mit UHD und 60FPS, ab welchen ein Raytracing- Bild auch ohen Denoiser und DLSS als "rauschfrei" gilt.

Inkl. der Vorteile, die sich für alle Entwickler durch den Einsatz dieser Technik ergibt. So muss nicht mühevoll jede Engine mit noch moderneren "sophisticated" Tricks modernisiert werden. Denn der Renderansatz ist von Grund auf stimmig.
Die ganze Mühe kann in Weltgestaltung, Optimierung und Art- Design fließen.

Wir sind da garnicht so weit entfernt von dieser Vorstellung wie viele denken. Man wird, wie bei so vielen Dingen, unter Anderem durch eingeschränkte Denkmuster und die Kompatibilität zu alten Verfahren "zurückgehalten".
Muss man doch immer dafür sorgen, dass der klassische Ansatz eben auf den Karten auch noch funktioniert. Und die Industrie will im Gesamten eben auch noch abgeholt werden, da diese auch nicht alles von heut auf morgen auf den Kopf stellen kann (z.B. deren Engines).
Man sieht ja schon gut an der RTX- Reihe, wie stark ein Henne- Ei Problem ausgeprägt sein kann.

Es gab mal eine Zeit, wo man dieses Dilemma dadurch gelöst hat, indem an spezialisierte Zusatzkarten eingebaut hat (erste 3d- Beschleuniger wie die Voodoos habens vorgemacht).
Diese könnte man dann daraufhin designen nur zu 100% Ray-/Pathtracing zu beschleunigen- Vielleicht sogar mit fixed function Grundauswertungen wie Spiegel, Verschattung etc., was auch nochmal ein erhebliches Beschleunigungspotenzial mit sich brächte.
Die Ergebnisse werden dann jeweils in den Framebuffer der "Hauptkarte" geschrieben und von dort ausgegeben.

Das wäre zumindest ein gangbarer Weg für eine Übergangszeit, bis die Fertigungstechnik so weit fortgeschritten ist, dass es z.B. kein Problem ist, für ein par Euro einen Chip für Rasterisierung noch mit auf die Grafikplatine zu klatschen, der die Leistung einer 3080TI erreicht, um die "alten Schinken" dann auch noch bedienen zu können.

Und- Das ganze muss noch nicht mal teuer werden, weil man die Komplexität auf ein par wenige, immergleiche Standardaufgaben herunterbrechen kann. Optimale Chipletgrößen mit hoher yieldrate wären einsetzbar und und und...

Aber das sind wie immer nur meine 2 cents...

LG
Zero

 

[RRe36]

[Ist etwas lang also dient das hier nur als link]

Deswegen hätte Ich Zusatzkarten welche praktisch nur ASICs zum Beschleunigen von RT enthalten, dann aber auch etwas flexiblere als wir sie aktuell in Turing finden (die Beschränkungen der RT-Einheiten der Turing Chips könnten in der Zukunft durchaus zu interessanten Entwicklungen führen), fast schon für sinnvoller gehalten als diese "Kombi-Chips" die wir momentan haben. Dadurch könnte man die RT Leistung praktisch beliebig skalieren unabhängig von der vorhandenen Leistung für traditionelle rasterized Berechnungen.

 

[PCGH_Torsten]

Womit Du eben genau den Finger auf die Wunde gelegt hast. Rasterisierung hat einfach ein Thema mit Szenenkomplexität, Berechnungstiming und dem "Faken" gewisser Effekte, die eben dann doch wieder ineffektiv mittels stochastischer "bruteforce"- Berechnungen abgehandelt werden müssen.
Deswegen sind selbst moderne Grafikkarten mit der Komplexen Welt einer AAA Produktion locker in die Knie zu zwingen.


Man muss sich von den alten Denkschemata und den Grenzen lösen, die der rasterbasierte Ansatz in die Köpfe geprägt hat.

Bei einem reinen Path- Tracer könnte man nämlich allein schon eine Beschleunigung um den Faktor 4 erreichen, indem man auf eine Platine 4 GPUs steckt, mit einem verschwindend geringen Bruchteil der Nachteile des geringer werdenden Grenznutzens und der Synchronisationsthematik.
Durch den Per- Pixel- Ansatz kannst Du das Bild in beliebig viele Arbeitspakete einteilen (siehe auch Cinebench). Da steckst Du einfach mehr Prozessoren oder Kerne rein und es wird schneller, da pro Kern ein immer kleiner werdendes Arbeitspaket generiert werden kann.
Auch können die Arbeitspakete mit ansteigender Komplexität skalieren. Sind z.B. in einem Arbeitspaket viele für RT Rechenaufwändige diffus- spiegelnde Oberflächen, vorhanden, könnte man dort zusätzliche Worker spawnen bzw. das Paket nochmals unterteilen um den zeitlichen Berechnungsnachteil zu egalisieren.

Paralleler als diese Technik wirds in Sachen Grafik nicht mehr. Da könnte ein Big/Little Prinzip im Multigpu- Ansatz in Sachen Leistung aber -und das ist ein ebenso wichtiger Punkt- auch kosteneffizienz richtige Wunder wirken.
Ein großer Rechenblock für "klassische" Aufgaben, auch für die Steuerung und viele viele kleine, billige Rechenblöcke fürs Ray-/Pathtracing wären denkbar.

Man stelle sich eine zukünftige GPU vor (die von mir oben erwähnten Nachfolger der kommenden Generation), die, wenn man z.B. 4 GPUs auf die Platinen packt, dann die 16- Fache Tracing- leistung einer heutigen 2080TI liefert.
Reicht die Leistung nicht? -> Karte dazustecken, schon gibts die 32- Fache Leistung einer 2080TI.
Enthusiast? -> QUAD SLI hat wieder eine Berechtigung und belohnt einen mit 64- Facher Leistung.
Auch können unterschiedliche GPUs gemischt werden, so dass sich jeder User ganz individuell sein System fast ohne Aufrüstungsgrenzen zusammenstellen könnte.

Mich hindert bislang nicht primär die eingeschränkte Skalierung von Rasterizern daran, sechzehn RTX 2080 Ti in meinem Rechner zu betreiben, sondern der Mangel an Platz, an PCI-Express-Lanes, an Strom, an ausreichender geschweige denn ausreichender unhörbarer Wärmeabfuhr und vor allem an Geld. Ich vermute, dass die gute Skalierbarkeit von Raytraycern einer der Gründe ist, warum Nvidia sich für die Technik einsetzt – aber solange ich Beschleuniger im Wert von 20.000 Euro für gute Grafik brauche, ist es für mich privat keine Option. (Beruflich sieht die Sache anders aus, von daher darf gerne jemand solche Produkte auf den Markt bringen und ich werde Spaß mit ihnen haben. Aber ich glaube da bin ich mit meinem Job ein Sonderfall. )

 

[ZeroZerp]

Und in Minecraft? Ach ja - physikalisch Korrekt Lichtberechnung, da muss nicht mehr getrickst werden den das Visuelle Ergebnis ist bereits richtig - mit AO.

Stimmt- Physikalisch korrekte AO ist ja bei Pathtracing quasi als kostenloses "Abfallprodukt" mit dabei.

dass die gute Skalierbarkeit von Raytraycern einer der Gründe ist, warum Nvidia sich für die Technik einsetzt

Exakt- Die Rasterisierungstechnik ist inzwischen ausgelutscht und man muss muss mit den neuen Engines sowieso immer weiter in Richtug des stochastischen Renderns wandern.

aber solange ich Beschleuniger im Wert von 20.000 Euro für gute Grafik brauche, ist es für mich privat keine Option. (Beruflich sieht die Sache anders aus, von daher darf gerne jemand solche Produkte auf den Markt bringen und ich werde Spaß mit ihnen haben. Aber ich glaube da bin ich mit meinem Job ein Sonderfall. )

Genau darauf gehe ich ja unter anderem in meiner Ausführung ein - Durch den Technologiewechsel wären in Zukunft wieder richtige Leistungssteigerungen zu niedrigeren Fertigungskosten drin. Wir kratzen da gerade noch an der Oberfläche. Ich wollte auch nur veranschaulichen welches Potenzial die neue Technik birgt. Auch in Sachen Beschleunigung und Preis.
Auch wenn die erste Generation eben was anderes vermuten lässt...

LG
Zero

 

[ZeroZerp]

Zu meiner wiederkehrenden Kritik am Atmospheric scattering, übertriebenen god- ray Einsatz der RTX- Version.
Ich kannte mich mit dem Minecraft- Zeugs einfach nicht genügend aus.

Da sind diverse Parameter anpassbar - Mit dem command "raytracefog". Da kann man alles nach seinen Bedürfnissen anpassen und danach sieht es auch "stimmig" aus.
Das wird in Zukunft wohl auch über das Menü einstellbar sein.

My bad.

LG
Zero

 

[PCGH_Torsten]

?? Tesselation ist die Stufe NACH dem Vertex-Shader (Die Stufe die nach dem eigentlichen Shading am meisten Leistung benötigt), culling ist da schon längst vorbei.

?? Wie kommst du auf sowas? Sollen wir dann auch noch Textur-LoD auf die CPU auslagern damits erst recht irrsinnig lange dauert?

*facepalm*
Sorry, habe Vertex- und Geometrie-Shader verwechselt.

Wenn wir Rechenzeit sparen und uns nicht um Latenzen sorgen: Ja. In der Praxis ist die Bestimmung der optimalen Texturauflösung aber lächerlich einfach und die Häufigkeit, mit der sie erfolgen muss, macht eine Auslagerung praktisch unmöglich. Aber es würde die GPU-Last reduzieren. Und bei Geometrie entfällt das Latenzproblem eben, denn Geometriedaten hat die CPU, im Gegensatz zu Texturdaten, lange vor der GPU alle einmal verarbeitet.

Stimmt- Physikalisch korrekte AO ist ja bei Pathtracing quasi als kostenloses "Abfallprodukt" mit dabei.


Exakt- Die Rasterisierungstechnik ist inzwischen ausgelutscht und man muss muss mit den neuen Engines sowieso immer weiter in Richtug des stochastischen Renderns wandern.


Genau darauf gehe ich ja unter anderem in meiner Ausführung ein - Durch den Technologiewechsel wären in Zukunft wieder richtige Leistungssteigerungen zu niedrigeren Fertigungskosten drin. Wir kratzen da gerade noch an der Oberfläche. Ich wollte auch nur veranschaulichen welches Potenzial die neue Technik birgt. Auch in Sachen Beschleunigung und Preis.
Auch wenn die erste Generation eben was anderes vermuten lässt...

LG
Zero

Ich weise ausdrücklich daraufhin, dass in meinem Kommentar "vorerst" nutzlos steht.
Potenzial hat Raytraycing auf dem Weg zum Fotorealismus definitiv, nicht umsonst hat es beim Nicht-Echtzeit-Rendering meinem Wissen nach einen Anteil von 100 Prozent. Irgendwann wird der Rechenaufwand, der bei Rasterizern für die Fehlervermeidung nötig ist, größer als der Aufwand für eine physikalisch korrekte Berechnung. Die Frage ist: Wann?

Minecraft ist auch in der RTX-Fassung wirklich keine Referenz für beste Grafikpracht, frisst aber Grafikkarten zum Frühstück und muss massiv mit temporaler Nachbesserung arbeiten, die zu offensichtlicheren Artefakten führt als die Tricks aktueller Rasterizer. Ich würde schätzen, dass es mindestens den Leistungszuwachs von 3 Grafikkartengenerationen braucht, um ganz auf diese Trickserei zu verzichten und reines Raytraycing zu betreiben, anstatt auf Basis von (nur) Raytraycing ein Bild zu interpolieren und weitere 2 Generationen, um den reinen Performance-Vorsprung heutiger Rasterizer einzuholen. Da selbige aber "nur" exponentiell für weitere Qualitätsverbesserungen zahlen und nicht komplett stillstehen, muss man dieses Spiel dann noch einige weitere Jahre fortsetzen, ehe reine Raytraycer tatsächlich in Qualität und Performance an reinen Rasterizern vorbeiziehen. Es ist also klar die Technik der Zukunft – aber eher der Zukunft "2030", nicht der Zukunft "2021". Ich warte den Break Even nicht mehr in dieser Hälfte des Jahrzehnts.

Auf der aktuellen oder auch der kommenden Generation reicht es eben nur für Minecraft mit Artefakten oder Quake II ohne Artefakte. Diese Grafikqualität mit Rasterizern zu vergleichen ist schwierig, man hat simpelste Inhalte mit perfekter Ausleuchtung, aber zumindest ich würde Half Life 2 hübscher finden als Quake II RTX. Und ersteres dürfte auf einer X1800XT ähnlich gut laufen, wie letzteres auf einer RTX 2080. Das ist die Hardware-Entwicklungslücke, die Raytraycer schließen müssen, ehe ich die Technik für etwas anderes als ein paar Sonderfälle gut heiße. Bei gewölbten Spiegelungen, komplexen Brechungen und mehrfach Spiegelungen hat die Technik schon heute Vorteile, aber sowas ist nur bei wenigen Spielinhalten ein Level-Hauptbestandteil.

 

[ZeroZerp]

Ich weise ausdrücklich daraufhin, dass in meinem Kommentar "vorerst" nutzlos steht.

Der "Nutzen" einer höherwertigen/korrekteren Grafik ist immer diskussionswürdig und sehr subjektiv.

Es geht ja letztenendes nur drum, dass es tatsächlich genug Menschen gibt, die bereits jetzt ihre Freude daran haben und das ganze als spielbar betrachten. Die youtube Kanäle sind voll von begeisterten Usern.
Insofern gibt es bereits einen "Nutzen", der vielleicht aber dem ein oder anderen nicht hoch genug erscheint.

Diese Grafikqualität mit Rasterizern zu vergleichen ist schwierig, man hat simpelste Inhalte mit perfekter Ausleuchtung,

Zudem- Der einfache Art- Style täuuscht

Ich zitiere:

Minecraft renders on Far about 5000 mini-chunks (16x16x16) from which up to 1300 may be visible in the frame. Each mini-chunk has about 6000 visible vertices on average.
This gives 8 million vertices or about 2 million polygons per frame. When running with 30 FPS this corresponds to 60 million polygons per second. This is a very approximate calculation just to get an idea of the work that the GPU has to do.

Details:
The world consists of chunks with dimensions 16x16x128 blocks.
Every chunk gets divided vertically in 8 mini-chunks with dimensions 16x16x16 which get rendered separately (WorldRenderer). The "chunk" numbers in the debug screen are in fact mini-chunk numbers.
The Far render distance has view distance (forward) 256 blocks or 16 chunks. The world on Far has (2 x 16) x (2 x 16) = 32 x 32 = 1024 chunks.
1024 chunks = 1024 * 8 = 8192 mini-chunks. Minecraft limits the mini-chunks on Far to 5400 to limit the GPU load.
After frustum culling about 1/4 of the 5400 mini-chunks are left = 1300 mini-chunks.

Somit mag zwar die Grafik "einfach" wirken, erreicht aber die Komplexität eines modernen AAA Titels. Wenn man sich also diese Szenenkomplexität erlauben würde und die Assets und das Textureset entsprechend ändert, dann könnte auch ein heutiger AAA Titel schon spielbar gepathtraced werden und würde dementsprechend besser aussehen.

LG
Zero

p.S. Die Artefaktbildung ist ein "known" Issue- Und es wird zur finalen Version verbessert. Nie- Vergessen:Es ist eine erste Beta.

 

[RRe36]

Das ist dann der Style den sie haben wollen - muss einem nicht gefallen, ich finde sie auch nicht wirklich gut so. Die Strahlen sind physikalisch korrekt, das shading der Ergebnisse unterliegt aber nach wie vor den Einstellungen, den Texturen und den Shadern des Spiels.

Ahh Ich glaube Ich versteh jetzt wie du das mit "physikalisch korrekt" früher hier im Thread meinst. Du meintest wohl wenn man die Lichtinteraktion an sich betrachtet und mal alle Koeffizienten usw. außen vor lässt. Dann macht das natürlich Sinn, Ich bezieh da die "Umgebungsvariablen" immer mit ein, also Koeffizienten für Scattering und Extinction bzw. das simulierte volumetrische Medium da diese ja maßgeblich bestimmen wie das Endergebnis aussieht und es auch da physikalsch korrekte Koeffizienten gibt die man mit Tools für die genutzten Wellenlängen des Lichtes errechnen kann.

EDIT: Ich finde ich sollte da noch etwas Hintergrundwissen dazu geben.
Man kann volumetrischen Nebel inkl. Lichtinteraktion in mehrere Komponenten runterbrechen.
Da hätte man dann einmal die konstanten Koeffizienten die schlichtweg vorgeben welche Art von Medium simuliert werden soll. Diese sind maßgeblich dafür verantwortlich wie das Endresultat aussieht da durch diese Koeffizienten in einfachen Worten die "Farbe" des gestreuten Lichtes als auch die wellenlängenabhängige Extinction (im Prinizp die Sichtbarkeit von Objekten hinter dem Nebel) simuliert wird.
Damit sind wir dann schon bei der nächsten "Komponente", was das Scattering bzw. zu deutsch die Streuung wäre. Diese wird bei Nebel in der Regel in Mie-Scattering und Rayleigh-Scattering unterteilt (wobei letzteres in dem RTX Patch nicht vorhanden zu sein scheint wie Ich schon in einem vorherigen Post erwähnt hatte). Mie Scattering ist dabei im Prinzip das was in Nebel passiert, also weitestgehend Wellenlängenunabhängige Streuung während Rayleigh-Scattering stark von der Wellenlänge abhängt und auch bestimmte Wellenlängen stärker streuut oder absorbiert. Rayleigh Scattering ist z.B. auch der Grund warum unser Himmel blau und nicht weiß ist und ist oftmals auch in Form eines leichten bläulichen Nebels über große Distanzen bei klarer Luft sichtbar.
Dann gibt es noch die Lichtinteraktion an sich, was oftmals einfach eine Shadowmap ist die innerhalb des Raymarching Loops ausgelesen wird um festzulegen ob die aktuelle Position beleuchtet ist oder nicht. Es gibt auch noch den Ansatz mit Light-Propagation-Volumes welchen Ich hier aber aufgrund der geringeren Verbreitung nicht ausführen werde.
Zu guter letzt gibt es noch die Dichtefunktionen für das volumetrische Medium, das kann von simplen höhenbasierten Gradienten bis zu komplexeren Funktionen welche lokalisierte "Wölkchen" an Nebel simulieren reichen.

Das Ganze wird i.d.R. grob wie folgt kombiniert:
- Als erstes werden die Koeffizienten festgelegt, dies geschieht außerhalb des Raymarching Loops da diese Koeffizienten bis auf wenige Außnahmen konstant sind.
- Dann wird auf Basis von z.B. einer Shadowmap festgelegt ob die aktuelle Position des Loops beleuchtet ist. (Für das Rayleigh-Scattering wird im Idealfall auch die Sichtbarkeit des Himmels an aktueller Position geprüft)
- Die Dichte des Mediums an der aktuellen Position wird bestimmt.
- Dieser Wert wird dann mit den Scattering-Koeffizienten sowie der Beleuchtungsintensität "kombiniert" und anhand der Sichtbarkeit der aktuellen Position zum Gesamt-Scattering hinzugefügt (das ist das resultierende Scattering was am Ende auf die Szene addiert wird).
- Anhand der Dichte und der Extinction-Koeffizienten wird berechnet wie stark die dahinterliegenden Objekte sichtbar sind. Dies wird auf die Gesamt-Extinction (oder oftmals auch Transmittance) angewendet.
- Zum Schluss wird die Ausgangsfarbe der Szene mit der Gesamt-Extinction multipliziert und das Gesamt-Scattering addiert.

Ist jetzt alles wieder etwas vereinfacht aber Ich denke jetzt kann man erkennen das es etwas ungünstig ist einzelne Komponenten davon (z.B. die Lichtinteraktion) zu betrachten da alles recht eng zusammen hängt. Deswegen wird dies auch relativ selten gemacht und stattdessen das Gesamtpaket betrachtet da eine korrekte Lichtinteraktion kein Garant für ein insgesamt physikalisch korrektes Resultat ist, insbesondere da es bestimme Regeln zu beachten gibt wenn man z.B. die Koeffizienten festlegt da man ansonsten Situationen wie extrem intensives Scattering aber sehr wenig Extinction hat wie man es im RTX Patch betrachten kann. Insofern mag die Lichtinteraktion korrekt sein (wäre auch eigenartig wenn ausgerechnet das zu kurz kommt) aber wie Ich schon oben gesagt hatte sind die "Umgebungsvariablen" nicht korrekt weswegen das Gesamtpaket per Definition nicht physikalisch korrekt ist.

Für Interessierte hier noch ein Paar weiterführende Wikipedia-Artikel:
Luftperspektive – Wikipedia
Rayleigh-Streuung – Wikipedia
Mie-Streuung – Wikipedia
Tyndall-Effekt – Wikipedia

 

[PCGH_Torsten]

Somit mag zwar die Grafik "einfach" wirken, erreicht aber die Komplexität eines modernen AAA Titels. Wenn man sich also diese Szenenkomplexität erlauben würde und die Assets und das Textureset entsprechend ändert, dann könnte auch ein heutiger AAA Titel schon spielbar gepathtraced werden und würde dementsprechend besser aussehen.

LG
Zero

p.S. Die Artefaktbildung ist ein "known" Issue- Und es wird zur finalen Version verbessert. Nie- Vergessen:Es ist eine erste Beta.

Na dann warte ich mal die Gold-Fassung ab, ehe ich mich wieder nach einer Meinung zum Thema fragen lasse. Bislang haben mit temporale Cheats nur selten überzeugt, daher sehe ich viele der Artefakt nicht als Bug, sondern als unvermeidbare Konsequenz der Strahleneinsparung.

Sollten im Moment tatsächlich im Schnitt 1.500 Polygone pro Block gezeichnet werden, dann ist die Leistungsfähigkeit der Engine in der Tat beeindruckend. Ich hätte für die meisten Blöcke ziemlich exakt ein Fünfhundertstel dieses Wertes erwartet: Einen texturierten Würfel, von dem drei Seiten sichtbar sind. So gesehen ist es aber extrem beeindruckend, was der Rasterizer an Durchsatz stemmt (und peinlich, wie schlecht das LOD arbeitet ); wir reden hier immerhin von im Schnitt einem Polygon pro Pixel. Da kann man nicht nur über Raytraycer nachdenken, die pro Pixel statt pro Polygon skalieren, sondern direkt auf Voxel wechseln.

 

[ZeroZerp]

@pcgh_torsten
Ich hab gestern mal versucht ein Profiling von "typischen" Szenen bei Minecraft zu machen und in der Tiefe zu analysieren, was tatsächlich durch die Engine geschleust wird.
UWP macht da einen Strich durch die Rechnung- Ich krieg zwar übers visual studio debuging nen hook hin, allerdings crasht mir das System, sobald ich in die Frameaufschlüsselung gehe. Egal in welchem Modus

Hab jetzt mal nvidia angehauen. Vielleicht können die helfen und vielleicht sind wir dann alle schlauer
Dann kann man das sicherlich noch besser bewerten, was da Sache ist.

So ein texturierter Würfel sollte, wenn sie nicht völlig dämlich sind eigentlich nur aus 12 Dreiecken bestehen, esseidenn es würde tesseliert (hab noch kein wireframe dazu gesehen). Somit sollte ein Mini- Chunk ohne Tesselation im blödesten Falle 49.152 Dreiecke haben.
Blöd beim Pathtracing ist halt auch immer das Culling. Gerade wenn da noch wie im Dschungel- Level Transparenz mit im Spiel ist. Da hast Du dann ja teilweise rückwärtiges Scattering, Spiegelungen und co.
Das ist das höllische an dem System, dass es eine hohe Wahrscheinlichkeit gibt, dass es doch von ziemlich vielen Seiten etwas zu berechnen gibt....

LG
Zero

 

[PCGH_Torsten]

Eigentlich ist effektives Culling von Rückseiten eine Stärke von Raytraycern, da aufwendigere Berechnungen überhaupt erst durchgeführt werden, wenn eine indirekte oder direkte Sichtverbindung zu der Oberfläche gefunden wurde.

 

[ZeroZerp]

...was nichts daran ändert, dass z.B. durch Bounces Radiosity auf Flächen hinter einem in Rasterszenarien unsichtbaren Backfaces projeziert werden, wie es z.B. bei Minecraft passiert.
Und ab da fällt halt ziemlich viel durchs Raster, was dann tatsächlich noch geculled werden könnte.

Solch ein "unangenehmes" Szenario siehst Du in meinem "Zerpflückungsszenario" unter Punkt 11 (Video ab ca. 3:30):
Minecraft RTX... - Das sagen die PCGH-Redakteure dazu

Da siehst Du, dass die Farbgebung des Rückwärtigen Raumes (der in "normalen" Szenarien außerhalb des Viewports liegt und geculled würde), in Minecraft noch in die Projektionsmatrix bzw. Viewport reinspielt.

LG
Zero

 

[PCGH_Torsten]

Dabei sollten aber eben nicht, wie es ein Rasterizer machen müsste, ganze Flächen, sondern nur einzelne Trefferpunkte sekundärer/tertiärer Strahlen berechnet werden. Ein Aufwand der sich letzten Endes nicht von einem Sekundärtreffer im sichtbaren Bereich unterscheidet und bei dem sparsamen Einsatz von Strahlen in Minecraft RTX kann auch nur eine begrenzte Zahl zusätzlicher Polygone insgesamt getroffen werden.

 

[ZeroZerp]

Dabei sollten aber eben nicht, wie es ein Rasterizer machen müsste, ganze Flächen, sondern nur einzelne Trefferpunkte sekundärer/tertiärer Strahlen berechnet werden. Ein Aufwand der sich letzten Endes nicht von einem Sekundärtreffer im sichtbaren Bereich unterscheidet und bei dem sparsamen Einsatz von Strahlen in Minecraft RTX kann auch nur eine begrenzte Zahl zusätzlicher Polygone insgesamt getroffen werden.

Verstehe, was Du meinst.

Was bei Minecraft diesbezüglich Vorteil und Nachteil zugleich ist, ist, dass ja erstmal die ganze Szenerie beschossen wird. Insofern hast Du natürlich recht, dass man durch die Primärstrahlen schon sehr viele Informationen erhält, wo/ob da noch irgendwas weiterverfolgt werden muss oder gleich im Nirvana oder der Farbwertschwelle/Schatten verschwindet und die Genauigkeit diverser Rechenschritte mit fortschreitenden Bounces nachlassen kann.
Eine Art "natürliches" LOD.

Ich vergess immer wieder, dass Minecraft kein klassischer Hybrid mehr ist. Was mich aber auch gleichzeitig immer wieder erneut staunen lässt....

LG
Zero