Archiv verlassen und diese Seite im Standarddesign anzeigen : Neues in Sachen Echtzeit-Raytracing (Quake4RT)
Habe eben gerade gelesen, dass es was neues in Sachen Echtzeit-Raytracing zu vermelden gibt:
http://planetquake.gamespy.com/fullstory.php?id=108107
http://www.q4rt.de/
Macht IMHO mittlerweile schon ganz schön was her, nicht zuletzt auch durch die endlich vorhandene Textur-Filterung.
Die Performance ist zwar immernoch nicht mainstream-tauglich, aber da die Technik sehr gut auf mehreren CPUs skaliert könnte die zunehmende Verbreitung von Multicore-CPUs vielleicht in ein paar Jahren erste Anwendungen oder eben Spiele hervorbringen.
Eure Meinung dazu?
Problem: Core 2 QX6700 (4 CPUs) 16,9 FPS in 256x256. Ich denke die D3D10-GPUs werden für das sehr viel besser zu gebrauchen sein, vor allem weil sie Textursampling viel effizienter erledigen könnten.
16fps und sieht nicht wirklich gut aus. WENN man aber im Hinterkopf bedenkt was im Hintergrund alles passiert, dann ist es natürlich schon ein mittlerer Hammer. Nur sieht halt letztendlich nicht wirklich "aktuell" aus ;)
Das mit dem "aktuell Aussehen" ist so ne Sache. Der Typ ist Programmierer und kein Artist.
Bumpmapping und scharfe Schatten kann das Ding genauso wie Q4 auch.
Naja, das Projekt verwendet ja die Artworks von Quake4.
Vorteil des Raytracings ist halt, dass der Polygon-Count praktisch keine Rolle mehr spielt.
Muh-sagt-die-Kuh
2006-11-04, 20:00:01
Ich verstehe nicht so ganz, was der Sinn der Sache ist.....Raytracing ist wunderbar für realistisches Offline-Rendering geeignet, aber eben in keinster Weise für Echtzeit Anwendungen...
Naja, das Projekt verwendet ja die Artworks von Quake4.
Jo, aber nicht die gleichen Lichtverhältnisse offenbar.
Vorteil des Raytracings ist halt, dass der Polygon-Count praktisch keine Rolle mehr spielt.
Bei statischer Geometrie.
Ich verstehe nicht so ganz, was der Sinn der Sache ist.....Raytracing ist wunderbar für realistisches Offline-Rendering geeignet, aber eben in keinster Weise für Echtzeit Anwendungen...
Wieso nicht?
Ich verstehe nicht so ganz, was der Sinn der Sache ist.....Raytracing ist wunderbar für realistisches Offline-Rendering geeignet, aber eben in keinster Weise für Echtzeit Anwendungen...
Im Moment nicht nicht, das bestreitet ja niemand. Aber es geht ja hier um eine Forschungsarbeit.
Vorteil des Raytracings ist halt, dass der Polygon-Count praktisch keine Rolle mehr spielt.
a) falsch, solange man es nicht nur in der Theorie betrachtet
b) was würde dir das bringen? Um LOD kommt man auch nicht rum
vom bumpmapping sieht man auf vielen screenshots nicht besonders viel. im gegenteil - es sieht eher so aus als ob bei den meisten texturen nur die diffuse-maps verwendet werden...
Mastermind
2006-11-04, 23:39:48
Geilomat! :smile:
Eine Workstation mit zwei übertakteten QX6700 und das Vieh ist halbwegs spielbar. :smile:
BAGZZlash
2006-11-05, 01:03:26
Warum wird eigentlich immer, wenn hier was über Echtzeitraytracing gepostet wird, losgezetert? Wie die Waschweiber. Also ich finde, das ist 'ne tolle Sache!
Muh-sagt-die-Kuh
2006-11-05, 12:06:20
Wieso nicht?Weil die aktuell verfügbare Rechenleistung für eine realistische Darstellung in keinster Weise ausreicht. An dem Beispiel sieht man das wunderbar.....um ein paar Raytracing Effekte in extrem niedrigen Auflösungen ermöglichen zu können, muss man die restliche Darstellung auf Doom 2 Niveau senken...
Muh-sagt-die-Kuh
2006-11-05, 12:10:51
Im Moment nicht nicht, das bestreitet ja niemand. Aber es geht ja hier um eine Forschungsarbeit.Deren Sinn ich nach wie vor nicht zweifelhaft ist.....man nimmt einfach eine Standard-Raytracing Engine und deaktiviert so lange Komponenten bzw. vereinfacht diese, bis die Frameraten halbwegs im Echtzeit-Bereich sind. Was dabei rauskommt, sieht aber dementsprechend bescheiden aus....Raytracing wird genau dann sinnvoll, wenn genug Rechenleistung für das gesamte Feature-Set vorhanden ist.
man nimmt einfach eine Standard-Raytracing Engine und deaktiviert so lange Komponenten bzw. vereinfacht diese, bis die Frameraten halbwegs im Echtzeit-Bereich sind. Was dabei rauskommt, sieht aber dementsprechend bescheiden aus....
Das ist so nicht ganz richtig. Wie man auf der Seite nachlesen kann basiert das Projekt auf der OpenRT-Schnittstelle, für welche sogar zur Zeit ein Hardware-Beschleuniger entworfen wird (Prototyp gibt es schon), der am Ende sicher auch ein flüssiges Spielen mit höheren Auflösungen und Features ermöglichen würde.
Ich finde, es sieht momentan einfach nur schlecht aus. Aber man muss im gleichen Zuge auch bedenken, wie rechenintensiv RT ist und dass die Technologie sicherlich noch weiter entwickelt werden wird. Von daher ist es sicherlich interessant, diese Angelegenheit etwas zu verfolgen.
DR.ZEISSLER
2006-11-07, 00:01:32
http://www.q4rt.de/videos/q4rt_vid02.avi
Das war aber der Hardware-Raytracer Prototyp ODER ?
Hatte mir den HW-Raytracer mal auf der Cebit 05 angesehen, war echt beeindruckend. patent wohl bei nvidia, fertige karte wohl auch, veröffentlichung nicht vor 2010.
http://www.q4rt.de/videos/q4rt_vid02.avi
Das war aber der Hardware-Raytracer Prototyp ODER ?
Offline-Rendering.
Einfach Auflösung erhöht, jedes Frame gespeichert und ein Video draus gemacht.
Hatte mir den HW-Raytracer mal auf der Cebit 05 angesehen, war echt beeindruckend. patent wohl bei nvidia, fertige karte wohl auch, veröffentlichung nicht vor 2010.
Rechte sind entweder beim CGUdS oder bei Intrace. Schätze ersteres mit Wanderungstendenz Richtung zweitem. Als Prototyp würde ich das auch nicht bezeichnen. Höchstens als Studie.
MadMax@
2006-11-08, 17:16:41
kein Mensch braucht Echtzeit Raytracing in Spielen wozu auch.
es braucht auch kein mensch mehr als 640KB arbeitsspeicher
scnr
BAGZZlash
2006-11-08, 18:02:18
es braucht auch kein mensch mehr als 640KB arbeitsspeicher
scnr
Sagte Bill Gates 1981.
Sagte Bill Gates 1981.
oder auch nicht...
Onkeltom421
2006-11-08, 22:06:47
oder auch nicht...
Doch hat er ;)
Neomi
2006-11-09, 01:31:48
Doch hat er ;)
http://en.wikiquote.org/wiki/Bill_Gates#Misattributions
Er selbst bestreitet es, so eine Aussage würde auch keinen Sinn ergeben. 640 KiB waren nicht der Anfang. Bis dahin war es eine lange Entwicklung mit einigen Steigerungen und damals war natürlich schon abzusehen, daß 640 KiB eben irgendwann nicht mehr reichen. Genauso, wie heute schon abzusehen ist, daß auch 4 GiB irgendwann zuwenig sind, über 1 TiB werden wir auch irgendwann nur noch lachen, genauso wie spätestens unsere Kinder mit weniger als 1 PiB nicht mehr auskommen wollen.
Da wär ich jetzt aber vorsichtiger, irgendwann kann man ja leider keine kleineren Schaltungen bzw. DRAM-Zellen (oder wie auch immer es dann aussieht) bauen.
BAGZZlash
2006-11-09, 10:07:06
Da wär ich jetzt aber vorsichtiger, irgendwann kann man ja leider keine kleineren Schaltungen bzw. DRAM-Zellen (oder wie auch immer es dann aussieht) bauen.
Na und? Wenn's nicht kleiner geht, geht trotzdem mehr.
Klar, 2m breite RAM-Riegel oder was? X-D
Blaze
2006-11-09, 10:37:22
Das wär zumindest mal was anderes ;D
kein Mensch braucht Echtzeit Raytracing in Spielen wozu auch.
Schon einmal darüber nachgedacht, was Raytracing (besser) kann, als heutige Verfahren?
Schonmal darüber nachgedacht, was Rasterizing (besser) kann als Raytracing? ;)
Raytracing ist auch nicht der heilige Gral. Da gibt's dann andere Probleme (dynamisch Geometrie ist z.B. ein sehr großes) und Global Illumination bekommt man dadurch auch nicht umsonst wie viele denken.
Schonmal darüber nachgedacht, was Rasterizing (besser) kann als Raytracing? ;)
Raytracing ist auch nicht der heilige Gral. Da gibt's dann andere Probleme (dynamisch Geometrie ist z.B. ein sehr großes) und Global Illumination bekommt man dadurch auch nicht umsonst wie viele denken.
(ich war der Gast)
Richtig,
ich habe es auch nicht als heiligen Gral hingestellt.
Aber Attribute wie "keiner", "nie" usw. finde ich trotzdem ein wenig hart. Ich finde es schön, wenn ein Projekt mal hingeht und zeigt, wie es im moment Aussieht, was möglich ist usw.
Raytracing ist z.B. sher gut parallelisierbar.
MikeB
2006-11-11, 18:42:08
kein Mensch braucht Echtzeit Raytracing in Spielen wozu auch.
Ich sag nur echte Refraktion/Reflektion, normales Rasterizing taugt hier nicht die Bohne !
Man kann ein paar von diesen Effekten anfaken, das wars auch schon. Schönes Beispiel: Self-reflection im Lack eines Autos, wie der Rückspiegel in der Tür als Spiegelung zu sehen wäre. (Womit viele Enginescreenshots als renderings entlarvt werden)
Im Moment kann man über eine Cubemap die Umgebung um ein Auto in einem Auto spiegeln. Wenn man jetzt für jedes spiegelnde bewegliche Objekt eine Cubemap rendern möchte ist realtime Raytracing wahrscheinlich jetzt schon schneller.
Ich sehe realtime Raytracing als die Zukunft, wenn vielleicht das Problem mit dynamischer Geometrie lösbar wird.
Die Q4RT Screenshots sind leider erbärmlich, man sieht nicht einen Vorteil von Raytracing, aber wahrscheinlich ist das nur eine Machbarkeitsstudie.
Michael
Ringwald
2006-11-11, 19:46:19
Mal ne doofe frage, sorgt/unterstützt Raytracing auch für/die Fotorealistische Grafik?
Und falls ja, ist dies überhaupt erstrebenswert im Gaming Bereich?
Weil ich kann mir nicht vorstellen das ein Publisher/Entwickler der ein Weltweiten release anstrebt sein Spiel,
wo es jetzt mal hart gesagt darum geht sein Gegner mit Waffengewalt auszuschalten (EgoShooter, RPG's, Echtzeitstrategie),
wirklich Fotorealistische Grafik verwenden kann.
Denn wen auch kein Blut fließt oder andere Splatter Effekte gibt, so sorgt das doch das bei dem meisten Sittenwächtern
für Alarmleuten da in diesen Falle die Spieler die Gegner realistisch sterben sehen, ja gar selbst ermordet haben und
die Abstumpfung dadurch schon stark gegeben ist wie ich finde.
Das sorgt doch für viele indizierungen oder ab 18+ Ratings in vielen Ländern was ja nicht grad sehr erwünscht ist.
Sorry falls das jetzt zu OT war :biggrin:
Mit Raytracing wird die Grafik keinesfalls automatisch fotorealistisch. Dazu braucht es dann schon noch eine ordentliche Global-Illumination-Methode, und natürlich realistische Szenendaten.
Mit einem Raytracer kann man genauso unrealistische Kampfszenen darstellen wie mit einem Rasterizer. ;)
seb74
2006-11-12, 00:49:40
Der Berechnungsaufwand beim Raytracing hängt primär von der Anzahl der Pixel ab. Es werden vom Auge des Betrachters aus Strahlen rückwärts in Richtung der Lichtquelle verfolgt, mindestens ein Strahl pro Pixel der Bildebene. dh bei 256x256 sind für jedes Frame 65536 Strahlenverläufe zu berechnen. Schon sehr beeindruckend, daß es mit den neuesten Enduser CPUs 16fps machbar ist. Raytracing ist sehr gut parallelisierbar, daher die gute Quad Skalierung. Natürlich sieht es optisch nicht so schön aus wie aktuelle 3D Spiele, es ist nur eine Machbarkeitsstudie, keine neue PC Spiele Technologie :cool: Ein Problem beim klassischen Raytracing ist, daß punktförmige Lichtquellen angenommen werden, was keine weichen Schatten ermöglicht und jede Veränderung der Betrachterposition was ja bei einem 3D Shooter durchaus vorkommen kann :D eine komplette Neuberechnung aller Strahlen erfordert.
Ich sag nur echte Refraktion/Reflektion, normales Rasterizing taugt hier nicht die Bohne !
Beeep. http://www.iit.bme.hu/~szirmay/ibl_link.htm
...und jede Veränderung der Betrachterposition was ja bei einem 3D Shooter durchaus vorkommen kann :D eine komplette Neuberechnung aller Strahlen erfordert.
Das ist ja der Normalfall beim Realtime-Rendering. Auch Rasterizer berechnen das Bild so oft neu wie es geht in Spielen ;)
MikeB
2006-11-12, 14:11:37
Beeep. http://www.iit.bme.hu/~szirmay/ibl_link.htm
Ja, ist schon toll was in diesen speziell preparierten test-szenen an tech-demos möglich ist...
"environment mapped reflections" Suppi, weit von self-reflections entfernt.
"Computing a map for each refractor surface" ... Geil, das gibt ja 'ne tolle performance !
"The method is fast and accurate if the scene consists of larger planar faces" Wie praxisnah...
Schönes Beispiel, wo normales Rasterizing endgültig mit seinen Fakes versagt: Ein plätschender Gebirgsbach... Eine Eishöhle mit Tropfsteinen aus Eis...
Es steht ausser Frage dass man viele Effekte sehr gut ohne Raytracing simulieren kann, aber irgendwo ist einfach Schluss, weil der Aufwand explodiert, und das dann bei geringerer Performance und Qualität als Raytracing.
Vielleicht kann man mit GPGPU da schon was reissen ?
Michael
Schönes Beispiel, wo normales Rasterizing endgültig mit seinen Fakes versagt: Ein plätschender Gebirgsbach...
Ist ja nicht so, dass Raytracing dort nicht auch wegen der Laufzeit versagen würde. ;)
tokugawa
2006-11-12, 15:21:54
Ich sag nur echte Refraktion/Reflektion, normales Rasterizing taugt hier nicht die Bohne !
Doch. Da gibt's sogar Papers dazu wie man Raytrace-Refraktionen/Reflektionen hier mit aktuellen GPUs erledigen kann, und das sogar skalierbar (also, je mehr Iterationen, desto "korrekter").
Beispiel:
http://www.cg.tuwien.ac.at/~chiu/raytrace_effects.jpg
(auf einer GeForce Go 6600 @ 250 MHz)
Man kann ein paar von diesen Effekten anfaken, das wars auch schon.
Und das tolle ist, dass die gefakten Versionen für "ungeübte" Augen kaum unterscheidbar aussehen. Das muß man sagen, trotz aller "Korrektheit" des oben gezeigten Raytrace-Effects-Verfahrens.
Gerade in Spielen wo man eben keine Glashasen hat, die irgendwie zentrales Spielelement wären, macht es keinen Sinn, zuviel GPU-Power in geraytracte Refraktionen zu verschwenden, wenn es ein billiger Fake genauso tut und genauso aussieht für die meisten Augen.
Schönes Beispiel: Self-reflection im Lack eines Autos, wie der Rückspiegel in der Tür als Spiegelung zu sehen wäre. (Womit viele Enginescreenshots als renderings entlarvt werden)
Stimmt, das ist eine Situation die kaum in Echtzeitrenderingengines durchgeführt wird, aber unmöglich ist das auch nicht. Apropos: "Rendering" ist auch das, was Echtzeit-Grafikengines tun, ein allgemeiner Begriff. Was du meinst ist "Offline-Rendering", oder "Nicht-Echtzeit-Rendering".
Im Moment kann man über eine Cubemap die Umgebung um ein Auto in einem Auto spiegeln. Wenn man jetzt für jedes spiegelnde bewegliche Objekt eine Cubemap rendern möchte ist realtime Raytracing wahrscheinlich jetzt schon schneller.
Kommt natürlich auf die Szene an. Aber der obig gezeigte Effekt ist quasi eine Kombination aus Rasterisierung und Raytracing: es verwendet zwar eine Cubemap zur "Adressierung" der Umgebung (Color & Depth), aber wendet dann im letzten Schritt Raytracing/Raycasting an (und benötigt daher Shader Model 3.0).
Wenn man aber Global Illumination mit reinhaben will, Ambient Occlusion/Spherical Harmonics, und ähnliches, dann kostet Raytracing dann mehr als das "hingefakte". Ganz zu schweigen von Spektral-Raytracing-Systemen (davon gibt's nämlich nur genau einen einzigen bisher).
Die Kosten/Nutzen-Frage geht zur Zeit immer noch deutlich zugunsten Rasterisierung aus!
Ich sehe realtime Raytracing als die Zukunft, wenn vielleicht das Problem mit dynamischer Geometrie lösbar wird.
Ich sehe es als eine mögliche zusätzliche Variante. Ich will aber gar keinen aufgezwungenen Realismus, sondern ich will die Auswahl haben, ob ich jetzt Realismus will in der Grafik, oder ob ich eher auf non-photorealistic Rendering (NPR) gehe. Letzteres ist mit Rasterizern deutlich einfacher möglich.
Und letztendlich sind es interessanterweise immer jene Grafiken in Spielen, die absichtlich einen eigenen, möglicherweise unrealistischen, Stil haben, die dann die Zeit überleben: Spiele die vor 5 Jahren versucht haben "realistisch" zu sein, schauen heute scheiße aus; Spiele dagegen, die schon vor 5 Jahren versucht haben, "Stil" statt "Realismus" umzusetzen, schauen selbst heute gut aus (Zelda: Wind Waker, XIII, usw.).
Auch Okami für die PS2 zeigt, dass man mit Stil vor Realismus selbst mit relativ "alter" Hardware sehr schöne Grafik erzeugen kann.
Die Q4RT Screenshots sind leider erbärmlich, man sieht nicht einen Vorteil von Raytracing, aber wahrscheinlich ist das nur eine Machbarkeitsstudie.
Raytracing ist ja auch nicht die Antwort auf alles.
Und was soll schlecht am "Faken" sein? Selbst Raytracing ist noch nicht so weit entfernt vom "Faken", dass man sagen könnte, man fakt nichts.
Das Elegante an der Echtzeitgrafik ist ja, dass man überzeugende Grafiken erzeugt, die einen Bruchteil an Rechenzeit kosten. Und das Tolle daran ist, dass man für gute Echtzeitgrafik daher auch etwas Kenntnis der Wahrnehmungspsychologie braucht: man muß wissen, worauf der Mensch achtet, was er wahrnimmt.
Und Faken und Betrügen ist letztendlich in fast allen Bereichen der Computergrafik gang und gebe; oder hat jemand schon die Rendering-Equation komplett gelöst?
MikeB
2006-11-12, 16:39:31
Ich wollte mit Sicherheit nicht Raytracing als den heiligen Gral hinstellen, aber den Spruch "kein Mensch braucht Echtzeit Raytracing in Spielen wozu auch." fand ich einfach dämlich.
Mein "normales Rasterizing taugt hier nicht die Bohne !" war vielleicht nicht viel besser...
"Und das Tolle daran ist, dass man für gute Echtzeitgrafik daher auch etwas Kenntnis der Wahrnehmungspsychologie braucht: man muß wissen, worauf der Mensch achtet, was er wahrnimmt."
Da geb ich dir völlig Recht !
Mal abgesehen davon, dass Glashasen in Spielen vielleicht nicht gebraucht werden, bricht diese Technik wohl völlig zusammen wenn 20 davon dargestellt werden sollen. Dann kommt man schnell in Regionen wo realtime Raytracing eine schnellere Diashow abliefert.
Eine Env-cubemap pro Objekt ist ... nicht sinnvoll.
Ich bin nur ein bischen zickig, weil mir diese Tech-demos manchmal richtig gegen den Strich gehen. Solche Effekte sind ja ganz toll, wenn die Umgebung aus 100 Polygonen besteht und 1 Meter gross ist.
In Spielen muss man sich mit Sichweiten >1000 Meter und gigantischen Polygonmengen rumschlagen, und dann muss man sich anhören, dass man als Spiele-Entwickler inkompetent ist weil man das nicht so schön wie die Tech-demos kann.
Michael
micki@work
2006-11-12, 17:42:56
Die Kosten/Nutzen-Frage geht zur Zeit immer noch deutlich zugunsten Rasterisierung aus!
wenn du auf einer CPU rasterisierst, ist das nicht wirklich der fall, zeichne einfach mal 100.000 tri/s, die gleichen die du mit nem raytacer abarbeitest, es wird nicht schneller sein.
dass man zZ mit GPUs rasterized statt zu tracen liegt eher daran, dass sie auf streaming von lokalen daten optimiert werden. du kannst von 100 nebeneinander liegenden pixeln ausgehen, dass sie auch sehr nah aneinander liegende texel haben werden. beim raytacen hingegen ist streaming nur schwer moeglich und wenn, dann ist es mit unmengen von logic verbunden die man nicht so leicht in hardware giesst, sondern mit software abarbeiten muss.
jedenfalls meine meinung.
dass man zZ mit GPUs rasterized statt zu tracen liegt eher daran, dass sie auf streaming von lokalen daten optimiert werden. du kannst von 100 nebeneinander liegenden pixeln ausgehen, dass sie auch sehr nah aneinander liegende texel haben werden. beim raytacen hingegen ist streaming nur schwer moeglich und wenn, dann ist es mit unmengen von logic verbunden die man nicht so leicht in hardware giesst, sondern mit software abarbeiten muss.
Wenn du selbe Geometrie hast und die Pixel in der selben Reihenfolge abarbeitest, wirst du beim Raytracing genauso nebeneinanderliegende Texel erwischen.
Einzig verdeckte Bereiche von einem Polygon werden auf andere Daten zugreifen.
Die Kosten-/Nutzenrechnung sieht für Raytracing mit dedizierter Hardware fällt trotzdem schlecht aus, wenn man betrachtet wieviel Rechenleistung man allein in das Raycasting stecken muss.
Wenn du selbe Geometrie hast und die Pixel in der selben Reihenfolge abarbeitest, wirst du beim Raytracing genauso nebeneinanderliegende Texel erwischen.
Einzig verdeckte Bereiche von einem Polygon werden auf andere Daten zugreifen.
beim raytracing hast du aber als grosses problem nicht das texturieren, sondern durch den baum traversieren, was selbst fuer zwei nebeneinander liegende pixel vom selben triangle bedeuten kann, dass der baum anders durchgelaufen wurde, somit ist das nur schwer durch streamingoptimierungen zu verbessern, wie es bei rasterizern sehr gut geht.
Die Kosten-/Nutzenrechnung sieht für Raytracing mit dedizierter Hardware fällt trotzdem schlecht aus, wenn man betrachtet wieviel Rechenleistung man allein in das Raycasting stecken muss.was nicht sagt, dass raytacing an sich diese schlechtere kosten-nutzen-rechnung hat, sondern nur dass bisher die hardware guys lieber die relative stumpfen optimierungen fuer rasterizer machen, was nur das exploiten von caching algos ist.
raytracing braucht sehr viel mehr logik und wirklich schnelle technologie (z.b. ram mit sehr kleiner latenz). und der weg bei rasterizern geht zZ in genau die gegenrichtung. mehr latenz, groessere streaming-bandbreite.
tokugawa
2006-11-12, 19:15:44
Niemand redet von "an sich", sondern ich redete von der pragmatisch gesehenen Situation, dass auch Hardware für Rasterizer leichter zu bauen ist (ist ja auch Teil der Kosten/Nutzenrechnung: die Hardwareimplementation).
tokugawa
2006-11-12, 19:25:46
Da geb ich dir völlig Recht !
Danke, aber könntest du vielleicht kein Leerzeichen vor dem Rufzeichen machen, wie es im Deutschen die korrekte Satzzeichensetzung wäre? :) Danke.
Mal abgesehen davon, dass Glashasen in Spielen vielleicht nicht gebraucht werden, bricht diese Technik wohl völlig zusammen wenn 20 davon dargestellt werden sollen.
Dann kommt man schnell in Regionen wo realtime Raytracing eine schnellere Diashow abliefert.
Klar, aber man sollte sowieso in Spielen nie gegen die Technik designen: wenn nur 5 Glasobjekte maximal vernünftig gehen, dann haben sich die Game und Art Designer an dieses Limit zu halten. Ist auf jeder Plattform so (speziell bei noch sehr viel mehr limitierten Plattformen wie etwa dem Nintendo DS).
Eine Env-cubemap pro Objekt ist ... nicht sinnvoll.
Da gibt's schon Tricks... Lazy Updates, niedrigere Auflösung, usw.
So teuer ist dieser Raytrace-Shader nicht, solang man die Iterationen sehr niedrig hält (bei 1-3 geht's wirklich sehr performant). Und bei niedriger Iterationenzahl sieht man den Unterschied auch nur wenn man sehr nah rangeht, da nur in der Nähe der Unterschied sichtbar ist.
Ich bin nur ein bischen zickig, weil mir diese Tech-demos manchmal richtig gegen den Strich gehen. Solche Effekte sind ja ganz toll, wenn die Umgebung aus 100 Polygonen besteht und 1 Meter gross ist.
Mir geht's genauso, aber der von mir erwähnte Raytrace-Effekt ist Teil des EU Gametools Projektes: www.gametools.org
Dort geht's eigentlich darum, High-End-Effekte zu entwickeln, die auch für Spiele geeignet sind, und nicht nur für 1-Raum-Testdemos mit den klassischen Stanford-Bunny/Buddha/Drachen.
In Spielen muss man sich mit Sichweiten >1000 Meter und gigantischen Polygonmengen rumschlagen,
Jein. In Spielen wird viel getrickst, 1000 Meter Sichtweite hast du fast nie, wenn doch (etwa in Vast-Outdoor-Szenarien wie Far Cry), dann wird viel mit Impostorn gearbeitet.
Die "gigantischen Polygonmengen" sind auch etwas übertrieben, so viel sind's auch wieder nicht.
Aber definitiv höhere Ansprüche als ein reines Techdemo, da hast du recht (vor allem da ein Spiel ja noch viel mehr machen muß - Spiellogik, AI, usw.).
und dann muss man sich anhören, dass man als Spiele-Entwickler inkompetent ist weil man das nicht so schön wie die Tech-demos kann.
Ja, das geht mir auch am Nerv.
Apropos: Für dieses Gametools-Projekt entwickel ich gerade ein Demospiel, das einige dieser Effekte in einer echten Spieleumgebung zeigen soll, und damit quasi ihre "Praxistauglichkeit" beweisen soll.
Der Refraktionseffekt ist zwar nicht so billig dass man da 50 Objekte reinstellen könnte, aber er ist auch nicht allzu teuer. Er ist zumindest ein Effekt, der "GPU-friendly" geschrieben ist, und somit gerüstet ist für die nähere Grafikkartenzukunft - auf meiner GeForce 7950 GT rennt der Effekt im Demospiel wirklich flüssig (auf meiner X1900XT auch, aber da die ATI kein FP-Filtering kann, schaut's artefaktbehafteter aus), auf der GeForce 8800 müsste der Effekt rasen, und auf einer GeForce 9 könnte man den Effekt vermutlich schon weitflächiger einsetzen.
Ich sehe es als eine mögliche zusätzliche Variante. Ich will aber gar keinen aufgezwungenen Realismus, sondern ich will die Auswahl haben, ob ich jetzt Realismus will in der Grafik, oder ob ich eher auf non-photorealistic Rendering (NPR) gehe. Letzteres ist mit Rasterizern deutlich einfacher möglich.
Was da momentan gemacht wird ist doch nur outline-rendering, cell-shading und darauf ausgelegte Texturen zu nutzen. Ich sehe kein Problem darin, das mittels eines Raytracers zu rendern. Für Outlines einfach bei bestimmten Eintreffwinkeln schwarz zeichnen, der Rest ist eh trivial und genau wie bei einem Rasterizer zu erledigen.
MikeB
2006-11-12, 20:07:41
Tokugawa, schön, dass wir einer Meinung sind ! :smile: (Geblankte ! und ? sind ein Markenzeichen von mir)
Michael
tokugawa
2006-11-12, 20:22:54
Was da momentan gemacht wird ist doch nur outline-rendering, cell-shading und darauf ausgelegte Texturen zu nutzen. Ich sehe kein Problem darin, das mittels eines Raytracers zu rendern. Für Outlines einfach bei bestimmten Eintreffwinkeln schwarz zeichnen, der Rest ist eh trivial und genau wie bei einem Rasterizer zu erledigen.
Da gibt's schon noch mehr Varianten...
Vor allem mit Shadern und via Postprocessing lässt sich da einiges anstellen, um diverse NPR-"Malstile" zu erreichen.
Da gibt's schon noch mehr Varianten...
Vor allem mit Shadern und via Postprocessing lässt sich da einiges anstellen, um diverse NPR-"Malstile" zu erreichen.
In Windwaker und XIII nicht und Postprocessing steht Raytracing sowieso nicht im Weg. Und "Shader" ist ein wenig arg unspezifisch ;) Gib mal ein Beispiel, mir fällt nämlich nix ein.
tokugawa
2006-11-12, 22:31:12
In Windwaker und XIII nicht
Wo hab ich geschrieben dass ich mich auf diese zwei Beispiele beschränke?
und Postprocessing steht Raytracing sowieso nicht im Weg.
Postprocessing an sich nicht, aber derzeitige Algorithmen "baken" oft eine Art "Fat Buffer". Klar kann man den auch mit Raytracing erzeugen, aber meistens ist das dann wie mit Kanonen auf Tauben zu schießen, da dieser Fat Buffer doch spezialisierte Informationen (Normals, Depth) enthält, der beim Rasterisieren ungemein schnell erzeugbar ist. Hier geht's nicht um Beleuchtungsinformationen, sondern tatsächlich um andere Per-Fragment-Parameter... bei Raytracing hast du hier immer noch den Offset des Raytracings...
Und "Shader" ist ein wenig arg unspezifisch ;)
Klar ist das unspezifisch, da es hier einfach recht viele Varianten gibt. Gemein sind den Varianten aber, dass sie alle vergleichsweise schnell auf Rasterizer-Hardware gehen (schneller als sogar "reguläre" Beleuchtungspasses auf Rasterizern), da sie eben keine Beleuchtung berechnen, sondern andere Oberflächen-Parameter, wo man ganz einfach nicht wirklich einen (Licht-)Strahl verfolgen muß. Wenn man so will ist es gewissermaßen eine Art Deferred Lighting/Shading.
Gib mal ein Beispiel, mir fällt nämlich nix ein.
Hmm, naja, NPR ist relativ jung und leider nicht Hauptforschungsgebiet der Echtzeitgrafik, aber wie gesagt, dieser Fat Buffer von oben ist etwas, wo man einfach viel geringere Information braucht als eine normale Beleuchtungsberechnung. Bei Rasterizern ist das gut nach unten skalierbar (einfachere Shaderprogramme), bei Raycastern hat man dann immer noch den Overhead - das ist eigentlich das Hauptargument: das Ziel bei NPR ist ja keine Simulation der Lichtausbreitung, sondern ein bestimmter künstlerischer Stil.
Ich denke da auch an diverse Verfahren, die etwa einen Wasserfarben oder Bleistiftzeichnungs-Look über das Bild ziehen, wo ebenfalls "Fat Buffer" verwendet werden. Sehr oft wird hier die Pseudo-Beleuchtung (inklusive diverser Perturbationen) erst im Image-Space durchgeführt.
Wo hab ich geschrieben dass ich mich auf diese zwei Beispiele beschränke?
Nirgends. Wollte nur ausdrücken, dass mich verwundert, dass sämtliche genannten Beispiele nicht von Belang sind.
Postprocessing an sich nicht, aber derzeitige Algorithmen "baken" oft eine Art "Fat Buffer". Klar kann man den auch mit Raytracing erzeugen, aber meistens ist das dann wie mit Kanonen auf Tauben zu schießen, da dieser Fat Buffer doch spezialisierte Informationen (Normals, Depth) enthält, der beim Rasterisieren ungemein schnell erzeugbar ist.
Also "nur" ein Geschwindigkeitsproblem? Das hat man beim Raytracing momentan ja sowieso generell, also egal ;)
Bei Rasterizern ist das gut nach unten skalierbar (einfachere Shaderprogramme), bei Raycastern hat man dann immer noch den Overhead - das ist eigentlich das Hauptargument: das Ziel bei NPR ist ja keine Simulation der Lichtausbreitung, sondern ein bestimmter künstlerischer Stil.
Raytracer kann man auch nach unten skalieren, indem man die Strahlen einfach nach dem ersten Treffer nicht weiterverfolgt und stattdessen was anderes rechnet.
Ich denke da auch an diverse Verfahren, die etwa einen Wasserfarben oder Bleistiftzeichnungs-Look über das Bild ziehen, wo ebenfalls "Fat Buffer" verwendet werden. Sehr oft wird hier die Pseudo-Beleuchtung (inklusive diverser Perturbationen) erst im Image-Space durchgeführt.
Finde ich beim Raytracing bequemer, da kann man sehr leicht quasi beliebig an der Beleuchtung rumspielen, ohne überhaupt erst einen "Fat Buffer" berechnen zu müssen.
Guten Abend zusammen,
mir persönlich fällt es schwer zu glauben dass Raytracing der heilige Gral der Computergraphik sein soll und zwar aus verschiedenen Gründen:
- Ich hab noch nirgendwo ein wirklich performantes Raytracing auf einem einzelnen Rechner gesehen, dass nicht im Briefmarkenformat war. Und von Antialiasing wollen wir da mal gar nicht reden. Und von Antialiasing a la CSAA schon überhaupt nicht. Aliasing sieht man dafür recht häufig, insbesondere bei Texturen sieht es während die Szene in Bewegung ist gar schauerlich aus, je nachdem wie hochfrequent die Texturen sind.
- Raytracing ist gut wenn es um Reflektionen und Refraktionen geht, da muss man nicht tricksen. Aber wenn es um weiche Schatten geht, oder realistische Materialien (ausser Lack und Glas) im Interieur bei denen umfangreiche Shadingalgorithmen ablaufen (triplanare Bumpmapper die ineinander blenden) da ist eine GPU um ein vielfaches effizienter.
- über richtig dynamische Szenen wollen wir erst mal gar nicht sprechen, es ist immer noch volles Forschungsthema, wie man die Beschleunigungsstrukturen, die Raytracing benötigt, dynamisch zur Laufzeit verändern kann.
- Es gibt viele Anwendungen z.B. im Marketingbereich, da möchte man nicht realistisch rendern, sondern sich die Szene so hintunen um den Kunden emotional anzusprechen (ich sage jetzt absichtlich nicht faken).
Natürlich hat Raytracing seine Daseinsberechtigung, keine Frage, aber alle wird es nie glücklich machen, genauso wie es Rasterisierung nie machen wird.
Das ist auch das was mich so an der Thematik begeistert, alles ist noch im Fluss, es ist immer spannend und man muss immer dazu lernen.
Matthias
PS: Ist Werbung hier erlaubt ? Falls nicht bitte löschen.
Wer Lust Ergebnisse eines nicht so schlechten Echtzeit- Rasterisierungsystemes für industrielle Anwendungen zu sehen kann auf der Hannovermesse mal am Stand von PNY vorbei schauen ...
MadMax@
2007-04-02, 17:20:40
So dan möchte ich doch mal meine etwas in den raum geworfene Ausage Preziesieren.
Warum ist Raytracing in Spielen nutzlos:
1.Sämtliche mit Raytracing erzielten effekte lassen sich problemlos auch mit einem rasterrizer erstellen (Spiegelungen,Brechungen,harte Schatten,Per Pixel Beleuchtung)
2.Ein Raytracer bringt leider nur die eine hälfte der GI nämlich den spekularen teil für den diffusen (und der ist imho fast wichtiger) braucht man ein völlig anders verfahren
3.Es gibt ja bekantlich unterschiedliche arten von raytracern der bekannteste davon ist der Whitted Raytracer,welcher zu gelich auch der einfachste ist.
Dieser Algo wird dan auch bei Echtzeit Raytracern angewand. Allerdings ist er sehr limitiert was die anzahl der Effekte angeht man kan z.b. nur harte Schatten,perfekte Reflexionen sowie Punktlichtquellen berechnen.
4.Es wurde gesagt das eine GPU Probleme damit hat mehr als ein paar Spiegelnde Objekte darzustellen. Das ist sicher richtig aber man darf nicht vergessen das ein Raytracer genauso mehr Berechnungszeit braucht je mehr Spiegelnde Objekte in der Scene sind.
5.Spiele Graphik braucht einfach nicht die Perfektion die Raytracing bietet für andere Anwendungen mag Echtzeitraytracing nützlich sein.
btw:
http://www.maxwellrender.com/
das ist ein spektraler raytracer und wen es gelingt sowas in Echtzeit zu berechnen revidiere ich meine Ausage.
MikeB
2007-04-02, 17:28:56
1.Sämtliche mit Raytracing erzielten effekte lassen sich problemlos auch mit einem rasterrizer erstellen (Spiegelungen,Brechungen,harte Schatten,Per Pixel Beleuchtung)
2.Ein Raytracer bringt leider nur die eine hälfte der GI nämlich den spekularen teil für den diffusen (und der ist imho fast wichtiger) braucht man ein völlig anders verfahren
Zu Punkt 1, in welcher Qualität? Gerade bei Spiegelungen und Brechungen ist der Raytracer überlegen.
Punkt 2, wenn du strikt zwischen RayTracing und RayCasting trennst, magst du Recht haben...
Warum muss Raytracing eigentlich gebasht werden? :confused:
Michael
Also die Qualiät der Spiegelungen reicht in der Regel aus da, wir von unsere Wahrnehmung aus nicht unbedingt ein perfektes Ergbniss brauchen sondern es reicht wen es nachvollziehbar aussieht.
Was du zu Punkt2 geschrieben hast verstehe ich nicht. Raycasting hat damit eigentlich gar nichts zu tun.
Ich werde jetzt versuchen genau zu erklären was ich meine in dem ich ein paar begriffe erkläre.
GI = Globel Ilumination = Globale Beleuchtung:
Jede Beleuchtungs berechnung die bei der Lichtberechnung auch noch andere Objekte einbezieht Beispiele sind unter anderem Raytracing und Radiosity.
Das Gegenteil ist lokale Beleuchtung hier wird zur Lichtberechnung nur das objekt und die Lichtquelle herangezogen, Phong Lightening ist ein Beispiel(wen auch nicht perfekt da Raytracing es auch benutzt)
spekulare Wechselwirkung:
Hier wird nur spiegelnde Reflexion betrachtet sprich das Licht trifft in einem Punkt auf und es ensteht genau ein reflektierender Strahl.
diffuse Wechselwirkung:
Hier betrachtet man den diffusen Teil der Reflexion im gegenteil zum vorigen wird hier nicht ein Strahl betrachtet sondern es werden Strahlen über einer Halbkugel ausgesendet.
--> spekular Spiegelungen Brechungen
--> diffuse Farbausblutung indirektes Licht
Also Raytracing ist mit Sicherheit ein Globales Beleuchtungsverfahren allerdings nur im spektralen Bereich wärend bei der Diffusen Beleuchtung nur ein lokales Modell verwendet wird.
Da Szenen aber naturgemäß eher aus diffusen den aus Spiegelden Objekten bestehen denke ich das Raytracing eher keinen großen Sprung in richtung Photorealismus ist(Natürlich nur bei Spielen).
Echtzeit Radiosity wäre was feines.
Ich will überhaupt nichts bashen das wäre doch etwas kindisch. Ich halte Raytracing für einen wichtiges Modell zu Photorealistischen Beleuchtung allerdings sehe ich die Anwendungsfelder von Echtzeitraytracing nicht im Bereich der Computer Spiele.
Für den Wirklichen Photorealismus müssen viele Faktoren zusammenspielen einen guten Raytracer(am besten einen spektralen) und einen Radiosity Engine. Nur wen beide zusammenarbeiten bekommt man gute Ergebnisse.
GI = Globel Ilumination = Globale Beleuchtung:
Jede Beleuchtungs berechnung die bei der Lichtberechnung auch noch andere Objekte einbezieht Beispiele sind unter anderem Raytracing und Radiosity.
Raytracing ist an sich keine GI-Lösung. Da braucht man noch zusätzlich Photon-Mapping o.Ä. was mindestens so teuer ist wie Radiosity.
Doch ist es aber diese Diskusion hatte ich schon ungefähr 100mal und sie hängt davon ab wie man GI definiert.
Nein ist es nicht. GI berücksichtigt indirekten Lichteinfall, was Raytracing an sich nicht ermöglicht. Dann müsste man auch Rasterizing zu GI zählen, weil's ja per Radiosity auch ein GI-Verfahren dafür gibt.
Das steht übrigens auch auf Wikipedia falsch.
GI == verfahren das nicht nur direktes Licht berücksichtigt sonder auch Licht das von anderen objekten abgestrahlt wird. Dabei ist es egal ob es Spekual oder Diffuse ist.
Rasterizing ist ja eigentlich auch kein Beleuchtungsverfahren sonder ein Render verfahren.
Das Problem an der Sache ist das die Definitionen überall anders verwändet werden.
Ich persönlich halte mich an die Definition von Alan Watt in
http://www.amazon.com/Computer-Graphics-3rd-Alan-Watt/dp/0201398559
Sie verwenden zur Einteilung der Algos so genante Lichtpfade:
L=Lichtquelle, D=diffuse Fläche, S= spekulare Fläche, E= Auge
--> Raytracing = LD(S)*E
--> Radiosity = LD*E
--> Phot Mapping = L(D|S)*E
--> lokale beleuchtung = L(D|S)*E
jedes verfahren das Lichtpfade der länge > 3 darstellen kan ist nach deren definition global.
Du meinst weil Raytracing Spiegelungen zulässt? Na gut, dann hast du gewissermaßen recht. Aber was die Mehrheit unter GI versteht (und was es imho auch ausmacht) ist ja ganz klar das indirekte diffuse Licht.
Keine Ahnung was du mit deiner Definition bezwecken willst, aber viel helfen tut es Raytracing nicht den Rang eines "GI-Verfahrens" zu haben ohne die wirklichen Vorteile eines solchen zu besitzen.
Im prinzip ist halt ne Definition Sache wen man sagt GI = indirektes Licht hast du recht aber eigntlich spielt das ganze keine Rolle. Der Kern der Sache ist einfach raytracing allein kan kein indirektes Licht Berechnen und damit fehlt etwas das sehr zum stimmigen Bildeindruck gehört.
MikeB
2007-04-02, 20:49:18
Eine sehr gängige Technik für "GI" ist Raycasting, von jedem Pixel wird Igel-förmig ein Haufen Strahlen losgeschickt. Dies ermöglicht sehr effizient indirektes Licht ersten Grades und "Ambient occlusion" auf Skylight oder "image based lighting". Wenn man diesen Strahlen Reflektion erlaubt, hat man auch Spiegel die Licht werfen.
Damit ist Raytracing definitiv GI-fähig.
Michael
Ja und mit Radiosity ist Rasterizing GI-fähig. Das ist genauso "effizient". Und jetzt?
MikeB
2007-04-02, 21:01:26
Und jetzt?
Nichts.
Ich hoffe nur diesen Satz "Raytracing kann kein GI" weniger oft lesen zu müssen.
Insbesondere da ja manche GI-Routinen intern Raytracing/Raycasting benutzen...
Die Zukunft wird zeigen was Raytracing noch bringt. Es von vornherein für Spiele auszuschliessen halte ich für kurzsichtig. Wo wäre Rasterizing heute ohne dedizierte Hardware wie GPUs?
Michael
Ich hoffe nur diesen Satz "Raytracing kann kein GI" weniger oft lesen zu müssen.
Reines Raytracing kann auch kein GI. Genauso wie reine Rasterisierung es nicht kann. Und beides wird auch auf einmal durch GI genauso langsam.
Insbesondere da ja manche GI-Routinen intern Raytracing/Raycasting benutzen...
Ja. Und andere Rasterizing. Auch egal.
Ich möchte weniger oft lesen müssen, dass Raytracing was das angeht irgendwie besser dasteht als ein Rasterizer. Ist einfach nicht so.
Die Zukunft wird zeigen was Raytracing noch bringt. Es von vornherein für Spiele auszuschliessen halte ich für kurzsichtig. Wo wäre Rasterizing heute ohne dedizierte Hardware wie GPUs?
Was schließe ich denn aus? Ich sehe bisher allerdings einfach zu wenige Vorteile und viel zu viele Nachteile.
MikeB
2007-04-02, 21:14:35
Coda, das ging kein bischen gegen dich, nur gegen die "Raytracing taugt nicht die Bohne".
Eigentlich bin ich fast mit dir einer Meinung, lasst uns einfach schauen was die Zukunft bringt, vielleicht wird das Problem mit nicht statischer Geometrie noch gelöst, dedizierte Hardware dazu entwickelt (die nicht so "floppt" wie PhysX)...
Michael
Wenn man drüber nachdenkt gestaltet sich das mit der dynamischen Geometrie zumindest mit der heutigen Grafikpipeline als sehr schwierig (Vertexshader und Geoshader können Vertices an beliebiger Position in der Szene ausgeben). Man müsste nach jedem Durchgang des Vertexshaders den Scene-Tree updaten. Dass das nicht geht sollte klar sein. Verzögertes Updaten ist evtl. möglich, aber dann müsste man die Vertexberechnungen vorziehen und es ist mit GS nicht abzuschätzen wieviel Geometrie erzeugt wird und damit auch nicht wieviel Speicher dafür als Cache benötigt wird. Abgesehen davon macht das natürlich partielle Updates sehr schwierig.
Und ich bin mir nicht sicher, ob die Entwickler bereit sind da nach dem D3D10-Zeitalter Kompromisse einzugehen.
Ich glaube was viele Leute die in der Branche arbeiten (und das durchaus ziemlich hart) ziemlich annervt ist die Art und Weise wie die PR zu diesen Themen betrieben wird. Klingt immer so als ob ein bahnbrechender Durchbruch erreicht wurde und alle anderen Verfahren nur fieses völligst unrealistisches Rumgetrickse ist.
Wenn man drüber nachdenkt gestaltet sich das mit der dynamischen Geometrie zumindest mit der heutigen Grafikpipeline als sehr schwierig (Vertexshader und Geoshader können Vertices an beliebiger Position in der Szene ausgeben). Man müsste nach jedem Durchgang des Vertexshaders den Scene-Tree updaten. Dass das nicht geht sollte klar sein. Verzögertes Updaten ist evtl. möglich, aber dann müsste man die Vertexberechnungen vorziehen und es ist mit GS nicht abzuschätzen wieviel Geometrie erzeugt wird und damit auch nicht wieviel Speicher dafür als Cache benötigt wird. Abgesehen davon macht das natürlich partielle Updates sehr schwierig.
Und ich bin mir nicht sicher, ob die Entwickler bereit sind da nach dem D3D10-Zeitalter Kompromisse einzugehen.
Raytracing benötigt eine räumliche Szenen-Datenstruktur (Spatial Database) um effizient zu sein. Das heißt allerdings nicht dass man eine solche Datenstruktur bei einer auf Rasterisierung basierenden Engine nicht gebrauchen könnte, im Gegenteil. Da sich das gleiche Problem bei der Physikberechnung stellt (letztlich gehört ja auch Rendern in diese Kategorie), muss man hier sowieso Lösungen finden. Bounding Volumes für die dynamische Geometrie braucht man ja häufig, und diese will man sicher auch nicht aus dem VS-Output jeweils neu berechnen.
Shaderflexibilität ist wichtig, keine Frage. Innerhalb einer bestimmten Engine kann man diese aber durchaus sinnvoll begrenzen, z.B. als Positionstransformation nur MVP, Skinning und Displacement Mapping sowie im GS nur bestimmte Subdivision Surfaces zulassen. Es ist auch fraglich ob man für Raytracing die D3D10-Pipeline so überhaupt will.
Moralelastix
2007-04-03, 14:51:22
Intel hires Quake 4 Ray-Trace guy
http://uk.theinquirer.net/?article=38688
micki
2007-04-03, 14:55:26
Reines Raytracing kann auch kein GI. Genauso wie reine Rasterisierung es nicht kann. Und beides wird auch auf einmal durch GI genauso langsam. wieso sollte Raytracing das nicht koennen? ich hab schon einige raytracer implementiert die GI berechnet haben, ich wueste nicht weshalb das nicht gehen sollte.:confused:
Spasstiger
2007-04-03, 15:25:35
Intel hires Quake 4 Ray-Trace guy
http://uk.theinquirer.net/?article=38688
Ui, da hat sich [Win] Elchtest alias Daniel Pohl aber ganz schön gemacht. Ich weiß noch, dass er vor ein paar Jährchen als ganz normaler Doom- und Quake-Zocker auf den einschlägigen Seiten (quake.de, doom3maps.org) unterwegs war. Mit dem Q3-Raytracing hat er dann schon eine gewisse Berühmtheit erlang. Und jetzt geht er frisch von der Uni ab und ist gleich bei einem der Big Player in der Branche unter Vertrag. :)
Moralelastix
2007-04-03, 15:31:51
Ui, da hat sich [Win] Elchtest alias Daniel Pohl aber ganz schön gemacht. Ich weiß noch, dass er vor ein paar Jährchen als ganz normaler Doom- und Quake-Zocker auf den einschlägigen Seiten (quake.de, doom3maps.org) unterwegs war. Mit dem Q3-Raytracing hat er dann schon eine gewisse Berühmtheit erlang. Und jetzt geht er frisch von der Uni ab und ist gleich bei einem der Big Player in der Branche unter Vertrag. :)
Ja ja die bösen Killerspieler wieder! :biggrin:
MadMax@
2007-04-06, 00:53:41
wieso sollte Raytracing das nicht koennen? ich hab schon einige raytracer implementiert die GI berechnet haben, ich wueste nicht weshalb das nicht gehen sollte.:confused:
Das liegt dran das Coda GI mit indirekter Beleuchtung gleichsetzt was aber nicht wirklich die Definition von Gi ist.
GI ist und bleibt einfach das Gegenteil von LI
GI = Globale Beleuchtung
LI = Lokale Beleuchtung
Ja, aber die Möglichkeit Spiegelungen zu erzeugen als globale Beleuchtung zu sehen ist nun wirklich arg verquer. Ich hab's schonmal gesagt: Raytracing als GI zu definieren, ohne dass es die eigentlichen Vorteile davon hat ist reine Pedanterie (oder man will was schön reden :rolleyes:)
Wenn man von GI redet meinen 99% der Leute mindestens vorhandene diffuse Interreflexion, und das hat man mit Raytracing weder schneller noch einfacher als mit Rasterizing.
wieso sollte Raytracing das nicht koennen? ich hab schon einige raytracer implementiert die GI berechnet haben, ich wueste nicht weshalb das nicht gehen sollte.:confused:
Ich hab's extra kursiv geschrieben: Reines und vor allem schnelles Raytracing. Kein Photon Mapping, o.ä.
Wir reden hier von interaktiven Szenen und nicht von Offline-Rendering.
ScottManDeath
2007-04-06, 10:53:09
Zu Raytracing vs. GI: Adjoint Photons (http://www.cs.utah.edu/~shirley/papers/gi06.pdf)ist recht einfach zu implementieren, braucht aber als Monte Carlo Integration (http://en.wikipedia.org/wiki/Monte_Carlo_integration)welches Raytracing zum samplen der Rendering Equation (http://en.wikipedia.org/wiki/Rendering_equation)nutzt pervers viele Samples um zu konvergieren. Allerdings hat man dann GI out-of-the-box =) Damit dies in Echtzeit möglich ist, müssen noch viele Core Generationen ins Land gehen ;)
Raytracing (ohne GI) hat Vorteile, wenn man z.B mehrere GB grosse Datensätze (http://www.sci.utah.edu/~wald/Publications/2006///Aerospace/download//aerospace.pdf) rendern will, die weder in den RAM noch VRAM passen. Dies ist ungleich schwerer mit einem Rasterizer zu machen.
Aber für Spiele & Co, da hab ich für die nächsten Jahrelieber ein G80/R600 Rastermonster =), insbesondere da man damit auch spiele taugliche GI Approximationen (http://www.fantasylab.com/newPages/FantasyEngineFeatures.html) bauen kann. Siehe dazu auch GPU Gems 2 Kapitel 14 ;)
mickii
2007-04-06, 19:18:11
Wir reden hier von interaktiven Szenen und nicht von Offline-Rendering.das war mir nicht so klar so verallgemeinert wie das hier beredet wird... hmm.. wenn ich mal zeit hab werd ich das mal in echtzeit probieren.
Raytracing (ohne GI) hat Vorteile, wenn man z.B mehrere GB grosse Datensätze (http://www.sci.utah.edu/~wald/Publications/2006///Aerospace/download//aerospace.pdf) rendern will, die weder in den RAM noch VRAM passen. Dies ist ungleich schwerer mit einem Rasterizer zu machen.ich behaupte mal das gegenteil, mit simplen rasterizern kann man sowas viel besser realisieren als mit raytracern die random irgendwelche datensaetze von der platte fischen.
Aber für Spiele & Co, da hab ich für die nächsten Jahrelieber ein G80/R600 Rastermonster =), insbesondere da man damit auch spiele taugliche GI Approximationen (http://www.fantasylab.com/newPages/FantasyEngineFeatures.html) bauen kann. Siehe dazu auch GPU Gems 2 Kapitel 14 ;)wenn sogar die teuersten und zeitaufwendigsten rendersysteme vieles approximieren, wird das natuerlich auch bei spielen so gemacht.
Daniel Pohl hat für Intel auf dem IDf in China Q4 laufen lassen:
http://www.theinquirer.net/default.aspx?article=39101
...das waren sicher noch zeiten:
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.