News Nvidia zeigt Raytracing auf der GPU

Ja, Raytracing will ich auch nicht schlecht machen - Ich zweifle nur daran, dass es so bald ein taugliches Echtzeitverfahren wird. Vorgerenderte Bilder/Szenen sehen durchaus eindrucksvoll aus. Eine Hybrid-Engine wäre als mittelfristige Kompromisslösung vielleicht denkbar? :D

e-Laurin, wäre das nicht wieder der statische Fall? Die Räume müssten festgelegt sein, ihr Inhalt auch.


Edit: Mit der Veyron ist die Präsentation natürlich sowieso ein Hingucker, da haben sie sich nen gutes Objekt ausgesucht um die Technik zu pushen ;)
 
Zuletzt bearbeitet:
e-Laurin schrieb:
@florymonth
Glaube nicht alles, was die Leute schreiben. Der Rechenaufwand bei steigender Polygonzahl ist bei Raytracing logarithmisch. Das ist ein Fakt, der sich ohne Probleme mathematisch beweisen läßt.

Es geht aber nicht nur allein um die Polygone in einem Spiel.Das wird in dem zitierten Thread recht gut erklärt.(Lod,Geometrie etc.)
 
kalle28 schrieb:
Also gegen das was AMD mit Cinema 2.0 in Echtzeit vorgezeigt hat sieht diese Vorstellung von Nvidia geradezu lächerlich aus.

Es ist schon interessant, wie der Fanboy-Krieg sich auf JEDE einzelne News von CB
ausweitet...
Die Leute diskutieren über die Vor/- und Nachteile von Ray Tracing und Rasterisierung
und plötzlich: aus dem Nichts kommt ein vollkommen unquallifizierter Kommentar der
nicht im geringsten mit den News zu tun hat...
Tut mir leid aber ich blicke nicht ganz warum hier einige
diesen absolut sinnfreien Konkurrenzkampf immer wieder aufwühlen müssen...
Q_q Jungs was denkt ihr euch?..

Wie auch immer:
Ich bin von den Reflexionen beeindruckt und sehe die Zukunft auch in Ray Tracing
oder einer Art Hybridengine.. Wir werden sehen, was die nächsten Jahre so bringen,
aber Ray Tracing aufgrund einiger Nachteile als untauglich zu verurteilen finde ich unpassend...
Rasterisierung birgt ja auch seine Nachteile.
 
@ Boffo

Ich glaube hier wird nichts auf Grafikkarten optimiert, sondern eben einfach CUDA für die Berechnung eines Raytracers genutzt. Das ganze macht auch mehr Sinn, da so den 3D-Programmierern auf der Anwendungsentwicklerseite mehr Freiraum gelassen wird, ohne dass die Aufgabe der Überspezialisierung nun mit allzuviel Performance-Verlust verbunden wäre. Wenn man sich den Larrabee-Artikel bei Anandtech so durchliest, scheint schon Interesse an mehr Entwicklerfreiheit vorhanden zu sein. Der Vorteil bei nem X86 (larrabee) oder für CUDA/OpenCL geschriebenen Raytracer ggü. OpenRT scheint zu sein, dass du deinen ganz eigenen Raytracer schreiben darfst, so wie John Carmack für Doom 1 und 2 seinen ganz eigenen Rasterizer schrieb, ohne auf vorgefertigte Strukturen von Glide, Direct3D, OpenGL oä. festgelegt gewesen zu sein. ;)
 
Moment mal, als Doom raus kam gabs doch garkein DirectX und OpenGL nur im professionellen bereich. 3DFx wurde überhaupt erst 94 gegründet.
Carmack blieb ja garnichts übrig als seinen eigenen Rasterizer zu schreiben, es gab ja keinen verbreiteten Standard.
 
bluebarcode schrieb:
[...]
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.
[...]
wunschdenken, mehr nicht. reines raytracing ist erst ab sehr großen datenmengen schneller. im wirklichen einsatz ist es aber heute selbst auf rendering-farmen noch so langsam das es nur für stil-renderings oder kurze animationen benutzt wird.

im film bereich werden fast ausschließlich rasterizer benutz (wie z.b. prman [der "renderman"] oder mental ray), die raytracing nur für sekundäre effekte nutzen (die für die meisten größeren renderings performance bedingt abgeschaltet bleiben), und nicht um das ganze bild zu rendern.

zumal raytracing nicht gleich raytracing ist. das eigentliche verfahren direkt pixel mit raytracing zu rendern ist für die meisten effekte die man so von "raytracern" kennt garnicht verantwortlich. so auch in der gallery zu yafray die hier gepostet wurde. realistische schatten und beleuchtung kann man so z.b. überhaupt nicht rendern. dafür sind z.b. global illumination algoritmen notwendig, die noch viel viel langsamer sind und auch in 5 jahren nocht nicht in echtzeit nutzbar sein werden.

in den nächsten 10 jahren kommt man um einen hybriden nicht drum herrum - die offline renderer machen es vor. denn nach "perfekten" (und nicht realistischen) schatten und spiegelungen ist bei reinem raytracing erstmal schluss.
 
Zuletzt bearbeitet:
Technisch beeindruckend, aber die Texturen wirken trotzdem wie spiegelnder Kunststoff. Was immerhin ein Fortschritt ist, denn bisher hatten wir "nur" matten Kunststoff. Jaja, das soll Metall darstellen, ist mir durchaus klar. Dazu paßt vielleicht ein Witz ganz gut:
Die Lehrerin ist mit ihrer Klasse in einer Bilderausstellung für Expressionismus. Sie stehen vor einem Bild, welches die Lehrerin mit "es soll eine Kuh darstellen" kommentiert. Daraufhin ein Schüler: "Und warum tut es das dann nicht?"
 
Der Unterschied zwischen Cinema 2.0 und Raytracing ist folgender:
Während Raytracing die Technik ist, mit der Grafikinhalte dargestellt werden können, ist Cinema 2.0 soweit ich verstanden habe nur dazu du diese Inhalte zu erstellen. Daher kann man die Techniken auch nicht vergleich.
 
sieht wie ich finde VERDAMMT gut aus, dafür dass die chips eign für rasterisation optmiert wurden^^
 
Ihr vergleicht hier A mit B.... ohne zu wissen was ihr hier vergleicht :/
 
Mal eine sehr gewagte These von mir, unter der Annahme es richtig verstanden zu haben, daß es seitens der GraKa-Herstellern auch eine Unterstützung für RT bedarf (ansonsten ist egal was jetzt kommt ;) ):

RT wird sich erst dann durchsetzen, wenn AMD/NVidia/Intel wissen was sie NACH RT noch als Kaufargument bringen können um Karten zu verkaufen. Angenommen RT wäre nun Standard. Um noch schönere Bilder zu bekommen brauche ich ja nicht mehr soviel Leistungswachstum, wie hier schön vorgerechnet wurde, folglich brauche ich auch nicht so schnell eine neue Graka. Das ist wie mit der Öl/Autoindustrie. Wir hätten schon längst das benzinfreie Auto, wenn die nicht so zusammenhingen.
 
@Forum-Fraggle
Die Autoindustrie wird sich von der Bevölkerung für den "entscheidenden Durchbruch" feiern lassen, sobald die Verkäufe von "Benzinern" weit genug gesunken sind.

Ein Grund, warum auch RT immer schnellere Hardware braucht, ergibt sich schon durch die steigenden Auflösungen. 40" TFT mit 5000 x 3125 Auflösung FTW ;)
 
@ riDDi

Na eben, deswegen musste Carmack eben auch nicht auf den Drfiect3D oder OpenGL-Rasterizer zurückgreiffen, sondern konnte seine ganz eigene Rasterisierung schreiben - einen Software-Rasterizer. Er konnte dabei Effekte für den Rasterizter und auch den Rasterizer selbst vollkommen frei programmieren, weil ja alles, wozu er kompatibel sein musste, die Prozessorarchitektur war (und das in Hochsprachen wie C - damit eigentlich nichtmal das). ;)
 
WiseGuy schrieb:
@Forum-Fraggle
Die Autoindustrie wird sich von der Bevölkerung für den "entscheidenden Durchbruch" feiern lassen, sobald die Verkäufe von "Benzinern" weit genug gesunken sind.

Ähm, geht nur, wenn sie die Autos auch anbieten, genau da liegt ja das Problem. Beim H2 Auto gab es in den 70ern schon gute Fortschritte, wurde aber auf Eis gelegt. Das E-Auto ist auch eine sehr gute Alternative insbesondere in Kombi mit Solardach und Solargarage.

Ein Grund, warum auch RT immer schnellere Hardware braucht, ergibt sich schon durch die steigenden Auflösungen. 40" TFT mit 5000 x 3125 Auflösung FTW ;)

RT Interesse beim Heimanwender liegt mehr bei Spielen, da wird es ab 24 Zoll schon unübersichtlich. Abgesehen davon steckte es in der These drin, denn die benötigte Leistungsteigerung ist bei dem 40 Zöller eben weitaus geringer als wir sie jetzt von Rasterisierung kennen.
 
@MountWalker: Ich würde nicht gern für jedes Spiel einen neuen Rasterizer/Raytracer schreiben wollen. Ist ja nicht so als ob OpenGL und Direct3D furchtbar unoptimiert wären, im Gegenteil. Vorteil ist natürlich, dass ich den ganzen "crap", den ich nicht brauche weglassen kann. Aber was brauchte es für Wolfenstein und Doom schon? Sprites ^^
Fixed Functions sind ja sowieso out. Irgendwann berechnen wir auch Texturen dynamisch, dann wird alles billiger ;)
 
Zuletzt bearbeitet:
Liege ich in der Annahme richtig das die Herr der Ringe Szenen aus dem Computer via Raytracing grendert wurden?
Dann sollte das all die die sagen das es so schlecht aussähe beruhigen.
 
Wäre dieses Raytracing dann nicht eher was für 3D Konstruktionsprogrammen ? (z.B. Solid Works...)
 
Elcrian schrieb:
Liege ich in der Annahme richtig das die Herr der Ringe Szenen aus dem Computer via Raytracing grendert wurden?
Dann sollte das all die die sagen das es so schlecht aussähe beruhigen.
nein. herr der ringe wurde (zum großteil?) mit prman gerendert. der ist heute ein hybrid renderer, wobei raytracing in film produktionen kaum benutzt wird. die erste version die raytracing beherscht wurde allerdings erst nach dem ersten film released. man kann also davon ausgehen das sowohl der erste als auch der 2. film praktisch raytracing frei sind.
 
Zuletzt bearbeitet:
@ riDDi

Du musst ja nicht den raytracer oder Rasterizer fpür jedes Spiel neu schreiben, sondewrn kannst auch den von John Carmack oder Tim Sweeney kaufen - wird mit den Grafikengines, die auf DX oder OGL aufbauen ja auch nicht anders gemacht. Der Entwicklungsaufwand für die Weiterentwicklung der Hardwaregussrenderer muss auch nicht weniger bezahlt werden, als die Entwicklung von Software-Renderern. (OpenGL wird halt von den hardwareherstellern bezahlt, die sich das Geld von ihren Kunden holen, und bei DX kommt dann die Lizenzeinnahme hinzu) Der einzige Vorteil der Hardware-Renderer bestand in der besseren Leistung und die könnte mit Larrabee nebensächlich werden. ;)
 
Zuletzt bearbeitet:
Zurück
Oben