Bericht: Ray-Tracing „4.0“

[Felixxz21]

Haha, oh man ihr bekommt echt den Preis für die unwissendsten und dümmsten Posts des Monats, ich mein wisst ihr überhaupt was RT ist oder habt geshweige denn den Artikel gelesen? Nicht? Warum postet ihr dann?

TT:

Finde die Entwicklung sehr interessant und RT greift eben genau dort an wo momentan der Realismus noch nicht gegeben ist, nämlich bei Licht und Reflexionen und hohe Polygonzahlen, was man IMO ja mit Tesselation lösen will.

Hoffe mal auf kaufbare Grakas un vor allem, dass die hersteller sich absprechen und alle neuen Konsolen auf Basis von Raytracing erscheinen, dann viell. Nextgen Knights Corner mit über 100 Kernen bzw. 400 Threads!

[Vidy_Z]

Du hast es nicht verstanden oder? In D.P.´s Wolfenstein ist alles gerastert bis auf die Spiegelungen und Refraktionen selber. Und das was du in den Spiegelungen und Refraktionen siehst, ist wiederum auch nur die gerasterte Umgebung. Für ein realistisches Ergebnis, müsste D.P. nicht nur die paar Ausnahmeoberflächen durch seine Engine jagen, sondern jede einzelne Fläche die in der Szene vorkommt. Anscheinend besitzt diese Berechnungsdemo dafür aber keinen Algorithmus. Das Problem wird einfach der Wolfensteinengine überlassen. 97% des Bildes werden also nach wie vor mit der neun! Jahre alten und überfälligen Wolfensteinengine erzeugt, und das ist auf die Dauer doch ziemlich ernüchternd. Von Realismus natürlich keine Spur. Aber einfach mal die 3% Spezialfälle rauspicken und dann behaupten das sei nun ein Leuchtpfad der Zukunft weil ja Ray Trace. Und das wird dann allgemein auch noch übernommen!

Der Ansatz den D.P. fährt, wurde von Offlinerenderern bis ca. 2003 forciert. Seit dieser Zeit setzen sich Rendersysteme durch, die Szenerien als Ganzes begreifen, die jedes Objekt als „spiegelnd“ beschreibend und in die Bildkalkulation mit einbeziehen. Denn jedes Objekt das man sehen kann, spiegelt auch Licht ins Auge des Betrachters, sonst wäre es tiefst tiefst schwarz. Es steht nicht mehr zur Debatte ob, sondern nur noch wie das Objekt spiegelt, konkret: wie stark und wie "verschwommen", oder besser diffus, das Licht zurück in den Raum geworfen wird.

Allein schon die diffuse Spiegelung stellt eine große Herausforderung dar. Denn entgegen dem was man so annehmen würde, nimmt der Rechenaufwand bei einer verschwommenen Spiegelung nicht ab, sondern zu, und zwar immens! Denn ein verschwommenes Bild baut sich aus mehreren Teilspiegelungen auf, die alle einzeln erzeugt werden und aus denen dann eine Schnittmenge berechnet wird. Je mehr Teilspiegelungen, desto besser das Ergebnis!

Hinzu kommt natürlich das Licht das von Objekten auf andere Objekte fällt. In einem Innenraum etwa, macht das den Großteil der Beleuchtung aus. Ein Riesenproblem! Eine Rasterengine ignoriert diesen Umstand einfach weg und weist da mal eben jedem Objekt eine Grundfarbe zu. Das ist in etwa vergleichbar mit "Malen nach Zahlen", und dieser plumpe Ansatz lässt auch die Wolfensteindemo so armselig, so aufgesetzt, so gemalt und unecht erscheinen (Rasterengines „berechnen“ nicht, sie klatschen einfach einen einheitlichen Farbton drauf, sie „malen“). Schwer zu beschreiben, muss man sehen:
mit indirektem licht: ohne indirektes Licht:


Ich denke, wenn das Reflektions/Refraktions-Wolfenstein/Quakewars Plugin in seiner jetzigen Form tatsächlich mit all den für eine akkurate Darstellung benötigten Berechnungen belastet würde, dann wäre die Darstellung unter Umständen langsamer als die von so manchem Offlinerenderer. Denn es findet überhaupt keine Auseinandersetzung mit der eigentlichen Problematik statt, und in Folge dessen existieren auch keine Lösungsansätze für die riesigen Herausvorderungen, sprich: keine Lösung für die 97 anderen Bildprozente, ohne die ein Spiel genauso unglaubwürdig wirken wird wie eh und je, selbst wenn D.P. seiner speziellen Spiegelungsproblematik mit einer unendlichen Rechenleistung beikommen könnte.

James Kajiya haben wir dieses elegante Formelwerk zu verdanken:



Es nennt sich die Rendergleichung, und diese übersetzt die vollständige Lichtwirkung jedes Raumobjekts einer Szene in eine 2 dimensionale Darstellung. In ihr enthalten sind darüber hinaus auch alle schon existierenden Berechnungsansätze, ob Radiosity(ursprünglich aus der Wärmelehre) oder Ray tracing via Monte Carlo oder Metropolis Light Transport. crazy stuff!

Es geht ja nicht darum das Rad neu zu erfinden, aber die Herausforderung besteht doch darin, diese Formel oder eines ihrer Derivate so geschickt herunter zu brechen und so trickreich an die Hardware anzupassen, dass schließlich eine flüssige Bewegtbilddarstellung herauskommt, oder sehe ich da was falsch?

Also dafür eine Lösung bitte! Und wenn dann noch der Fall einer 100%tigen Spiegelung dazukommt, dann sieht das erst richtig fett aus!


Ergänzung zum Cloudrendering

Was das Cloudredering betrifft, so denke ich, dass dieses für eine echte GI Berechnung umso attraktiver erscheint. Alle von D.P. aufgeführten Punkte treffen zu, auf eine vollständige Lichtberechnung sogar fast noch eher! Warum?

Theoretisch lässt sich eine einmal erzeugte Renderlösung in den Szenentexturen speichern (Texturbacking). In diesem Sinne würde man die komplexe indirekte Lichtberechnung nur einmal pro Frame durchführen, mit einer äußerst fetten Renderfarm oder auch gerne Cloud, und zwar über die komplette Szenerie. Ein Client würde sich aber nur genau die Texturen, Texturabschnitte oder Texturupdates herunterladen, die in seinem Sichtwinkel erscheinen. Das würde nicht nur einem heutigen System die Möglichkeit verschaffen, solche Bilderwelten überhaupt das erste Mal in Echtzeit zu erleben, es würde sogar eine Menge Rechenleistung sparen, da sich nur noch ein einziges System um die Lösung der Rendergleichung und zwar stellevertretend für alle angeschlossenen PC´s gleichzeitig zu kümmern braucht. Um Bandbreite zu sparen, und da sich z.B. Spiegelungen ohnehin von jedem Betrachterstandpunkt unterschiedlich darstellen, könnten solche und ähnliche Effekte wiederum lokal berechnet werden, auf den Client Systemen, die durch die Vorarbeit der Cloudrechner entlastet sind und mehr Rechenleistung für Berechnungen wie die Spiegelungen und Refraktionen von D.P. übrig haben. Gegebenenfalls baut man halt noch eine der genannten Intel-Beschleuniger-Karte ein.

Die Geometrie würde man ebenfalls lokal berechnen, denn damit würde man sich wesentlich unabhängiger von der Bandbreite machen, sprich: wenn sich nur die aktualisierten GI-Texturen um 200ms verspäten, dann ist das durchaus noch vertretbar.
Wenn ich mir nur ausmale, wie man sich in einem Spiel fühlen muss, bei dem man tatsächlich den Eindruck hat, an einem wirklichkeitsechtem Geschehen wie durch eine Videolifeschaltung teilzunehmen, etwa in Form eines vollständig getraceten Portals oder eines UTs, dann könnte ich mir sehr gut vorstellen, dass das einschlagen würde wie eine Bombe. Ich hoffe, dass ich mich einiger Maßen verständlich ausgedrückt habe.

Als Beispiel für den Stand der Dinge bei den Production Renderern, hier ein Youtube Clip des Arion Renders. Zwischen den Bildern fallen die Wartezeiten von bis zu mehreren Sekunden auf, welche die Beschleunigerkarten(in der Regel 2-3 Stück bei solchen Produktdemos) benötigen, um das Licht nachzuführen. Genau diese Wartezeiten könnte eine entsprechend dimensionierte Claud doch auf Framelänge drücken, so das etwas wie das hier bei raus kommt. (Den Arion Render kann man sich soviel ich weis sogar als Demo runterladen um ein bisschen damit rumzuspielen. Da wünscht man sich dann einen leisen GPU-Lüfter. Denn diese Engines werden früher oder später alle über OpenCL laufen, also auf ATI Nvidia oder auf Intel. Bin sehr gespannt wie die Intelkarte performt.)

[Foxel]

Arion render? is das mal wieder eine kopierte Version der GPU variante von LuxRender (opensource) ? xD

Nutzt lieber den lux das is der selbe Render for free und den gibt es schon lange mit OpenCL ...

Hier mal ein Video von mir was ich damit gerendert habe in 5 Minuten auf einer gtx280

Video abspielen

hab auch noch mehr Videos auf meinem Channel


hier noch andere videos:

Video abspielen

Video abspielen

Video abspielen

Video abspielen

[Vidy_Z]

Ja cool, auch gleich via nem Citygenerator :-). Arion...Lux? Ich glaube Arion ist schon was eigenes, ist aber auch nicht so wichtig, Hauptsache es geht voran :-).(Vom Lux habe ich mir gestern glaub den Bench runtergelande, ist das ein spezieller Renderer für Blender? Die OpenCL Renderer schießen ja gerade wie Pilze aus dem Boden, da blickt man ja kaum noch durch!)

Nette Videos auch. Ich kann´s halt wirklich kaum abwarten, bis so etwas mal wirklich flüssig in RT läuft, bei Spielen muss das der absolute Bringer sein.

PS: Wäre überhaupt sehr schön, wenn CB einen OpenCL Bench in seinen Graphikkartentestparkur aufnehmen würde.

[Foxel]

Also Luxrender gab es glaube ich zuerst. Bin auch so ziemlich seit den ersten Betas dabei.
Sicherlich ist der Arion jetzt was eigenes, aber der code stammt definitiv aus lux, da auch die gezeigte Szene mit dem Klassenzimmer aus Luxrender kommt. Es gibt auch eine menge anderer neuer Render die auf LuxRender basieren, Arion ist da nicht der Einzigste ^^

Es gibt übrigens auch schon ein OpenCL Bench von LuxRender der ist allerdings, genauso wie lux, noch in der beta Phase und nennt sich LuxMark
Mann muss glaube ich im forum angemeldet sein um ihn zu bekommen: http://www.luxrender.net/forum/viewt...hp?f=34&t=5439

Der LuxRender ist übrigens für alle gängigen 3D Programme erhältlich aber für Blender am besten angepasst ^^
http://www.luxrender.net/en_GB/download

hier mal paar Bilder von mir:








größere Bilder gibt es hier von mir: http://storkner.deviantart.com/gallery/


Wie wird eigentlich die Spiegelung in Racing-Games berechnet? Da werden ja in einigen Games auch schon andere Fahrzeuge darin gespiegelt.


Ich hab auch ne Licht-Engine gefunden die global illumination in realtime schafft.

Video abspielen

Da es diese Technik (Radiosity) schon länger gibt, denke ich das sich es sich eher dahin entwickelt. Und Half-Life2 das ja indirekt auch schon hatte nur das das Licht statisch beim compilen der maps berechnet wurde.

Wer weis vlt. überrascht uns ja das nächste Half-Life mit dieser Technik =)


EDIT: wie geil Battlefield 3 wird dem schon voraus kommen sie nutzen die Radiosity Engine

Video abspielen

[ix.tank]

Dann werfe ich mal meinen Shader Model 4.0 (DirectX) Raycaster in den Raum, dieser schafft Volumen-Rendering/Raycasting bis zu 512x512 in Echtzeit. Man kann also sehen es geht eigentlich alles in diese Richtung, und ich tippe mal das es nicht mehr lange dauert bis Raycasting oder Raytracing wenigstens partiell in Engines benutzt wird. Denn Photon-Tracing oder Volumen-Rendering geht nunmal mit einem Scanline-Renderer nicht wirklich.

GPU-Ray - http://www.youtube.com/watch?v=JrX-2fIXigg

GPU-Ray ist auch ein Hybrid-System die Szene wird klassisch gerendert und das Volumen wird über Raycasting eingebettet. (Dazu rendert der Raycaster die ganze Szene in einer etwas niedrigern Auflösung aber ohne Effekt nur zur "Kollisionsbestimmung"). Es wird sogar eine klassische Shadow-Map in das geraycastet Volumen projiziert. Also "hybrid" wird wohl dem nächst sehr in Mode kommen.

[Vidy_Z]

@Foxel
Hey, du bist ja gut dabei . Wenn du dich ein oder zwei tage geduldest, ich glaube ich muss auch mal so ein deviantart Konto einrichten, ich würde dir nämlich gerne mit ein paar Bildern von mir antworten. Schön, hau weiter rein! .

Bei klassischen Scannline(oder Raster-)Games ist zumindest die eine Methode von der ich weiß die, die Geometrie einfach in der Spiegelfläche (spiegelverkehrt natürlich) nach zubauen.

Ja, die Enlightengine! Die gibt es sogar schon seit 2007 oder 2008, ich bin aber nicht sicher ob das wirklich Radiosity ist. Echtes Radiosity ist zwar sehr prazise, aber auch extremst rechenintensiv und damit langsam. Der Begriff selber wird aber nicht selten und dann fälschlicher Weise auch für andere GI-Verfahren verwendet. Keine Ahnung warum sich die Spieleschmieden so zieren. Das einzige wirklich GI artige Spiel mit einer gewissen Verbreitung ist bisher nur
Mirrors Edge. Ich meine aber dieses Spiel stützt sich auf eine Ambient Occlusion Technik. Das ist natürlich keine echte GI, sondern nur ein Fake, aber ein ziemlich guter Fake.

Was diese Frostbyte engine betrifft, da hats mich jetzt gerade mal vom Hocker gehauen. Die ist ja abgefahren! Ist dir aufgefallen, dass in dem Demo keine einzige Spiegelung vorkommt? Ist nicht schlimm, ist nur interessant, ist wohl der Performance geschuldet. Bei dieser Engine ist jetzt natürlich die brennendste Frage, die nach der verwendeten Hardware. Die sieht fast schon zu gut aus, als dass man glauben könnte, da sei nur ein schneller PC am Werk gewesen. Und du meinst diese Engine ist im neuen Battlefield 3 eingebaut? Ich würde mir das Spiel nur wegen dem Renderer kaufen .

@ix.tank
Vor jemandem der solche Dinge selber programmiert, da ziehe ich meinen Hut! Klar, ist jetzt mal was anderers als GI, aber ein extrem wichtiger Bestandteil für viele Szenen. Außerdem sieht das sehr sauber aus was du da gezaubert hast. Wo genau greift den die OpenCL Engine, in der Kollisionsbestimmung?

[Foxel]

Bei Mirrors Edge (Unreal Engine 3) wurde auch Radiosity benutzt aber das wurde vorher statisch für die Map berechnet. So wie in der Source Engine also leider kein realtime radiosity.

Ja Battlefield 3 benutzt die lighting Engine =)

Und ja kannst mir gerne Bilder zeigen ich add dich dann auch da auf deviantArt

[Vidy_Z]

Sehr fein, ich schicke dir ne Nachricht, nen Link und freue mich auf deinen Kommentar . Also bis dann!

[ix.tank]

Echtes Radiosity ist zwar sehr prazise, aber auch extremst rechenintensiv und damit langsam. Der Begriff selber wird aber nicht selten und dann fälschlicher Weise auch für GI verwendet.

Nur damit keine Missverständnisse bei anderen(Themen-Fremden) Aufkommen: Radiosity ist ein GI-Verfahren, allerdings nicht jedes GI-Verfahren ist Radiosity. (Raytracing mit Photon-Tracing ist eine GI Alternative.)

Wo genau greift den die OpenCL Engine, in der Kollisionsbestimmung?

Ist noch nicht mit OpenCL gemacht (da es aus 2009 war), damals war OpenCL noch nicht ausreichend verbreitet. Ich hab GPU-Ray mit HLSL(DirectX 10) geschrieben. Der Raycaster ist also ein Pixel-Shader-Programm. Und die Optimierungsalgorithmen auch. Alle Polygondaten und Datenstrukturen(Octrees) müssen dazu in Texturen geschrieben werden. Dazu kommen noch jede Menge andere Restriktionen, die mit CUDA oder OpenCL oder Compute-Shadern inzwischen nicht mehr existieren.

So zu deiner Frage . Die Volumen sind durch Polyeder begrenzt, also gibt es keine Partikel, der Raycaster erzeugt dann für jedes Pixel eine Schnittpunktliste (Eintritts und Austrittspunkte aus den verschiedenen Volumen und einen Endpunkt falls der Raycaster auf etwas solides trifft). Zwischen den Schnittpunkten kommt dann Volumen-Sampling zum Einsatz (mit 3D-Textur) und dabei wird dann für jeden Sampling-Schritt die Shadow-Map mit berücksichtigt(damit kann man dann sehr gut dynamisches und präzises volumetrisches Licht erzeugen). Inzwischen ist schon wieder viel mehr möglich. Hab schon extrem viele Ideen zur Weiterentwicklung und hoffentlich demnächst wieder Zeit dafür

[Vidy_Z]

Nur damit keine Missverständnisse aufkommen....

hab´s korrigiert, danke.

Ich bin kein Wissender was Shaderprogrammierung angeht, aber ich habe schon mitbekommen, dass es einigermaßen umständlich und frickellig sein muss, darin zu programmieren, einfach weil John Carmack und andere Entwickler immer wieder gerne darüber fluchen :-). Ein schöne Arbeit, an der sich so einige Spiele eine Scheibe abschneiden könnten.

Wenn ich das richtig verstanden habe, baust du deinen "Rauch" als einen Polyederkörper auf, um dann zu verfolgen, wo dein durch die Shadowmap gefilterter Lichtstrahl in den Körper ein- bzw. aus im ausdringt. Die Shadowmap ergibt sich aus der Geometrie, du kannst sie aber nach Wunsch auch anderswertig manipulieren, was dann wiederum zu allerlei coolen Auswirkungen auf das Innere des Rauchs führt, in welchem du die Pixel ja weiterhin beobachtest und steuern kannst. Erinnert mich an das Vorgehen bei Max, bloß halt ohne die mundgerechten Max-Menüs, sondern zu Fuß . Ich glaub gerne, dass sich mit eingängigeren Sprachen wie OpenCL und Cuda die Möglichkeiten vereinfachen und vervielfachen und wünsche dir jede Menge Spaß dabei :-).

[ix.tank]

Jep, haut ungefähr so hin und thx .

Ich denke, dass in Zukunft flexible Echtzeit-Raytracer die Basis für viele neue Effekte darstellen. Und auf lange Sicht wahrscheinlich die alten Renderer ganz ablösen. Daher sehe ich die "Grundlagenforschung" von Intel oder auch Nvidia, etc. sehr positiv, auch wenn sie jetzt noch nicht die Grafikpracht bringen, die sich einige hier wünschen oder noch nicht ganz in Echtzeit laufen (z.Bsp. Nvidia Design Garage - die würde ich gern mal auf nem GTX 580 Triple SLI System sehen das könnte fast reichen). Es ist noch kein Meister vom Himmel gefallen und beim Thema Echtzeit-Raytracing fangen jetzt alle klein an.