Archiv verlassen und diese Seite im Standarddesign anzeigen : Ray tracing soon to go real-time for 3D rendering
Moralelastix
2006-08-07, 15:51:53
http://arstechnica.com/news.ars/post/20060805-7430.html
"I think that Scientific American is right when they claim that we're on the cusp of a new wave of major graphics improvements"
Wow!
Ray tracing scaliert demach sehr gut mit der Anzahl der CPU Cores.
Mit Quadcores 2007 wirds dann wohl auch für "Spieler" langsam spannend.
Sowas könnte echt die neue Killer-App für Multicore-CPUs werden!
http://arstechnica.com/news.ars/post/20060805-7430.htmlMit Quadcores 2007 wirds dann wohl auch für "Spieler" langsam spannend.
Von Realismus ist diese Aussage aber ziemlich weit entfernt...
Ray tracing scaliert demach sehr gut mit der Anzahl der CPU Cores.
Was für eine bahnbrechende Erkentnis X-D
dildo4u
2006-08-07, 18:06:12
Quark für eine Quake 3 Emulation hat man schon über 30CPU cores gebraucht und das war dann auch nicht sonderlich flüssig.
runs faster with more computers (about 20 fps@36 GHz in 512x512 with 4xFSAA)
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/
Das schöne an Raytracing ist aber wenn der Grundspeed mal vorhanden ist kann man eigentlich statische Geometrie draufschmeißen wie man will.
Hat man halt noch das Problem mit der dynamischen...
Gas Ganze gibt es schon und funktioniert auch mit aktueller Hardware.
>klick< (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=308538&highlight=fantasy+engine)
Das verwendet ganz sicher kein Raytracing.
tokugawa
2006-08-07, 19:20:32
Raytracing/Raycasting in Echtzeit gibt's ja schon... sogar auf der GPU.
Forscher aus der Volumen-Visualisierung sind da besonders aktiv.
Ist halt nicht DAS Raytracing das alle meinen (und von dem sie glauben dass es mehr "Realismus" bringt).
Das verwendet ganz sicher kein Raytracing.
Aha, was denn sonst?
Undertaker
2006-08-07, 20:49:03
Quark für eine Quake 3 Emulation hat man schon über 30CPU cores gebraucht und das war dann auch nicht sonderlich flüssig.
runs faster with more computers (about 20 fps@36 GHz in 512x512 with 4xFSAA)
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/
das waren 20 xp 1800+... einer davon sollte etwa ein virtel der leistung eines 3ghz conroe bringen, dieser hat außerdem noch 2 cores, entspricht also schon 8 der 20 cpus... mit einem quad-core hat man also schon fast die power des quake-systems, ergo sind wir schon sehr nah dran, solch eine grafik auf unseren pcs rendern zu können...
wenn man es jetzt noch schafft, die grafikkarte zb über programmierbare shader mit in die berechnungen einzubinden, sollte einiges möglich sein :)
tokugawa
2006-08-07, 21:04:45
Und dann ist man bei einer Art des Raytracing wo noch nichts von der Beleuchtung physikalisch korrekt berechnet wird. Für die Realitätsfanatiker wird das dann sicher ein Schock sein.
Aha, was denn sonst?
Es gibt noch etliche weitere GI-Lösungen, vor allem auch gute Approximationen. Gibts einige Papers dazu u.a. von nVIDIA.
Nachtrag: Überhaupt ist reines Raytracing gar keine GI-Lösung ohne weitere Techniken wie Photon-Mapping.
Und dann ist man bei einer Art des Raytracing wo noch nichts von der Beleuchtung physikalisch korrekt berechnet wird. Für die Realitätsfanatiker wird das dann sicher ein Schock sein.
Nicht nur das.
Nachdem man ja nun schon eine (für heutige Verhältnisse) abartige Rechenleistung reingesteckt hat, um Raycasting betreiben zu können, werden sie versuchen einfach Geometrie in die Pipeline zu stopfen.
Dabei merken sie dann, dass man mit Overhead zu kämpfen hat und die Beschleunigerstrukturen wahre Speicherfresser sind.
Danach werden sie enttäuscht feststellen, dass sie doch wieder LOD einführen müssen um Speicher zu sparen und das geometrische Aliasing zu bekämpfen.
Der nächste Schock kommt dann spätestens bei Partikelsystemen mit viel Alphablending oder anderen Dingen mit viel Alphatesting X-D
Hier an der Uni Saarbücken wird sehr intensiv an Raytracing geforscht. Es gibt bereits Hardware, die später um Shader erweitert wurde. Die berechneten Bilder ziemlich gut aus. Aufgrund des Prototypen-Status (damals hab ich das nur auf 2 parallelen FPGAs laufen sehen) waren die Frameraten aber noch leicht ruckelig und die Auflösung ca. SVGA. Es gab aber immerhin schon verschiedene Anti-Aliasing-Modi (weiß aber nicht mehr wieweit die auf die Performance gingen).
Physikalisch korrektes Lightning ist ja durch das Raytracingprinzip quasi schon gegeben. Nur bei weichen Schatten (etwa durch räumlich ausgedehnte Lichtquallen verursacht) muss man etwas in die Trickkiste greifen - was dann aber auch sehr sehr gut aussieht. Das war damals auch noch nicht in Echtzeit zu sehen - vermutlich wegen des wesentlich höheren Rechenaufwands.
Bin leider kein großer Experte auf dem Gebiet, verfolge aber die Entwicklung sehr interessiert. Das größte technische Problem von dem ich zur Zeit weiß, sind dynamische Szenen. Das liegt daran, dass sämtliche Geometriedaten in einer Baumstruktur gespeichert sind und diese Struktur verändert werden muss, wenn ein Stück Geometrie seinen Ort verändert (bzw. die Position der Geometrie relativ zur Kamera verändert wird). Deterministisch ist das kein großes Problem - einfach im Voraus einen Pfad für z.B. eine sich bewegende Kugel errechnen und den Baum entsprechend ändern. Nichtdeterministisch (sprich: Art und Zeitpunkt von Geometrieänderungen sind unbekannt) geht das nicht so einfach. Gerade das ist der Knackpunkt z.B. bei Spielen. Der zuständige Prof. hofft auf Lösungsansätze zur diesjährigen Siggraph (gerade zuende gegangen) und ich hoffe im nächsten Semester gibts ein paar Vorträge die über den neusten Stand informieren.
Noch ein Wort zur Performance: Die Baumstruktur hat den Vorteil der logarithmischen Suchzeit - sprich eine Verdoppelung der Geometrie geht nur minimal auf die Performance. Ab einer gewissen Größenordung von Daten brauch man allerdings sehr viel Bandbreite um alles hin und her zu schaufeln. So wie ich das richtig verstanden habe limitiert derzeit nicht die Rechenleistung von Raytracing-Hardware sondern eher die Speicherbandbreite.
tokugawa
2006-08-08, 00:08:48
Nicht nur das.
Nachdem man ja nun schon eine (für heutige Verhältnisse) abartige Rechenleistung reingesteckt hat, um Raycasting betreiben zu können, werden sie versuchen einfach Geometrie in die Pipeline zu stopfen.
Dabei merken sie dann, dass man mit Overhead zu kämpfen hat und die Beschleunigerstrukturen wahre Speicherfresser sind.
Danach werden sie enttäuscht feststellen, dass sie doch wieder LOD einführen müssen um Speicher zu sparen und das geometrische Aliasing zu bekämpfen.
Der nächste Schock kommt dann spätestens bei Partikelsystemen mit viel Alphablending oder anderen Dingen mit viel Alphatesting X-D
Ganz zu schweigen davon dass man dann draufkommt dass einzigartigere Renderstile (Celshading, NPR) mit Rasterizern einfacher zu implementieren sind.
Wer will schon Spiele die alle gleich ausschauen? Ich find den Vorteil beim normalen Rasterizer dass man einfacher den Spielen einen eigenen distinkten Look verleihen kann. Spiele die wie aus einer Klonfabrik aussehen, brauchen wir nun wirklich nicht.
Hier an der Uni Saarbücken wird sehr intensiv an Raytracing geforscht.
An der TU Wien auch, auch wenn ich nicht wirklich zur Photorealistic-Rendering-Gruppe gehöre.
Physikalisch korrektes Lightning ist ja durch das Raytracingprinzip quasi schon gegeben.
Gerade das kann nicht wirklich stimmen. Raytracing alleine ist noch nicht physikalisch korrekt. Es kommt 1) auf die Art des Raytracing an 2) auf das Illuminations/Scatteringmodell.
Und gerade hier kann man eigentlich fast unendlich viel Rechenzeit verschwenden (etwa wenn man Lichtsplitterung etwa durch Prismen mitberechnet).
Wenn man diese ganze Klasse an Raytracing-Algorithmen sieht, dann kann man (wie ich schon in einem Posting erwähnt habe), erkennen, dass es Raytracing in Hardware in einer simplen Form bereits gibt, mittels SM3-Pixelshader (etwa für Heightfield-Tracing, diverse Raytracing-Refraktionseffekte, sowie Volume Visualization).
Der zuständige Prof. hofft auf Lösungsansätze zur diesjährigen Siggraph (gerade zuende gegangen) und ich hoffe im nächsten Semester gibts ein paar Vorträge die über den neusten Stand informieren.
Da ist die Eurographics 2006 sicher auch eine Anlaufstelle dafür - ist immerhin nach der Siggraph die zweitgrößte wissenschaftliche Konferenz für Computergraphik (und wird dieses Jahr von seiten des CG Instituts der TU Wien organisiert).
Wieso war ich ausgelogt?:|
Nunja der letzte Gast war ich.
Bin leider kein großer Experte auf dem Gebiet, verfolge aber die Entwicklung sehr interessiert. Das größte technische Problem von dem ich zur Zeit weiß, sind dynamische Szenen. Das liegt daran, dass sämtliche Geometriedaten in einer Baumstruktur gespeichert sind und diese Struktur verändert werden muss, wenn ein Stück Geometrie seinen Ort verändert (bzw. die Position der Geometrie relativ zur Kamera verändert wird). Deterministisch ist das kein großes Problem - einfach im Voraus einen Pfad für z.B. eine sich bewegende Kugel errechnen und den Baum entsprechend ändern. Nichtdeterministisch (sprich: Art und Zeitpunkt von Geometrieänderungen sind unbekannt) geht das nicht so einfach. Gerade das ist der Knackpunkt z.B. bei Spielen.
Einer der Knackpunkte. Es gibt aber noch einige andere.
Was der Vorteil bei den statischen Geometrie betrifft:
Wenn ich eh schon alle Geometrie rendern kann, die in den Speicher passt, was nutzt mir dann noch eine theoretisch bessere Laufzeit, die mir aber erst bei noch wesentlich mehr Geometrie einen Vorteil bringen würde?
LOD brauch man aus den schon genannten Gründen eh.
Zudem ist dynamisch generierte Geometrie wohl eins der wichtigen längerfristigen Ziele im Spielebereich und wird von MS nach eigenen Aussagen in zukünftigen D3D Versionen auch verstärkt unterstützt werden. Rasterizer habens hier dank fehlender Beschleunigerstruktur wesentlich einfacher.
Der zuständige Prof. hofft auf Lösungsansätze zur diesjährigen Siggraph (gerade zuende gegangen) und ich hoffe im nächsten Semester gibts ein paar Vorträge die über den neusten Stand informieren.
Die entsprechenden Paper sind seit einiger Zeit schon auf der Seite von Ingo Wald in Utah und auf der des Saarbrücker Grafiklehrstuhls verfügbar. Wer sich also auf den aktuellen Stand bringen will, muss also nicht auf einen Vortrag von Philipp zu warten. ;)
Im Prinzip hat man heute mit ReliefMapping, OPM etc schon eine Mischform zwischen Rasterisierung und Rasterisierung. Die grobe Geometrie wird rasterisiert und die feine Geometrie über Raycasting in einer Heightmap gefunden.Wenn man noch eine entsprechende Beschleunigerstruktur für die Heightmap hat, kann man auch die Laufzeitvorteile nutzen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.