News Nvidia zeigt Raytracing auf der GPU

Meine Meinung Koskesh.
- Korrekte Reflektionen und Brechungen sind für typische Spieleszenen eher unwichtig, da tuts auch die Cubemap.
- Lieber an echtzeitfähigen Soft-Shadows weiterforschen, dass fällt viel mehr auf. Eben weil man es nicht vollständig korrekt rechnen kann(in Echtzeit), kann man die bestehenden "Fakes" weiter verbessern.
 
Dann erkläre mir warum.

Mit einem "Geht nicht! Basta!" gebe ich mich nicht zufrieden.
 
Also meiner meinung nach hat das mit glaubenskrieg genau garnix zu tun. Raytracing ist besser - da gibts absolut keine zweifel. Es gibt keine effekte die rasterisierung darstellen könnte die es in Raytracing nicht schon seit über 15 jahren gibt. Einige ungelöste probleme der rasterisierung gibt es beim raytracen schon seit 30 jahren nicht mehr. Jetzt kommen alle "aber raytracing ist langsamer" bisland mag das noch stimmen - aber rasterisierung hat eine asymptotische Laufzeit von O(n) - Raytracing läuft in O(log(n)) also um VIELES schneller (ab einem gewissen punkt).

Der Punkt ist meiner meinung nach schon überschritten - allerdings existiert die hardware noch nicht für raytracing optimiert - sonst hätten wir schon sei 1-2 jahren beinahe fotorealismus. Und dass die bilder da noch nicht so atemberaubend sind lieg genau daran - dann die technologie nicht dafür abgestimmt wurde. Es wäre besser superskalare karten zu verwenden mit so - 4096rechneneinheiten zu je 90mhz. Ich denke damit würde das ganze locker lässig flüssig laufen - ziemlich egal welche detaills man einbaut. Die einzige limitation ist dann die rekursionstiefe der reflexionen - bzw photon/diffuse lightning...damit kann man jede rechenmaschiene in die knie zwingen...was aber auch den vorteil haben könnte dass ältere spiele in zukunft auf neueren Systemen deutlich besser ausschauen = )
 
silent-efficiency schrieb:
@e-Laurin
Das mit dem logarithmischen und der mathematischen Beweisführung gilt nur für Stationäre Bilder. Wenn sich alles bewegt gilt das mit dem logarithmischen verhalten einfach nicht!

Also das kannst du mir jetzt bitte erklären warum das so ein soll. Wenn ich ein bild Rendern kann und es hat logarithmische laufzeit - dann kann ich mehrere verschiedene bilder (bewegung) genauso in logarithmischer laufzeit berechnen. Das ist ganz einfach logik. Dass die berechnung der bewegung rechenzeit braucht ist klar - aber die braucht es beim Rasterisieren genauso.

Ich glaube dass sich das so entwickeln wird - Über die schnitstellen der GPUs werden die leute von OpenRT eine libary entwickeln die nichtmehr die CPU sondern eben die Grafikkarte nutzt - dann kommen erste opensource spiele dazu raus (und wenn es nur ein billiges autorennen ist) und dann werden alle sehen was Raytracing so alles kann. Übrigens wenn man bei raytracing so schummelt wie bei rasterisierung (was texturemapping usw angeht) dann schaut raytracing auch jetzt schon wahrscheinlich nix schlechter aus ^^
 
Ich habe da ne kleine Frage, die nicht direkt etwas mit dem Thema zu tun hat: Warum berechnet eine GPU bei GX2/X2 Karten einen kompletten Frame und warum teilen die GPUs sich das Bild nicht?
 
@ e-Laurin:

Beim Raytracing wird der Raum in Blöcke eingeteilt, die in eine Baumstruktur gebracht werden. Die Blätter enthalten Informationen über die enthaltenen Dreiecke dieses Bereiches; Der Raytracer muss nun nur noch eine Schnittpunktberechnung mit den Dreiecken durchführen, die sich in dem in Frage kommenden Bereich befinden. So viel ist den meisten wohl klar. Dazu ein Auszug aus der c't:

"[...] Dank dieser Optimierung wächst der Rechenaufwand für Raytracing nicht linear mit der Gesamtzahl der Polygone in einer Szene: Verdoppelt sich die Polygonanzahl, braucht der binäre Baum lediglich eine weitere Ebene, um die Zahl der zu testenden Dreiecke konstant zu halten. Der Rechenaufwand für die Schnittpunktberechnungen ist nun deutlich kleiner als für das Durchlaufen der Baumstruktur; deshalb wächst die Zahl der nötigen Berechnungen nur proportional zum Logarithmus der Polygonzahl. [...]
Das gilt in dieser einfachen Form aber nur, wenn sich die Objekte einer Szene nicht relativ zueinander bewegen - Sonst muss nämlich die Baumstruktur neu erzeugt werden. Man sucht daher nach Verfahren, mit denen sich die Datenstruktur mit möglichst wenig Aufwand an Veränderungen anpassen lässt. Einige Forscher experimentieren dabei mit der hierarchischen Anordnung von Bounding-Boxen ebenfalls in einer Baumstruktur."
(15/2008, Seite 157/158)

Unmittelbar lässt sich dieser gern genannte Vorteil von Raytracern leider nicht auf die Wirklichkeit anwenden.
 
Kann man da nicht einfach einen BSP-ähnlichen Baum verwenden? Also dass Räume ein Teil des Baumes sind? So braucht man nur beim Kompilieren der Map den Baum generieren. Wenn der Spieler dann durch das Level läuft, springt er einfach nur von Raum zu Raum bzw. von Ast zu Ast. Der Rechner müsste dann nie den ganzen Baum durchackern, um herauszufinden, welches Polygon für die Szenerie wichtig ist.
 
Zuletzt bearbeitet:
-Unreal- schrieb:
crysis sieht besser aus^^
ich denke mit ner cryengine 4, 1920 x 1080 8AA und 16AF haben wir alle das was wir wollen ... ohne raytracing.
Aber bis die Engine da ist das dauert noch 6 7 Jahre und bis das dann so flüssig dagegeben werden kann noch min 12.

Spätestens 5 Jahre und Raytracing läuft flüssig... schau dir mal die Entwicklung der letzten 5 Jahre an ;)
 
leute was labert ihr da? RT kann die belichtung gut simulieren, also schatten, spiegelungen, etc.. guckt guckt doch mal wie viele spiegelnde fenster und flächen da im demo sind, und alle sind live berechnet. das ist doch schon wahnsinn:)
 
Also ich bin begeistert, was für Sprünge das Thema Raytracing gemacht hat. Hatte mir vor kurzem das Buch "Raytracing und Szenengraphen" zugelegt um mich mal in das Thema einzulesen. Was Nvidia da gschaft hat ist echt toll.
 
Raytracing ist eine tolle Idee, auch wenn diese Demo nicht so gut gemacht ist, wie ich finde.
 
Zuletzt bearbeitet:
Interessant finde ich, dass eine Nvidia-Demo von einigen hier als Intelpropaganda bewertet wird.
 
w33546t206.jpg



AMD/ATI: Screenshots und Video der neuen Radeon-Ruby2.0-Technologiedemo:

http://www.pcgameshardware.de/aid,655714/News/Ruby_20_Screenshots_und_Video_der_neuen_Radeon-Technologiedemo/
 
Zuletzt bearbeitet:
Koskesh schrieb:
@ e-Laurin:

Beim Raytracing wird der Raum in Blöcke eingeteilt, die in eine Baumstruktur gebracht werden. Die Blätter enthalten Informationen über die enthaltenen Dreiecke dieses Bereiches; Der Raytracer muss nun nur noch eine Schnittpunktberechnung mit den Dreiecken durchführen, die sich in dem in Frage kommenden Bereich befinden. So viel ist den meisten wohl klar. Dazu ein Auszug aus der c't:

(15/2008, Seite 157/158)

Unmittelbar lässt sich dieser gern genannte Vorteil von Raytracern leider nicht auf die Wirklichkeit anwenden.

okay - das leuchtet mir dann auch ein. Es muss dann aber auch maximal mit jedem Polygon geschnitten werden - was wiederum eine obere Laufzeitschranke (Worst case - mehr kommt nicht mehr dazu) von O(n) verursachen würde - also asymptotisch gleich shcnell wie rasterisierung....aber über die vorzüge von Raytracing gegenüber Rasterisierung - braucht man eigentlich kaum worte verlieren. Es geht nicht nur um Spiegelungen, es geht auch darum dass Sprites endlich ausgedient hätten, dass Rauch, feuer o.Ä. relativ leicht dargestellt werden können. Rundungen sind endgültig Rund und keine annäherung mehr. Indirekte weitestgehend korrekte beleuchtung, schatten die nicht mehr über texturemapping gemacht werden muss....

Ich raytrace schon seit über 10 jahren - und als ich die ersten openRT sachen gesehen habe - war ich schon überzeugt das es das werden wird. Mit sicherheit. Vor allem die skalierbarkeit ist super - Am anfang werden dinge wie Blobs o.Ä. vllt noch nicht möglich sein - aber die algorithmen existieren ja eigentlich schon - das heisst es ist riesen potential vorhanden ganz "leicht" neue effekte hinzuzufügen - und wenn genug leistung da ist - zack funkt es schon.
 
Ich weiß noch, wie ich Anfang der Neunziger mit POV-Ray eigene Bilder per Raytracing erstellt habe.
Ein einzelnes Bild brauchte Stunden bis zur Fertigstellung.

Jede Pixelzeile dauerte gut 20-30 Sekunden, trotz extra angeschafften Koprozessors.

Wenn ich mir jetzt vorstelle, daß es mittlerweile möglich ist, daraus ein Spiel mit 30 fps flüssig darzustellen und das ganze auch noch für Grafikkarten optimiert wird, dann haut mich das wirklich um.

Ich hoffe daraus wird in Zukunft was.

Erstens wären dann CPUs für Spieler auch wieder so bedeutend, wie seit über einem Jahrzehnt nicht mehr und zweitens erhöhen sich die Möglichkeiten für Entwickler ganz erheblich.
 
Zuletzt bearbeitet:
Also gegen das was AMD mit Cinema 2.0 in Echtzeit vorgezeigt hat sieht diese Vorstellung von Nvidia geradezu lächerlich aus.
 
Zurück
Oben