[Suche] Mitstreiter für Realtime Raytracing Engine

[Lord Delvin]

Anm.: Die Sache ist gestorben. Ich hab keine Lust mehr mich alleine mit so viel Zeug rumzuschlagen, das ich dann nichtmal selbst weiter verwende, weil ich niemals die Zeit hätte was schönes mit zu machen. Falls aber jemand seinen eigenen Raytracer starten will kann er sich gerne mal bei mir melden, vielleicht hab ich ja noch n paar gute Ideeen. Man lernt doch ne Menge in 1.5 Jahren:)

Das Folgende ist noch in Arbeit, Kommentare sind aber erwünscht; wenn ich das Gefühl habe, dass es Ausgereift ist, also dass ich wirklich weiß, was ich machen will und das es so funktionieren wird, dann werde ich den Text weiter verteilen um mehr Menschen zu erreichen, als nur die Leser dieses Forums:)

Meine Motivation
(keine)

Eure Motivation
Ihr habt bestimmt schon mal was von den Intel Raytracing Demos gehört oder gesehen; dem ein oder anderen sagt sicher auch Arauna oder Realstorm was. Vielleicht hat euch auch überzeugt, was ich so produziert hab, vermutlich aber nicht.
Ansonsten kann ich noch youtube videos zu Quaternion Julia, Sparse Voxel Octrees oder Raytracing im allgemeinen empfehlen.
Der Punkt ist eigentlich, eine Alternative zu Rasterizern zu schaffen, die in der Lage ist Schatten, Reflexionen, ... in einfachen Situationen schöner darzustellen.
Außerdem lernt man einfach viel über Computer Grafik, Paralleles Programmieren, Softwarearchitektur, Teamarbeit, etc.

Was ich von euch erwarte
-Zuverlässigkeit
-ZUVERLÄSSIGKEIT, d.h. wenn ihr sagt ihr übernehmt eine Aufgabe, dann übernehmt ihr sie auch, oder meldet euch rechtzeitig ab.(wenn mal was dazwischen kommt, kein Thema, wir sind alle Menschen)
-für Programmieraufgaben: Sicheren Umgang mit der jeweiligen Sprache
-sicheres Englisch für Code & Kommentare
-sicheres Deutsch für Kommunikation mit anderen Teammitgliedern
-Regelmäßige Teilnahme an Besprechungen; ich plane atm. einmal pro Woche eine kurze Zusammenfassung aller Teammitglieder(ts, skype, wird man sehen) über das, was sie die letzte Woche so getrieben haben, weil es einfach motiviert und weil man viel effizienter arbeitet.

Tech
-Codepaths / Rechnerarchitektur(en):
Es wird eine offene Architektur entwickelt, die es erlaubt auf vernünftige und effiziente weise einzelne Pipelinestufen getrennt zu implementieren, d.h. es kann letztlich jede Stufe auf der GraKa oder der CPU gerechnet werden.
-Raytracing an sich:
Es wird wieder Rekursives Raytracing aus der Bildplane heraus werden. Alles andere ist meines Wissens für Realtime ungeeignet. Daraus ergeben sich dann die bekannten vor und nachteile, wie teure Softshadows, Absens mancher in Raytracern üblicher Spielereien.
Es wird einen inneren Frame geben, in dem das aktuelle Bild in einem Out of Order Verfahren berechnet wird. Das führt dazu, dass zwischen dem aktuell sichtbaren Bild und dem, welches gerade vorbereitet wird, wie bei GraKas auch genau ein Frame unsichtbar dazwischen liegt. (Das war bei APE 0.3 nicht so, daher auch manche der Artefakte) Das erlaubt aber auch, dass man Raypacks und Batchprozesse verwenden kann, ohne das jemand auserhalb des Cores was davon mitbekommt, d.h. es wird für den Endnutzer der lib nicht komplizierter.
Um das einigermaßen Performant hinzubekommen, ist geplant Rays oder Raypackages an Knoten im SceneGraphen zu pinnen, die dann selbstständig von Workerthreads abgeholt und mit einer optimierten Batchfunktion komplett alle bearbeitet werden. Der vorteil davon ist, dass man sich diverse load/store Operationen spart, weil man gegen das gleiche Objekt testet; außerdem ist das für die Prozessorpipeline viel netter.
UserRays, die manche Rayattribute auf const setzen, damit man sich verlassen kann, das Shader diese nicht ändern; leicht über cast operator zu realisieren.
Weitere Details spar ich mir hier mal.
Mit einfachen Mutexen wird sichergestellt, dass sich einzelne Pipelinestufen nicht im weg stehen, so dass Raycreation erst fertig läuft, bevor sekundärstrahlen gestartet werden, damit man danach, wenn zu viel Zeit verbraucht wurde auch abbrechen kann um eine erwünschte Mindestframerate auf kosten von Details zu erreichen.
-Texturen:
Es soll voll verwaltete Texturen geben, die prefetch, MipMaps und HDR unterstützen. Zudem konstante, lineare und cubische Interpolation, was man so eben alles braucht.
Bis auf mipmaps und prefetch ist eigentlich auch schon alles Implementiert, das prefetch wäre vermutlich etwas arbeit.
-Objekte:
Es wird "normale" Objekte geben, die so funktionieren, wie man das jetzt schon in APE sehen kann.
Zudem wird gefordert, dass sich alle Objekte wie Volumen haben, die ein innen/außen definieren, um die behandlung allgemeiner Objekte zu vereinfachen. Das würde, über eine Hyperebenen ähnlicthe Eigenschaft von Dreiecken, erlauben, dass Objekte selbst dann noch *dicht* sind, wenn man sich in ihnen befindet und nicht hohl, wie das bei rasterizern afaik immer gehandhabt ist. Dieses Verhalten wäre allerdings nur optionaler Natur, da die Standardimplementierung, wie jetzt auch schon, eine dünne Hülle um ein Dreieck sein wird.
Es wird Voxel basierte Geometrie geben, da man damit interessante Dinge machen kann und hier Raytracer mit Rasterizern speedtechnisch gleichziehen können, wobei Raytracer ihre Vorteile weiter behalten.
Allerdings ist von mir zunächst nur statische Voxelgeometrie geplant, da sich hier selbst bei scheinbar moderaten auflösungen riesige Datenmengen ergeben können.
Außerdem ist mir grad gekommen, dass man auf Grund der Gestalltung von Objekten, wie sie ab APE 0.2 war, ohne etwas über ein Objekt aussagen zu können, CSG aufbauen kann, sogar mit etwas komplexeren funktionen als AL, das ganze werd ich wohl selbst ausprobieren, da ich's vermutlich schneller selbst implementiert hab, als es jemandem genau zu erklären, so dass ers machen kann.
(Anm.: Es funktioniert mit ape nur bedingt, aber fast so wie ich mir das vorgestellt hab und der zusatzaufwand ist fast immer sehr gering; in ape kann man leider nicht rausfinden, wann ein Strahl aus einem Objekt austreten würde, was auf Grund der Volumenforderung hier kein Problem wäre. Für Objekte, die nah beieinander liegen funktionierte das aber in ape auch schon recht gut, auf Wunsch hätte ich da n Screenshot zu.)
-UI:
Es soll ein User Interface (also die Fassade für die Programmierer) geben, dass leicht und effizient zu benutzen ist.
Außerdem wird UI vollständig asynchron zum Rest laufen. Dafür bekommt *der Rest* eine FrameClock auf die man lauschen kann.

Aufgaben
- OS Maintainer, je für Windows und Linux; eventuell für Mac, wenn sich einer findet.
Die Aufgabe besteht darin regelmäßig die Bibliotheken und die Tests auf dem Zielsystem zu bauen und für eventuelle Probleme Bugreports zu schreiben. Diese Aufgabe kann im Prinzip jeder übernehmen.
- Core Rayhandling; den Weg, den Rays durch den Core nehmen; das würde ich selbst machen, weil ich da Erfahrung habe
- Core Texturen;
- Core SceneGraph;
- Object StandardObjects; Dreiecke, Vierecke, Boxen, Kugeln, etc.
- StandardObjects Materialien: Diffuse, Normalmap, Reflection, zusammengesetzte Fresnel Reflection/Refraction, etc.
- Object Voxel; alles was man mit Voxeln schönes machen kann
- Documentation Review; das sollte man vielleicht im Kreis rumreichen, dass es einfach jeder mal macht, sollte man aber machen
- Tutorial writer; jemand, der einfach Tutorials schreibt und testet, wie man mit der Lib arbeitet
- Modelformat; man müsste ein Format entwickeln, mit dem man Szenen beschreiben kann; da die Szenen, die man mit dieser Lib darstellen kann eine echte Obermenge von Dreieckbasierten Zeug sind wäre ein gängiges Format hier imho unpraktikabel. Das für sich ist imo eine Aufgabe die einen Hobbyentwickler voll auslasten würde und mit Raytracing an sich auch nicht zwingend was zu tun hat.
- UI Maintainer; jemand, der mir einfach sagt, wie meine Nutzerschnittstelle aussehen sollte, damit sie von normalsterblichen Programmierern zu bedienen ist. Das ist vermutlich die selbe Person wie der Tutorial writer.

voraussichtlicher Projektstart: 1.10.09
bisherige Interessenten neben mir:
- 1x PR
- 1x Programmierung

voraussichtliches Release von 0.1 noch 2009, wobei da nur die grundlegende Funktionalität im Vordergrund stehen wird und die Framerate auchnoch egal sein sollte. Einfach nur die Pipeline und ein paar schöne Bilder bauen, damit andere Leute auch was zu tun haben und motiviert sind, einzusteigen.

Kommentare sind erwünscht, bei Interesse könnt ihr hier schreiben, oder mir per Mail/Jabber/ICQ/PN.
Bei der Teamstruktur denke ich, dass ich das Projekt leiten würde, bis sich alle kennen und dass man dann zu einer Demokratischen Struktur übergeht, da das letztlich das beste ist und die meisten sowieso ohne Überschneidung arbeiten können.
Gruß
Timm

[whiteambit]

Hallo, bin leider schon fertig mit dem echtzeit RT. Ist aber ein Hybrid, d.h. die EyeRays werden per Scanline erstellt. Schaffe auf 768x576 so 20-50fps mit dem Stanford Bunny. In ein bis zwei Monaten habe ich ne demo fertig :ugeek:

[Zudomon]

@whiteambit
Super, was du da gemacht hast!! Ich bin auch der Meinung, den Primärstrahl über Scanline zu machen. Denn solange die Linse selbst nicht verzerrt ist, hat man dadurch das absolut gleiche Ergebnis! Bin schon sehr auf eine Demo gespannt!! Hybrid ist eh Zukunft, normales CPU-Raytracing lohnt nicht. Also gute Arbeit und vor allem sehr Zukunftsweißend. :D
Weiter so!!

[Lord Delvin]

Hört sich gut an:)
Hast du vor den Code rauszugeben?

Hmm also das mit dem Hybrid fand ich eigentlich nie besonders gut, aber es hat mich auf ne Idee gebracht.
Aber erstmal zu dem Problem, das ich mit Hybrid immer hatte:
1. zwei befehlssätze, d.h. man hat einen mehraufwand und muss eventuell ein schnittstelle bauen
2. kommunikation über einen pcie bus:
der hat in version 2 mit 16x 8GB/s. Sagen wir 50 fps wären das zies, dann wären das 160 MB/F die man maximal rein theoritisch zwischen GraKa und CPU rumschieben kann. Davon würden letztlich nochmal so 10-20MB nur auf das verschieben des Screenbuffers an die GraKa entfallen, blieben noch sagen wir 140MB. Ehrlich gesagt hab ich keine ahnung, wieviel man als update zulassen will, wenn man bedenkt, dass die GraKa nur etwa 1GB RAM hat, sagen wir 20MB. Man kann da ja viel machen.

Rechnen wir also der einfachheit halber mal mit 40 runter, 80 hoch (ich hab vorher unterschlagen, dass es sich um duplexdatenraten handelt, die 40MB waren natürlich von CPU zu GraKa), die man per frame verschicken kann.
Ein Ray besteht mindestens aus einem Ursprung und einer Richtung, macht also 8Byte. wenn mir noch 40MB bleiben, wären wir also noch bei 5MRays, die ich den frame testen kann...PRO FRAME. Das wären bei der 2MP variante 2.5 Rays/Pixel, also primärstrahl und diffuser schatten. Wenn man so rechnet, dann muss die GraKa aber selbstständig die gesamte SzeneGraph traversierung durchmachen, was jetzt aus meiner sicht kein Problem wäre.

D.h. man könnte darüber nachdenken diesen Schritt in die Pipeline einzubauen; dann müsste die CPU nurnoch die gesamten Materialgedönse übernehmen, im ScreenBuffer rummalen und updates machen...klingt fair, macht den code halt schwieriger.
Bliebe noch zu klären, ob die GraKa überhaupt 250MRay/s testen kann.

Wenn dem so wäre hätte man zumindest ein schönes Bild mit 30-50 fps bei Auflösungen um 1MPixel.

Anm.: Ich sammel hier momentan meine Gedanken zu dem Thema, kann also sein, dass ich irgendwo einen denkfehler mache.
Gruß

[whiteambit]

Hi, hier mal meine Gedanken:
Der "break even point" bei der Polygonzahl ab dem ein RT schneller ist, kann zunächst vernachlässigt werden, es sei denn man hat wirklich sehr sehr kleine Auflösungen (vllt. 10x20 :shock: ). Deswegen ist es immer schneller die EyeRays (oder Primärstrahlen) per Scanline zu erzeugen. Das Ergebnis ist das selbe, nur das Scanline hier bedeutend schneller ist, worauf man bei einem echtzeit RT wohl kaum verzichten kann. Die weitere Strahlenverfolgung übernimmt bei mir dann eine GeForce GTX 260 mittels CUDA (später vielleicht DX compute shader und OpenCL) - mit einer normalen CPU schafft man bei 4 cores vielleicht 2-4fps bei einer vernünftigen Auflösung. Mit SSE und Strahlenbündeln vielleicht ein bischen mehr - aber die Strahlenbündel funktionieren nur bei den Primärstrahlen gut - und die hat man ja schon vom Scanliner. Das GPU gerechne hat dann aber den Vorteil das die Datenschieberei entfällt. Da es bei mir HDR-Images sind ist sowas auch kein spass mehr . Ich werde letztlich egal ob vom Raytracer oder Scanliner nur 'deferred shadings' erstellen lassen, so das man später zum einfärben einen ganz banalen shader drüberlaufen lassen kann. Das vereinheitlicht beides wieder ein wenig. Letztlich ist es aber eher ein "proof of concept" (für mein diplom) mit einer ganz brauchbaren Engine drumherum geworden. Ich habe vor die Engine in ca. 2 Monaten zu releasen unter der LGPL wies ausschaut. Der Code ist allerdings noch ziemlich Windows lastig, die Programmiertools die es für diese Plattform gibt sind IMO einfach unschlagbar. Trotzdem ist es eine "echte engine", das heist der codepfad für DX (z.Zt. 9 und 10) kann schnell und sauber mit einem OpenGL codepfad erweitert werden. Der SceneGraph ist relativ schlicht auf Visitors aufgebaut. Dazu gibt es einen .NET Wrapper, so das man sich mal eben schnell eine GUI dranhängen kann.

[Lord Delvin]

Wir bräuchten noch unbedingt einen Programmierer fürs UI. Also jemand, der die features auf einheitliche und einfache Weise an Bibliotheksnutzer zur verfügung stellt. Außerdem sollte jemand assimp oder was ähnliches integrieren, damit man besser vergleiche zu Rasterizern bieten kann um mehr Leute zu überzeugen, dass es die zusätzliche Rechenzeit einfach wert ist.
Auf wünsch könnte man ins UI auch eine beliebige dsl integrieren um objekte und shader in sehr wenigen codezeilen erzeugen zu können. Das erfordert afaik aber einige Kenntnisse auf dem Gebiet, da man das ganze später irgendwie in asm konvertieren muss um genug speed zu haben, dass es sich lohnt, da Objekttests je nach Szene mit 10 bis 50% der verwendeten Rechenzeit zu Buche schlagen.

Generell denk ich aber trotzdem wieder, nach längerem nachdenken und vor allem motiviert durch die drei Gruppen hier im Forum die doch beachtliche Demos/Screenshots zeigen, dass sich Rasterizer nich lohnen, wenn man Reflexionen oder Schatten auf nichttrivialen Objekten darstellen will, von Wasser mal ganz zu schweigen. (wobei durchsichtige Objekte nie einfach sind)

Gruß
(btw. hab seit dem letzten post relativ viele Änderungen vorgenommen, darunter auch eine zusätzliche Anforderung an Objekte, die direktes CSG ohne wesentlich höheren Programmieraufwand ermöglicht)