SIR_Thomas_TMC
Freizeitschrauber(in)
Schau mal, was im Zitat in meinem Post (den du zitiert hast) steht.
Special Half-Life mit Pathtracing getestet: Eine unglaubliche Verwandlung des 1998er-Meilensteins
- Ersteller PCGH-Redaktion
- Erstellt am
owned139
BIOS-Overclocker(in)
Naja, in deinem Video wirft das Licht absolut null Schatten. Flächen die nicht vom Licht getroffen werden, sind einfach nur Dunkel, aber Bögen, Mauerwerke und Tafeln werfen 0 Schatten.
Rizzard
PCGH-Community-Veteran(in)
Sieht zwar deutlich atmosphärischer und realistischer aus, aber insgesamt wirkt es dadurch auch an vielen Stellen zu dunkel. Also mir persönlich wäre das Spiel so zu dunkel gewesen.
Ist zwar immer schön und gut wenn Licht und Schatten korrekt dargestellt werden, aber in solchen Fällen müssen dann eben mehr Lichtquellen hingestellt werden, damit es am Ende nicht einfach nur sehr dunkel ist.
Ist zwar immer schön und gut wenn Licht und Schatten korrekt dargestellt werden, aber in solchen Fällen müssen dann eben mehr Lichtquellen hingestellt werden, damit es am Ende nicht einfach nur sehr dunkel ist.
Eiegentlich hätten Sie mit RX7000 schon deutlich näher an NVidia in Punkto Raytracing aufschließen müssen. 1,5 bis 2 Jahre bis zur nähsten Gen damit zu warten ist im Prinzip schon zu spät. Ich würde mir jedenfalls heute keine RT-Krücke mehr anschaffen, da kann die reine Rasterleistung noch so gut sein. Die meisten großen Produktionen unterstützen RT heute bereits, teilweise mit deutlichen grafischen Verbesserungen.
Ich mag Planar Reflections auch - fast alles ist besser als diese volatile Screen-Space-Seuche -, allerdings sind sie kein Allheilmittel. Planar Reflections funktionieren, der Name sagt's schon, nur auf ebenen Flächen gut, also beispielsweise zur Wasserdarstellung oder für Wandspiegel. Aber was machst du, wenn dein Spiegel eine Krümmung hat, deine Fahrbahn wellig ist, auf Karosserien, Bad-Armaturen, dem Helm-Beispiel usw.? Das wird sehr fummelig oder ist unmöglich. Außerdem gibt es einen Punkt der Komplexität, wo das doppelte Rendern der Szene teurer wird als selektives Raytracing für Reflexionen. Man kann nicht jede Mini-Spiegelfläche mit Planars zukleistern.
Davon ab ist Ray- bzw. Pathtracing eben viel, viel mehr als Reflexionen, auch wenn das gerne auf diesen gut sichtbaren Effekt reduziert wird. Wie genau simulierst du Refraktionen in milchigem oder brüchigem Glas? Gar nicht.
MfG
Raff
Lichtbrechung geht über Shader recht gut; auch in Kombination mit teiltransparenten Oberflächen. Ich glaube die Wasseroberfläche in Far Cry hat als erstes beides berücksichtigt. Natürlich gilt auch hier, ähnlich wie für Reflektionen: Rasterizer-Tricks skalieren sehr schlecht mit der Zahl der Effekte und gehen von vereinfachten Annahmen aus. Die treffen auf viele Spielsituationen zu und solange du eine Fläche hast, die einmal bricht/reflektiert eine Lichtquelle, die einen direkten Schatten wirft, bekommt man mit einer Technik, die bestimmte Aspekte für den ganzen Bildschirm abstrahiert, eine viel bessere Performance respektive bei gleichen Fps die bessere Bildqualität. Wenn dagegen dutzende kleiner Spiegel durch Linsen hinweg sich überlagernde Mehrfachschatten von multiplen indirekt-gestreuten Lichtquellen darstellen sollen, bekommt man ein Problem. Schon allein deswegen weil z.B. eine Planar Reflection, die in einer Planar Reflection sichtbar ist zwei komplette aufeinander folgende Renderdurchgänge benötigt, die hinterher auch noch kombiniert werden müsen. (Vergl. Portal ohne RTX.)
Pixelbasiertes Vorgehen wie bei Raytraycing ist in einem derart komplexen Szenario effizienter – es gibt quasi keinen Overhead und wenn am Ende sowieso jedes Pixel einen anderen Renderpfad als sein Nachbar erfordert, kann ein Rasterizer keine Detailschritte einsparen, ohne an Qualität einzubüßen. So ähnlich wie Voxel effizienter als Polygone sind, sobald man ein 9-Koordinaten-Polygon statt eines 3-Koordinaten-Voxel pro Pixel berechnen müsste. Aber hier wie dort stellt sich die Frage, wo genau der Break-Even liegt und ob man ihn mit aktueller Hardware überhaupt erreichen kann?
Bislang wird Raytraycing +überwiegend für einen Teil der direkten Beleuchtung und für deutlich zu sehende Reflektionen in Spiegeln und auf Pfützen genutzt. Das heißt als Ersatz für Stencil-Schatten und für Planar Reflections. Die Zahl der Spiegel ist dabei schon durch sinnvolles Leveldesign ziemlich begrenzt und die Zahl der berücksichtigten Lichtquellen scheint mir oft so niedrig zu sein, dass man fast schon an Doom 3 erinnert wird. Mit jeweils dutzenden wäre ein Rasterizer sicherlich überfordert, aber aktuelle GPUs scheinbar auch.
Beide Begriffe scheinen recht willkürlich verwendet zu werden, aber in der reinen Lehre wären beide identisch. Spätestens seitdem Nvidia alles mit einem Hauch von Zusatzeffekt als "RTX" brandmarkt steht Pathtraycing daher tendenziell für 100 Prozent Raytraycing. Das heißt also es wird für jedes Pixel der komplette Weg von der Betrachterkamera bis zu einer Lichtquelle zurückverfolgt. "Raytraycing" wäre es dagegen formell auch schon, wenn man nur Primärstrahlen auf eine statisch mit Lightmaps erhellte Szene feuern würde. Allerdings beinhaltet auch "Pathtraycing" in aller Regel keine unbegrenzte Anzahl an Folgestrahlen, die beispielsweise bei "Endlosspiegeln" näherungsweise ins unendlich gehen würden und somit unberechenbar wäre. Ebenso gibt es keinen Konsens darüber, wie viel "Echtzeit" denn in "Echtzeit Pathtraycing" stecken muss. In Raffs Video sieht man zum Beispiel an 1-2 Stellen, wie Beleuchtungsdetails nachträglich eingezeichnet werden. Das heißt hier wird bereits über eine ganze Reihe von Frames hinweg temporal integriert, weil die Performance nicht ausreicht um alles in einem Renderdurchgang/ohne Rückgriff auf vorgerenderte Informationen aus älteren Frames darzustellen. Komplett offen bleibt die Frage nach der indirekten Beleuchtung und deren Genauigkeit. Das ist die eigentliche Achillesferse von Raytraycern (Rasterizer liefern allgemein Grütze ab, das aber flott):
Nimmt man die Winkelauflösung eines UHD-Bildes als Grundlage und verlangt, dass für jede Oberfläche im Spiel zumindest mit 1 Prozent dieser Genauigkeit geprüft wird, ob eine indirekte Beleuchtung vorliegt, würde das allein pro Primärstrahl, der auf eine matte Oberfläche trifft (in HL ist praktisch alles matt) knapp 94000 Sekundärstrahlen erfordern. (Und jeder einzelne dieser Sekundärstrahlen erfordert dann seinerseits so viele Tertiärstrahlen, wie es Lichtquellen gibt – in Gegenwart leuchtender Schnellfeuermunition also gegebenenfalls hunderte.) Um in dieser Qualität gemäß der Naturgesetze realistisch zu Rendern, also das Raytaycing-Versprechen vollumfänglich umzusetzen*, bräuchte man Petarays/s, aktuelle Grafikkarten liegen aber noch im unteren GR/s-Bereich.
*: Das heißt in der Natur gibt es natürlich auch doppelt indirekte Beleuchtungen. Zum Beispiel wenn die Sonne eine weiße Wand anstrahlt, deren Licht auf einen Holzschrank fällt und dann dafür sorgt, dass der Boden vor dem Schrank nicht reinweiß beleuchtet ist. Wollte man das auch in besagter Genauigkeit berechnen (was sicherlich übertrieben ist), würde sich die Rechenlast erneut mit knapp 100.000 multiplizieren und vermutlich die Leistung sämtlicher bis heute gefertigter GPUs übersteigen.
Zuletzt bearbeitet:
Downsampler
BIOS-Overclocker(in)
Aber doch nicht mit 20 FPS für über 1000 Euro. xDDer Punkt ist: Wenn du mit Raster-Fakes wirklich alles nachstellen möchtest, was sich durch Raytracing automatisch ergibt, passiert das Folgende:
- Es wird noch schlechter laufen,
- Es wird trotzdem nicht alles imitieren können.
Je komplexer und dynamischer das ist, was du darstellen willst, desto eher fällt dir das Rasterizing auf die Füße. Es führt kein Weg an Raytracing vorbei. Die Herangehensweise mit dem "Lalala, ich finde alles hübsch, wenn ich ein bis zwei Augen zukneife" hat jetzt 30 Jahre funktioniert - Zeit für die nächste Stufe.
MfG
Raff
reihner_zu_fall
Komplett-PC-Aufrüster(in)
Ob es wohl bald auch einen Half-Life2-RT-Mod geben wird? Einige der Gruselabschnitte , z.B. Ravenholm oder der Tunnel mit den Autowracks, stelle ich mir da richtig übel vor.
.gif "sm_=) =)")
Unter Windows bestimmt. Könnte mir vorstellen, dass es mit viel FSR 2 sogar läuft.
wurstkuchen
BIOS-Overclocker(in)
"Eine unglaubliche Verwandlung" ... ist das ernst gemeint? es sieht 1zu1 identisch aus mit und ohne RT.
JoM79
Trockeneisprofi (m/w)
Netter Versuch.
Danke für die aufschlussreichen Erklärungen.
SIR_Thomas_TMC
Freizeitschrauber(in)
Wird dann eigentlich jede Oberfläche (pixelgenau) in jede Richtung (Winkelkonus) berechnet? Das lässt sich doch kaum vernünftig berechnen.
Was ist z. B. mit verdeckten Lichtquellen?
Oder wird doch von Lichtquellen ausgehend berechnet?
Außerdem steigt ja mit jeder Quelle der Aufwand...
?
Siehe den Rest meines Beitrags.
Ohne indirekte Beleuchtung kann man noch gut vereinfachen: Trifft ein Primärstrahl von der Kamera kommend auf eine matte Oberfläche, feuert man von diesem Endpunkt je einen Sekundärstrahl zu jeder Lichtquelle. Ist die Lichtquelle aus Perspektive des Endpunkts verdeckt, wird ihr Sekundärstrahl vorher abgefangen, das heißt der Endpunkt bleibt dunkel. Erreicht der Sekundärstrahl die Lichtquelle, ist der Endpunkt beleuchtet. Durch Kombination aller Lichtquellen hat man auch Halb- und Mehrfachschatten sauber mit drin und aktuelle Grafikkarten könnten problemlos für jeden Primärstrahl ein ettliche Dutzend bis einige hundert Sekundärstrahlen pro Frame bearbeiten, also entsprechend viele Lichtquellen prüfen. Auch wenn Spiegelungen oder Lichtbrechungen in diesen Strahlengängen hinzukommen, ist das kein großes Problem, denn die generieren pro eingehenden Strahl nur einen ausgehenden in einer anderen Richtung.
Aber bei indirekter Beleuchtung, wenn also Licht über den Umweg zweier streuender Flächen in die Betrachterkamera fällt, steht man genau vor dem von dir (und mir) geschilderten Problem: Eigentlich müsste man von jeder Fläche in alle Richtungen unendlich fein prüfen, ob sie Blickkontakt zu irgend einer anderen Fläche hat, von der aus man dann wiederum nach direkten Lichtquellen Ausschau halten könnte. But infinity doesn't compute. Selbst die von mir oben angesetzten Genauigkeit, ich glaube es waren so ein Strahl pro 10 bis 15 Bogenminuten, ist auf heutiger Hardware unmöglich.
Wie Engines und Treiber damit umgehen, schwankt stark. Ein simpler Raytraycer lässt indirekte Beleuchtung einfach ganz weg oder stellt die Auswirkungen an wichtigen Stellen über "direkte" Fake-Lichtquellen nach. Der Rest muss einen noch spielbaren Kompromiss zwischen temporaler Integration und einer stark reduzierten räumlichen Genauigkeit nebst Reichweite finden. In einfachen Leveln in denen nur sehr wenige Lichtquellen existiert wäre auch eine physikalisch korrekte Berechnung ausgehend von der Lichtquelle möglich, welche vergleichsweise schnell die Bereiche ermittelt, welche als sekundäre/indirekte Lichtquelle in Frage kommen (de facto eine präzise Echtzeit-Lightmap). Aber ich weiß nicht, ob das in der Praxis eingesetzt wird, denn dabei werden auch für den Spieler gar nicht sichtbare Geometrie und Lichtquellen berücksichtigt werden, was meist die noch ineffizientere Herangehensweise ist.
So oder so: Bis wir Licht physikalisch korrekt durch einen Türspalt hindurch schimmern sehen, werden noch einige GPU-Generationen kommen und gehen.
Ohne indirekte Beleuchtung kann man noch gut vereinfachen: Trifft ein Primärstrahl von der Kamera kommend auf eine matte Oberfläche, feuert man von diesem Endpunkt je einen Sekundärstrahl zu jeder Lichtquelle. Ist die Lichtquelle aus Perspektive des Endpunkts verdeckt, wird ihr Sekundärstrahl vorher abgefangen, das heißt der Endpunkt bleibt dunkel. Erreicht der Sekundärstrahl die Lichtquelle, ist der Endpunkt beleuchtet. Durch Kombination aller Lichtquellen hat man auch Halb- und Mehrfachschatten sauber mit drin und aktuelle Grafikkarten könnten problemlos für jeden Primärstrahl ein ettliche Dutzend bis einige hundert Sekundärstrahlen pro Frame bearbeiten, also entsprechend viele Lichtquellen prüfen. Auch wenn Spiegelungen oder Lichtbrechungen in diesen Strahlengängen hinzukommen, ist das kein großes Problem, denn die generieren pro eingehenden Strahl nur einen ausgehenden in einer anderen Richtung.
Aber bei indirekter Beleuchtung, wenn also Licht über den Umweg zweier streuender Flächen in die Betrachterkamera fällt, steht man genau vor dem von dir (und mir) geschilderten Problem: Eigentlich müsste man von jeder Fläche in alle Richtungen unendlich fein prüfen, ob sie Blickkontakt zu irgend einer anderen Fläche hat, von der aus man dann wiederum nach direkten Lichtquellen Ausschau halten könnte. But infinity doesn't compute. Selbst die von mir oben angesetzten Genauigkeit, ich glaube es waren so ein Strahl pro 10 bis 15 Bogenminuten, ist auf heutiger Hardware unmöglich.
Wie Engines und Treiber damit umgehen, schwankt stark. Ein simpler Raytraycer lässt indirekte Beleuchtung einfach ganz weg oder stellt die Auswirkungen an wichtigen Stellen über "direkte" Fake-Lichtquellen nach. Der Rest muss einen noch spielbaren Kompromiss zwischen temporaler Integration und einer stark reduzierten räumlichen Genauigkeit nebst Reichweite finden. In einfachen Leveln in denen nur sehr wenige Lichtquellen existiert wäre auch eine physikalisch korrekte Berechnung ausgehend von der Lichtquelle möglich, welche vergleichsweise schnell die Bereiche ermittelt, welche als sekundäre/indirekte Lichtquelle in Frage kommen (de facto eine präzise Echtzeit-Lightmap). Aber ich weiß nicht, ob das in der Praxis eingesetzt wird, denn dabei werden auch für den Spieler gar nicht sichtbare Geometrie und Lichtquellen berücksichtigt werden, was meist die noch ineffizientere Herangehensweise ist.
So oder so: Bis wir Licht physikalisch korrekt durch einen Türspalt hindurch schimmern sehen, werden noch einige GPU-Generationen kommen und gehen.
Frank-Langweiler
Software-Overclocker(in)
?
Bevor ich die 3dfx hatte musste ich das sogar im Softwarerenderer spielen und trotzdem hat es mir einen Riesenspaß gemacht.
Zuletzt bearbeitet:
Frank-Langweiler
Software-Overclocker(in)
Soweit ich mich erinnere, sah HalfLife 1998 schon genauso aus. Möglicherweise ist die Vanillaversion über die Jahre/Betriebsysteme einfach nur verblichen und die Mod holt den alten Windows 98 SE-Look wieder hervor.
Ähnliche Themen
