[Projekt]APE

[Lord Delvin]

Da ich es grad irgendwie hinbekommen hab aus einer demo stabile 25 fps rauszuholen (core i7 920, 640x480 bildpunkte) mach ich hier jetzt doch mal ein eigenen Thread auf in dem ich meine Gedanken an die Umwelt abgeben kann - natürlich in Verbindung mit schönen Bildern:D

ape@25fps.png

Das ganze verwendet die neu implementierte Möglichkeit von "swap Signalen". Damit kann die funktion, die bestimmt welcher Punkt als nächstes aktualisiert wird mitteilen, dass man danach dann den Buffer swappen kann. Das ganze kann man ähnlich wie vsync sehen, man kann's aber auch einfach ignorieren.

Anders als vsync entsteht bei der momentanen implementierung allerdings nicht eine Scanline, die über den bildschirm wandert, sondern eine pro thread die an relativ deutlichen Artefakten zu sehen ist...seht selbst:

ape scanline.png

Was man in dem Bild auch sehen kann ist die steigende Framerate während der ersten Frames. Das kommt durch einen eigenen mini Memory Manager, der in einem kritischen Teil des Codes eingabaut wurde und der sich erst *warmlaufen* muss, da adaptiv so viel speicher belegt wird, wie man grad braucht und syscalls kosten halt nicht grad wenig zeit.
Sehr schön anzusehen, dass so nach 30sec, wenn das ganze warm ist, kein weiterer speicher mehr allociert wird und alles etwa doppelt so schnell läuft:)

Etwas merkwürdig find ich atm noch, dass die Rayrate eigentlich für fast doppelt so viele fps reichen würde, vermutlich ist der Screenbuffer einfach immernoch zu langsam, da muss man sich echt noch was überlegen.

(mir ist klar, dass raytracing eigentlich eher nicht in das Forum passt, aber macht der gewohnheit, und weil ihr alle ziemlich inspirierend seid bleib ich lieber hier, als mir ein 100% passendes Forum zu suchen:) )

Gruß
Lord D

[Aramis]

Ich finde sehr wohl dass Raytracing hier her passt und vorallem finde ich die Framerate für einen Raytracer beeindruckend.
Wie sieht's mit Download's aus? Will auch mal Demo ausführen damit ich mir hinterher wenigstens sicher sein kann dass mein Prozessor im Vergleich zu einem core i7 920 lahm ist :D

[Lord Delvin]

Wie sieht's mit Download's aus?

Momentan nicht gut: Ich hab selbst keine windows mehr installiert und das Crosscompilen tat bei mir auch nie so richtig, ich werd aber demnächst mein Rechner aufräumen, da liegt irgendwo ein image mit win2k rum, mit dem sollte es eignetlich möglich sein eins der Testprojekte zu bauen.

Außerdem ist das mit der Framerate z.Z. noch eine sehr instabile sache, da man das mit ein paar ungeschickten änderungen schnell zu nichte machen kann und dann wieder bei ~4 vorbei kommt, aber wenn ich die Arbeiten im Untergrund alle erledigt hab, dann werd ich auf jeden Fall wieder ne demo für windows baun.
Und es scheint mir so, als würde der main thread, der eigentlich nur updates von display und szene macht, fast einen ganzen kern fressen, was natürlich dazu führt, dass die Framerate auf einer zweikernigen Maschine eher *niedrig* ist.

Ansonsten kann ich anbieten, dass dus direkt ausm svn ziehst und selbst baust; die depencies sind afaik alle in ubuntu 8.10 drin.

Btw. framerate: hat jemand mal irgendwas geschrieben, mit dem man ein normales model in einen kdTree geladen bekommt? Das wäre für mich für ne demo echt bombig und würde wohl den nötigen ansporn liefern, die ganze Objekt/SceneGraph Strukturen endlich mal zu implementieren...dann verbring ich nicht mehr 10% der zeit in std::vector...das is mitlerweile echt pervers.

Gruß
Lord D

[Aramis]

Ansonsten kann ich anbieten, dass dus direkt ausm svn ziehst und selbst baust; die depencies sind afaik alle in ubuntu 8.10 drin.

Ubuntu hab ich drauf, Deps würde ich vermutlich schon zusammenkriegen falls noch was fehlte. Insofern: gerne :-)

Btw. framerate: hat jemand mal irgendwas geschrieben, mit dem man ein normales model in einen kdTree geladen bekommt

Vielleicht nützt dir ja Assimp was (*unverschämtest mögliche Eigenwerbung*). Unsere Ausgabestruktur ist allerdings auch nur ein 'gewöhnlicher' Szenengraph, aber immerhin musst du dich dann nicht mehr um's Laden selber kümmern.

[Lord Delvin]

Vielleicht nützt dir ja Assimp was (*unverschämtest mögliche Eigenwerbung*). Unsere Ausgabestruktur ist allerdings auch nur ein 'gewöhnlicher' Szenengraph, aber immerhin musst du dich dann nicht mehr um's Laden selber kümmern.

Ja da hatte ich auch schon ernsthaft drüber nachgedacht, vermutlich mach ich das auch so, wenn ich die Zeit dafür hab, aber atm hab ich leider viel stress, in zwei drei Wochen vielleicht:-/

[glassbear]

Schick, schick :)

hast du Packet Tracing bereits eingebaut? Das hab ich als nächstes vor bei mir. Und dann vielleicht mal das Grid gegen einen Baum austauschen ;)

[Lord Delvin]

Nein und das wirds so auch nicht geben. Es wird aber vermutlich die traversierung des BVH, dens sehr rudimentär schon gibt in paketen erledigt. Mehr würde es auch zumindest mit unserer architektur auch nicht bringen...mir wäre zumindest völlig unklar wo. Außerdem ist echt nicht zu unterschätzen, dass die Speicherbandbreite immer mehr zu einem problem wird...ich mein gegen L3 Cache wirkt mein Ram schon fast wie Hintergrundspeicher und wenn der Screenbuffer nicht so riesig wäre, dann würd ich atm auch alles in den L3 Cache reinbekommen:D

[Lord Delvin]

So, heute wird ape 0.3 eingestellt, also mal ein paar Updates zum Projekt. Demos finden sich im Anhang.

Zuerst zu den Demos:
Das ganze ist auf qualvolle Weise unter Windows gebaut worden und läuft auch in wine, sollte also für jeden einfach ausführbar sein. Falls jemand es schafft eins von den teilen zum absturz zu bringen, meldet euch bitte.
Der Sinn ist eigentlich zu zeigen, was ape momentan kann und was nicht, aber dazu im Folgenden mehr.

Änderungen seit 0.2
In 0.3 wurde vor allem die Art, wie RenderThreads mit Rays hantieren geändert. Dabei sind alle Locks/Mutexe etc weggefallen, d.h. die RenderThreads laufen jetzt vollständig asynchron zum restlichen Code. Das funktioniert in der Theorie ziemlich gut. In den syncbox demos sieht man aber denk ich, dass es in der Praxis noch etwas überholt werden muss; das wird wohl das erste sein, was in 0.4 geschieht.
Außerdem gibt es ein neues Konzept für die repräsentation der Welt. Wie vorher wurde das aber nur sehr rudimentär implementiert, weil ich nicht die Zeit und die Lust hatte, da mehr zu machen. Generell fehlt hier eigentlich jemand, der sich um ape::object kümmert und mal versucht, eine Demo mit einer größeren welt zu schreiben...atm kann man leider nichtmal irgendwelchen models laden.
Deswegen ist in object auch nur ein kleines Material hinzugekommen, das man in der offline demo an den Wänden sehen kann. Das ganze hat mich aber auch nur 5min arbeit gekostet...
Naja und was soll man noch sagen...dadurch, dass alles viel besser in den Cache passt, kaum noch Zeit im Kernel verbracht wird, die Raybuffer entfallen und die CPU trotz der Möglichkeit die Szene zu verändern immer voll ausgelastet ist, hat man halt wesentlich mehr Rays/sec bzw FPS. Wobei an dieser Front noch sehr seltsame Effekte zu sehen sind, die ich untersuchen werde...z.b. läuft alles wesentlich langsamer, wenn man vsync rein macht. Dass die asyncbox langsamer läuft liegt imho nur am Cache, deswegen wird es in der nächsten version vermutlich auch keine möglichkeit mehr geben derartige updates zu machen.

Raytracer vs. Rasterizer
(Nein ich will hier kein geflame oder sowas anfangen, ich will nur versuchen die Essenz eines interessanten Gesprächs wiederzugeben, weil sie, denke ich, hilfreich ist)
(Anm.: Das ganze ist sehr "flach" formuliert, aber ich will mich hier nicht in Details verlieren)
Der erste wichtige Punkt ist der Komplexitäts geflame Unsinn vonwegen logn vs n ist Unsinn. Jedem halbwegs erfahrenen Grafikprogrammierer sollte klar sein, wie man beide Techniken in logn realesieren kann. Wobei n die Anzahl der Objekte ist.
Das eigentlich Speed Argument ist, dass Raytracer per Pixel und Rasterizer per Objekt arbeiten. Da man sich bei einem Raytracer im normalfall aber trotzdem alle Objekte auf dem Weg des strahls anschaune muss, müssen Raytracer langsamer sein. Wenn man sich eine Szene mit einem einzigen Dreieck ansieht, dann wird einem das wohl am deutlichsten klar:
Rasterizer 1 Test, Raytracer N Tests; N die anzahl der Pixel die das Dreieck sehen können.(theoretische Untergrenze, die Praxis ist meist etwas schlechter)
Ich bin letztlich davon überzeugt, dass es ab Szenen, in denen 10+ Dreiecke auf einen Screenpixel entfallen Raytracer tatsächlich schneller sein können, weil man dann bei Raytracern besser *bescheißen* kann. Allerdings muss ich zugestehen, dass es auch sein kann, dass sich Raytracer tatsächlich niemals aus Speedtechnischen gründen lohnen.
Dafür sehen die Bilder imho besser aus:D

Intel/Pohl Raytracer
Intel macht ja seit einiger Zeit gerne Marketingwirksame Aktionen mit ihrem *Raytracer*. Sieht nett aus, allerdings ist das quasi der ASIC unter den Raytracern. Wenn man genauer hinsieht, dann kann der eigentlich genau das, was sie grad brauchen und ist dafür bis zum erbrechen optimiert. Kann man so machen, ist in ihrer Situation sicher auch das beste, ich lehne ASM und viele andere Optimierungen zZ aber ab.

Oh schon viel zu viel geschrieben...aber kurz noch zu dem offline Raytracing:
Das ganze ist mit der Boxdemo fast identisch. Die Kugeln wurden durch Dreiecke ersetzt nud optisch interessant im Raum verteilt. Einzig das Diffuse Material wurde durch OfflineDiffuse ersetzt, was dazu führt, dass nicht genau ein Strahl/Licht in Richtung der sichtbaren Lichtquellen versand wird, sondern viele irgendwo hin. Das kostet natürlich viel performance, aber mir ist nichts schöneres eingefallen, um zu demonstrieren, dass APE relativ vielseitig genutzt werden kann, ohne dass man viel Code ändern müsste.

Ich denke falls tatsächlich noch jemand was wissen will, dann soll er einfach fragen:)
Ich hätte auch noch ein paar Screenshots, aber dann wird das so ein monster Post den keiner lesen will.

EDIT: Zu den Framerates fällt mir grad noch was erwähnenswertes ein: Das ganze wird immer gegen RenderThread 0 synchronisiert, d.h. wenn der sagt, dass ein Frame fertig ist, dann wird angenommen, dass er tatsächlich fertig ist. Das ist natürlich keine gute methode und führt zu weilen auch zu sehr merkwürdigen werten. Also vielleicht nicht ganz so ernst nehmen, hätte ich vielleicht früher drauf kommen können, dass das keine maß sein kann. Das führt witziger weise auch dazu, dass die "Sichtbarkeit" der Artefakte und der Unterschied zur tatsächlichen Framerate(die man leider atm nicht messen kann) ein Maß für die Qualität des System Schedulers ist, da theoretisch keine Artefatke auftreten würden, wenn alle Threads gleich viel zeit bekämen...passiert aber auf keinem mir bekanntem system.

EDIT2: Öhm falls sich jemand fragt, warum macht der den scheiß dann eigentlich, wenn er sowieso nicht gewinnen kann? Ganz einfach: So viel wie ich hier über Paralleles Rechnen gelernt hab werd ich sonst nirgends lernen können. Ich mein es läuft OHNE Mutexe...letzlich hab ichs auch nur wieder aus der Versenkung geholt, weil der Sysarch Übungsleiter behauptet hat, sowas wäre unmöglich....naja. Und irgendwie find ichs schöner, als sich mit Dreiecken und anderleuts Code rumzuschlagen.

EDIT3: Wenn man das Offline Rendering ne zeit laufen lässt dann siehts so aus:

ape offline.jpg

[Lord Delvin]

So hab jetzt die Artefakte größtenteils repariert.

Damit sich Menschen mit dualboot vergewissern können, wie schlecht threads unter windows laufen hab ich mal noch ein linux build reingepakt.

Das archiv enthält nur zwei Versionen von box, die identisch kompliziert sind, aber die linux version hat ne rotierende Kugel, weils gut aussieht, wenn die framerate hoch genug ist. Bei mir läuft das mit etwa 14-26 fps. Sehr schade ist irgendwie, dass die Kugeln erfordern, dass man 12 rays pro pixel erlaubt, was für die framerate ganz schlecht ist:D

Ah und falls das irgendjemand ausprobiert und feststellt, dass es langsam ist: Das braucht ne zeit, bis es schneller wird...also so 1min normalerweise. Das liegt daran, dass ich aufgrund idiotischer limitierungen durch POSIX gezwungen bin einen gc zu verwenden und dessen implementierung ist noch nicht direkt optimal...

Gruß

[Richard Schubert]

Läuft auf meinem i7 920 nur mit maximal 10 FPS und mit einer Menge Artefakte. Auf dem Intel Xeon E5420 (2x4 Cores) startet nur das Konsolenfenster und nichts weiter. :(

[Lord Delvin]

Läuft auf meinem i7 920 nur mit maximal 10 FPS und mit einer Menge Artefakte. Auf dem Intel Xeon E5420 (2x4 Cores) startet nur das Konsolenfenster und nichts weiter. :(

Kannst du mir dazu ein paar mehr Informationen geben, damit ich schauen kann, warum das so ist? Also OS und GraKa. Ram sollte eigentlich egal sein. Artefakte find ich ziemlich komisch...aber ich glaub ich such mir mal noch irgendwo n paar andere Systeme und schau ob ich da derartige Fehler reproduzieren kann. Habs leider atm nur alles auf dem gleichen System getestet und in der VM mit Win XP bekomme dank einem Thread auch keine Artefakte.
So ganz bugfrei kanns aber auch noch nicht sein, da es mir so scheint, als wäre der erste Frame wesentlich langsamer als die anderen.

EDIT: Sagt das konsolenfenster eigentlich irgendwas, oder nicht?

[Krishty]

Bei mir ebenfalls leeres Konsolenfenster, 0% CPU-Auslastung. Konsole schließt erst Sekunden nach dem Klick auf X, Admin-Rechte und XP-Kompatibilitätsmodus bringen nichts.

Vista x64, Core 2 Quad Q6600, Radeon HD 4850.

[Richard Schubert]

Beides Windows Vista 64Bit. Auf dem i7 920 sind alle 8 "Cores" zu 100% ausgelastet und die Graka ist ne Geforce GTX 285.
Der Xeon PC hat ne Quadro FX 3700 (AFAIK ähnlich zu einer Geforce 9800 nur mit wunderlichem Grafiktreiber). In dem Konsolenfenster steht leider nichts, als wenn er beim Start sofort stehen bleibt.

[mikesc]

Auch bei mir bekomme ich nur ein leeres Konsolenfenster zu sehen.
Intel Core2Duo E8500, ATI Radeon 4850, 3GB RAM, Windows XP 32bit SP3

[eXile]

Läuft hier mit gepflegten "alle 3 Sekunden ein Bild" (was anderes kannst du bei der Hardware hier auch nicht erwarten). Allerdings sind mir einige mutmaßliche Artefakte aufgefallen, aber ich konnte bei der Geschwindigkeit nicht beurteilen, ob dies so gewollt war.

[Lord Delvin]

@10fps: Also ich hatte schon früher unerklärlich niedrige werte unter windows bei gleicher Hardware, mir ist auch nie klar geworden, warum das so ist; weis nicht ob es sich noch lohnt, dem nach zugehen. EDIT: Letztlich war das auch, neben dem offensichtlich wundervollen apt-get, der Grund, warum ich an Windows die lust verloren hab.

@leeres fenster/leere konsole: So aus der ferne würde ich sagen, dass es bedeutet, dass der Verwaltungsthread nicht startet, da der eigentlich seine adresse zum debuggen auf die konsole schreiben müsste und das immer die erste message sein muss, weil der die renderthreads mit daten versorgt. Das würde sich dann auch mit dem langsamen schließen decken, weil versucht wird, auf den thread zu joinen, was nicht funktionieren kann, wenn ein thread nicht läuft.

@Artefakte: von links nach rechts: 1. ist kein artefakt. Das ist ein "shadowray", der von der metallkugel reflektiert wird. Früher wurden die dann einfach direkt abgebrochen, dann würde man genau den schatten bekommen, den man von den stencil shadows auch her kennt. Ich fands so aber schöner. 2. sieht spontan so aus, als wäre der raystack da voll. D.h. an dem punkt wurden schon 12 rays bearbeitet und es wurde immernoch kein licht getroffen. das kann bei so ner glaskugel leider relativ leicht passieren, weil die strahlen natürlich auch in der kugel bleiben können, was sie am rand relativ leicht machen. Ich vermute, dass das auch das problem mit 3. und 4. ist, allerdings würde ich mich da jetzt auch nicht festlegen.

@Richard Schubert Artefakte: Vermutlich kann man bei dir noch Rauschen an den Kanten sehen. Das liegt daran, dass teile von ape noch nicht auf das neue Konzept umgeschrieben sind, aber irgendwie is es bei mir nur manchmal sichtbar und selbst dann meistens erträglich, weswegen ich eigentlich keine lust hatte es gleich ze reparieren.

Man sieht mal wieder wie schön plattformunabhängigheit in der Realität funktioniert:-/
Freut mich aber, dass es ein paar Leute ausprobiert haben.

Ich hab mir das Wochenende auch noch mal die arbeit gemacht und meine alte maschine genommen und mit 0.2 verglichen. Es scheint so zu sein, als wäre der momentane Code etwa doppelt so schnell, was einmal mehr die Frage aufwirft, obs das ganze wert ist. Zudem hab ich mal gerechnet und komm auf eine Grenze von etwa 1MRay/(s * core *GHz). Wie man leicht sieht würde das auch bei allen angekündigten Prozessoren von Intel für nichts wirklich schönes reichen. Ob ich deswegen aufhöre weis ich noch nicht, aber letztlich muss ich sagen, dass ich das Potenzial doch erheblich überschätz habe.(Tut mir leid, falls ich irgendjemandem damit auf die Nerven gegangen bin;))
Außerdem scheint es zumindest bei mir so zu sein, dass ich langsam an die Limits der Speicherbandbreite komme. Und da wird man dann vermutlich nix mehr machen können, weil die Welt halt im allgemeinen nicht in den Prozessorcache passen sollte.

Ich denk ich werd doch noch die 15 Zeilen asm hacken und vielleicht schreib ich noch ne VoxelObject implementierung, weil es zwei Dinge sind, die mich noch reizen würden, aber ich glaub ehrlich gesagt nicht, dass ich nochmal 30fps vollbild erleben werde. Nicht zuletzt, weil ich das gefühl hab, dass momentan die Pixelzahl schneller wächst, als die Prozessorleistung...oder ähnlich schnell...für Raytracing auf jeden fall gar kein guter trend. Vielleicht besorg ich mir auch n Windows 7 rc und schau, dass ich das mit den threads debuggt bekomme.

Falls das irgendjemand mal in einiger Zukunft liest und sich überlegt auch mal nen Raytracer zu schreiben, dann sollte er das nur tun, um was zu lernen. Und wer will, kann sich gerne den Code anschauen.

Gruß


EDIT2: Wenns wirklich gewünscht ist, dann kann ich auch nochmal versuchen den Weg von APE und die gewonnen Erfahrungen in einem Post zusammenzutragen.

[Schrompf]

Andere Echtzeit-Raytracer haben wohl eine Menge Tempo gewonnen, indem sie die Szenedaten komprimiert haben. Also so schlichte Tricks wie die Normale nur als 16Bit-Integer abzulegen oder die lokalen Punktposition in 16Bit zu quetschen... das könnte Deinem Speicherbandbreitenproblem helfen. Auch sonst denke ich, ist da noch ne Menge rauszuholen... Du solltest da nicht zu früh aufgeben. Ich habe da nur Arauna als Vergleich im Auge, die ja ohne ihre AmbientLight-Spielereien auf einem QuadCore bereits solide Framerates erreichen - mit sehr viel komplexeren Szenen und dynamischen Objekten darin. Da ist also anscheinend noch ne Menge Luft für Verbesserungen :-)

[Lord Delvin]

Über die Kompression hab ich auch schon nachgedacht. Aber ehrlich gesagt lehne ich das ab. Weil ich dann schon sichtbare Artefakte erzeuge.
Wir haben am anfang mal geschaut, ob wir float oder double verwenden wollen, weils egal schien. Auf dem AMD X2 auf dem ich früher gearbeitet hab wars tatsächlich auch fast gleichschnell. Und der unterschied war doch schon sichtbar. Und unsere Welt ist weder groß noch kompliziert. Deswegen hatte man dann so ein real konstrukt, dass je nach config enteweder float oder double war. Mitlerweile is es nurnoch float.
Ich mein mann könnte auch einfach statt 96 bit farben 32bit nehmen. Schon klar. Aber man müsste für so Sachen halt ne menge Code ändern oder vermutlich nur anschauen; sonst hat man bald artefakte, die man nicht zuordnen kann.
Arauna verwendet auch RayPacks. Das ist ein Ansatz den ich aus Codeschönheitsgründen grundsätzlich ablehne:D
Naja ma schaun, muss da mal vielleicht länger drüber nachdenken um zu entscheiden ob ich die floats wirklich aufgeben will...floats sind so toll:D
außerdem sind so befehle wie dpps wirklich nicht zu unterschätzen...muss ma schaun obs sowas auch für ints gibt.
Vielleicht sollte ich ne Out of Order pipeline bauen:D
Dann könnte ich RayPacks im BVH verwenden und für die Objects can man normale Rays nehmen. Dann würde sich am user Code nichts ändern...der Core wäre dann aber vermutlich vollends unverständlich.

EDIT: Hab mir Arauna mal angeschaut. Die scheinen meiner Theoretischen grenze auch nicht so ganz direkt zu widersprechen, aber mein erster Gedanke war schon, der is einfach besser. Werd mir wohl definitiv mal seinen Code durchlesen. Dann versteh ich vielleicht auch, warum er nur Dreiecke erlaubt obwohl seine Sezenen eigentlich nur aus 5 einfachen Objekten bestehen.

[Zudomon]

Bei http://www.realstorm.com/ tricksen die auch sehr, um auf Echtzeit zu kommen. Da wird dann nur bei jedem x-ten Ray Licht und Schatten berechnet usw. und dazwischen einfach interpoliert.
Aber durch solche Dinge sieht das ganze dann schnell sehr unschön aus.
Außerdem verwenden die meistens diese parametrisierten Grundkörper, also auch für Quader und Zylinder usw.
Da lässt sich dann auch eine Menge an Daten einsparen.

Wenn du echtzeit Raytracen willst, dann gibs nur eine Möglichkeit, benutz deine Grafikkarte!!

[Lord Delvin]

Bei http://www.realstorm.com/ tricksen die auch sehr, um auf Echtzeit zu kommen. Da wird dann nur bei jedem x-ten Ray Licht und Schatten berechnet usw. und dazwischen einfach interpoliert.
Aber durch solche Dinge sieht das ganze dann schnell sehr unschön aus.
Außerdem verwenden die meistens diese parametrisierten Grundkörper, also auch für Quader und Zylinder usw.
Da lässt sich dann auch eine Menge an Daten einsparen.

Das mit dem x-ten Ray haben wir ausprobiert. Öhm um dir zu verdeutlichen wie schlecht das aussieht: Atm siehst du einen initialen Ray/Pixel. Stell dir einfach vor du hättest 0.x Rays/Pixel. Das geht einfach garnicht. Also wir zumindste hams verworfen, weil kacke aussieht.
Das mit den Grundkörpern ham wir ja auch. Du musst einfach nur zwei Funktionen definieren und schon bist du im geschäft. Welchem System diese Funktionen folgen ist deine Sache. Die einzige limitierung ist, dass es ein endliches Objekt sein muss, also du kannst zumindest im allgemeinen keine hyperebene definieren. Eventuell funktionierts doch mit +inf -inf etc. aber ich würdes nicht garantieren.

Wenn du echtzeit Raytracen willst, dann gibs nur eine Möglichkeit, benutz deine Grafikkarte!!

Nicht, wenn es kein C++ -> GraKa Compiler gibt, solange ich alleine an dem Projekt arbeite.

Ich glaub ich werds die Woche einfach mal ruhen lassen und nachdenken...vielleicht starte ich das ganze nochmal von Grund auf neu; dann würde ich mal schauen, was sich so an mitstreitern auftreiben lässt und dann könnte man auch über so späße wie CUDA, OpenCL oder algorithmische katastrophen wie out of order pipelines nachdenken.

[klickverbot]

Ich habe gerade keine Zeit, dein Projekt herunterzuladen und mich damit zu spielen. Deswegen nur eine kurze Anmerkung:
Ich komme einfach nicht dahinter, was auf deinem Offline-Rendering-Screenshot abgebildet ist – es könnte in meinen Augen genau so gut ein Haufen Artefakte sein. Vielleicht lässt sich hier noch eine »bessere« Szene finden…

[Zudomon]

@Lord Delvin
Bildinformationen zu interpolieren sehen meistens

kacke

aus. Man braucht sich ja nur nochmal die Realstorm Demo anschauen. Wollte dir damit auch nur sagen, wie man da noch Geschwindigkeit rausholen kann. Aber mal ehrlich, wenn man sich die Demos, die die da hatten nochmal anschaut, die liefen damals meiner Meinung nach fast genauso schnell und die Quali kommt ist nicht beeindruckend.
Also ich würde ein CPU Raytracer auf jeden Fall verwerfen, außer man hat Spass daran das ganze zu programmieren. Aber Gewinnen lässt sich damit nichts, und die Marketingbemühungen, die Intel da versucht, kann man auch getrost vergessen.
Würde mal behaupten, das selbst CPU's mit 32 Kernen nicht annähernd an die Geschwindigkeit einer heutigen Grafikkarte kommen.
Und davon abgesehen, selbst wenn das Raytracing mit dem normalen Rasterizieren mithalten könnte, hätte man ein großes Problem, denn sobald man eine Oberfläche mit nem Strahl getroffen hat, setzt eigentlich das ein, wo Grafikkarten mit ihrem Pixelshadern schon hochoptimiert sind, nämlich die Materialfarbenberechnung. Da kannste deine Szene noch 100 mal in den CPU Cache packen, wenn du dann darauf angewiesen bist, bei jeder Kollision aus hundert Megabytes Texturen zu lesen, wird das nichts.

Wir hatten da ja schon mal so privat drüber geredet. Wenn man da was sinnvolles erreichen will, dann muss man eine hybride Lösung finden.

Aber nochmal kurz, um mal anzuführen, wie sinnlos das echte Raytracen ist, und warum es in naher Zukunft nicht möglich sein wird:
http://www.computerbase.de/artikel/hard ... pielen_20/
Da schaffen die etwa 90 Bilder bei 1280x720...
Schön, Echtzeit könnte man sagen, aber was haben die jetzt?
Primärstrahl + Reflektion/Refraction + Schatten
Aber spektakulär sieht das eigentlich noch nicht aus. Man müsste weichen Schatten haben und Antialiasing/DOF wären auch nicht schlecht. 128 Sampels für Schatten wäre schon fein. Wenn man dann noch 16 Rays per Pixel für das AA/DOF einsetzt und noch optimiert, indem man bei jedem Ray nur einen Teil der Schattensampels rendert, wären das 8 Shadowrays.
Statt 8 Kerne bräuchte man dann schon 128, um die Framerate etwa zu halten und eine passable Qualität zu zaubern. Aber wirklich interessant wird es dann eigentlich erst, wenn man das indirekte Licht berechnet.
Durch Pathtracing ist das relativ einfach möglich, und auch in Ordnung, solange man keine Hochfrequenten Lichtbrechungen wie etwa bei Caustics hat.

Nun, was ist Pathtracing? Sobald ein Strahl eine Oberfläche trift, wird dessen Materialfarbe bestimmt und anschließend geschaut, wie viel indirektes Licht auf die Oberfläche fällt. Bei exakten Spiegelungen, wie man das beim Raytracing oft sieht, reicht ein weiterer Strahl aus. Wenn es allerdings Diffuse oberflächen sind, muss über die ganze Hemisphere des Punktes iteriert werden. Dazu wird im Monte Carlo verfahren der Strahl Diffuse weiter gestreut. Da wäre eine Bild mit 1024 Sampels noch so verrauscht, das es eigentlich unbrauchbar ist. Bei einer Million Sampels wird es schon so langsam ansehnlich. Aber um das dann genauso in Echtzeit darzustellen, muss man dann auch die Prozessoren eine Million fach schneller bekommen. Wenn man dann das grafische Maximum erreichen will, dann müsste man alles ausschließlich mit Photonen beleuchten. Da braucht man dann aber schon etwa eine Milliarde, um eine kleine Szene in relativ geringer Auflösung ziemlich rauschfrei darzustellen. :D
Aber da das ganze nicht gerade schnell ist, und die Hardware dafür wohl auch nicht in den nächsten Tagen rauskommen wird, wird man wohl wieder tricksen müssen. Nicht umsonst kann man bei den gängigen professionellen Raytracern auch Cube- und Shadowmaps rendern. Und da frag ich mich dann, was hat Raytracing für Vorteile? Oder eher, was kann Raytracing, was man nicht auch im Pixelshader realisieren kann, wenn man es unbedingt braucht?

Wirst sehen, irgendwann holen dich die Dreiecke!! :D

[Lord Delvin]

@klickverbot: Jaja, ich weis, die Szene is scheiße. Wenn jemand lust hat mit rumzuspielen wär ich ihm sehr verbunden. Für mich reichen halt drei Kugeln, also metal/glas/licht und die bunte box aus. Und für texturen hab ich ja noch die box mit normal maps und textur und dem erdlicht. Die ist aber auf grund ihrer struktur nicht so gut, um artefakte zu erkennen. Da sind harte kanten und große glatte flächen viel besser. Das was man da unten sieht ist der klägliche versuch mit ner normal map wasser zu simulieren...ist vermutlich vor allem wegen des raums an sich keine gute idee...

@zudomon: Also dass der Pohl Artikel nicht Sachlich ist, ist uns wohl allen klar. Es geht zwar alles in die richtige Richtung, aber die Fixkosten/Ray zu unterschlagen is relativ unfair und viele der Vergleiche so darzustellen, wie er das tut ist es definitiv.
Deine ausführungen zu schatten sind aber extrem unsachlich. Du kommst mit 8 rays ohne AA und (softshadows oder refraction) aus. Du kannst bei mir sogar beides reinmachen und wenn in einem Pixel zuerst ein diffuses material ist, dann hat das softshadows und wenn zuerst glas kommt, dann hast du in dem glas harte oder vielleicht auch keine schatten, wenn halt keine rays mehr da sind. Die schönen diffusen beleuchtungen wie in der offline Demo willst du eigentlich nicht haben, weil sie, wie du richtig erkannt hast, nicht in echtzeit berechenbar sind. Da must du dich dann entscheiden ob du das mit irgendwelchen Lightmap gesocksen simulieren willst, oder ob du lieber verzichtest; die frage stellt sich da aber immer.
Außerdem ist dein kommentar zu den Texturen ziemlicher blödsinn. Du kannst doch genau vorhersagen, wo der Punkt sein wird, den du brauchst, also hast du einen ganz normalen speicherzugriff wie sonst auch. Das macht zumindest bei mir fast nix aus. Ich kann mir auch fast nicht vorstellen, dass es irgendwann mal WIRKLICH ins gewicht fallen wird.
Außerdem glaub ich, dass du GraKas etwas zu positiv siehst. Die haben zwar *imense* GFLOP zahlen, allerdings ist es wesentlich komplizierter die auch zu erreichen. Da nimmt dir die CPU sehr sehr viel arbeit ab. Außerdem musst du dich bei GPUs um viel scheiße kümmern und dein RAM ist ziemlich mikrig. Das führt letztlich dazu, dass du programme für GPU und CPU schreiben musst, die dafür sorgen, dass die CPU immer schön daten an die GPU streamt, damit die weiter machen kann...out of order und prefetching...lecker:-/

EDIT: Btw bin ich davon überzeugt, dass es bei schönen diffusen materialien effizienter ist, strahlen vom licht zu versenden und nicht andersrum.

[Zudomon]

Ich frage mich, wie du mit 8 Rays für weichen Schatten auskommst, wenn man noch bei 128 Artefakte sehen kann.

Meine Ausführungen bzgl. der Texturen waren eigentlich auf das Pathtracing bezogen. Da wirste nicht so einfach vorhersagen können, wo du dann aus der Textur sampeln musst.
Außerdem ist es natürlich nur ein einfaches "aus der Textur rauslesen", wenn du einen ziemlich simplen Shader hast, aber mach das mal mit komplexen Pixelshadern...

Du kannst bei mir sogar beides reinmachen und wenn in einem Pixel zuerst ein diffuses material ist, dann hat das softshadows und wenn zuerst glas kommt, dann hast du in dem glas harte oder vielleicht auch keine schatten, wenn halt keine rays mehr da sind.

Das verstehe ich nicht so ganz. Hört sich an, als ob du das alles mehr oder weniger nach gutdünken baust, statt dich an physikalische Grundlagen zu halten.

EDIT: Btw bin ich davon überzeugt, dass es bei schönen diffusen materialien effizienter ist, strahlen vom licht zu versenden und nicht andersrum.

Wenn du es am effizientesten machen möchtest, dann solltest du vom Licht aus Strahlen aussenden und vom Auge aus. Das ganze nennt sich dann Bidirectionales Path Tracing.

[Bergmon]

@Lord Delvin:
tja, keine ahnung, ob es dich noch interessiert(mich hat es) - ich hab auch mal deine progrämmchen getestet:

verwendet auf einem A643200 1GBRAM GF6800GT XP64, mit fraps gemessen, weil dein framecounter etwas undeutlich war...;):

ape0.3:

• asyncbox: 16fps
• offline rendering: 4-5fps
• syncbox: 12-16fps[scanline]
• syncbox-nosync,direction: 7-9fps[scanline]
• syncbox-vsync,std: keine rückmeldung
• textured box: 24fps

ape0.3b: keine rückmeldung

wo wir schon mal beim benchmarken sind :D ... hast du dir schon mal den benchmark von http://maxwellrender.com/ angeschaut? zu finden unter: http://benchwell.com/. die test-szene dauerte bei mir circa 105 minuten zu rendern. interessant ist da, dass die neuesten rechner so 10 bis 20 mal schneller sind. das ergebnis sieht dann so aus:

was ich mittlerweile auch gemerkt hab ist, dass sich 64Bit kompilate doch ganz gut in der geschwindigkeit bemerkbar machen. kann man z.b. aus der ergebnisliste des benchmarks entnehmen. auch in dem pick-tutorial vom dx-sdk hab ich bis zu 100fps mehr(ca 20-30% an geschwindigkeitszunahme, woran es genau liegt weiß ich jetzt nicht). da kann man also auch noch was rausholen, vermutlich sogar gratis, einen guten compiler vorausgesetzt was die cpu seite angeht - gpu-seitig könnte sich für die primary-rays auch der deferred-render ansatz eignen, oder?

ansonsten hab ich noch das gefunden: http://www.caustic.com/
vielleicht als ne art voodoo-karte, so für secondary-rendering...à la 3dfx

gruß bergmon

ps: textured box hat mir mit der wandbeleuchtung durch die sphere ganz gut gefallen, allerdings noch sehr verrauscht.

[Lord Delvin]

Ich hatte zwar beschlossen diesen *verrauschten* Ansatz nicht mehr so zu verfolgen, aber es interessiert mich trotzdem, zumal es meine Vorstellungen doch zu bestätigen scheint, dass es wesentlich schneller ist als Ape 0.2.

Die Framerate beim Offline Rendering ist vollkommen egal; dass es manchmal passiert, dass es keine Rückmeldung gibt, hab ich noch nicht ganz verstanden, ich hab aber einen verdacht woran das liegt; wenn ich damit recht behielte würde das bei nem rewrite verschwinden. Wobeis letztlich auch nie passiert wäre, wenn ich nen Windowsmaintainer gehabt hätte.

Das mit den 64bit Systemen liegt imo an der breite der Datenbusse. Wenn ich über nen Datenbuss sowieso 2*32bit transferieren muss, dann befinden sich nach wesentlich weniger Lade Operationen die richtigen Werte in meinem Cache. Vorausgesetzt natürlich, der Programmierer kann was; in meinem Fall hab ich relativ viel Zeit damit verbracht das einigermaßen cacheeffizient zu gestallten, keine Ahnung ob mir das wirklich gelungen ist. Das komische Inteltool lief bei mir leider nicht.

EDIT: Das Maxwell teil ist mir sehr unsympatisch von den Seiten her. Ich würde eigentlich erwarten, dass ich irgendwo ein paket mit irgendwas ausführbarem bekomme und dann wird alles für mich gemacht.

Gruß

[Bergmon]

ja, das maxwell-dings ist halt nen profi-programm. allerdings fand ich die renderqulität auf den ersten blick ziemlich gut, sowie den physikalischen ansatz ;). keine ahnung jedoch, ob sie dort wirklich interferenz berechnen - wenn ja wäre das schon ziemlich anspruchsvoll.
außerdem hab ich das gefühl, dass die schon fast in echtzeit-render zeiten vorstoßen, wenn man nicht auf das finale bild wartet. dafür müsste man allerdings wissen, wann die ersten zwei-drei bilder auf den high-end systemen fertig waren.

wie sieht es eigentlich mit dem reflection-map ansatz aus?
man kann doch eine kleine szene mit wenigen polygonen und ein oder zwei lichtern für jedes polygon einer konkaven umgebung dieser szene (für konvex sollte es keine selfreflection geben) eine reflectionmap rendern? dann würde sich das radiosity nach ein paar renderpasses einstellen, so wie die infinity-reflektionen zwei gegenüberliegender spiegel. je nach szenen-strukturierung kann man dann das verhältnis "optische qualität - rendergeschwindigkeit" sehr weich einstellen. schatten sollte man dann nicht mehr explizit berechnen müssen, da man nur das licht mit mit seinen okludern betrachtet. abgesehen von alaising-problemen, wird die interferenz natürlich auch nicht betrachtet.

dann gibt es ja noch das photon-mapping. ist mit dem deferred-ansatz auch schon echtzeit-fähig, wie man hier sehen kann:
http://www.infinity-universe.com/Infini ... &Itemid=27
lightsmark wird vermutlich auch ähnliche technik verwenden. das sind jedoch alles hybride-ansätze, welche die massive parallele rechen-leistung einer grafikkarte versuchen sinnvoll zu nutzen. doch im endeffekt sind diese deferred-ansätze alle so 2.5d. echtes 3d ohne tricks braucht einfach massive rechenleistung - die formeln zum berechnen dazu exisitieren ja schon lange.

[Bergmon]

hast du schon mal überlegt, ob sich screenspace voxel lohnen? (ist mir gerade eingefallen)

[Lord Delvin]

Was meinst du mit screen space voxel? Ich wollte eigentlich ganz normale Voxelbäume in das rewrite integrieren.

[Bergmon]

ja, das mit den octrees wird auch erstmal das beste sein. kam mir auch in den sinn um die ray-test menge zu reduzieren.

screen space voxel dachte ich in etwas als einen screen-space tauglichen tiefenatlas:

man rendert zunächst die sichtbare szene mit allen okludern usw. in den tiefenbuffer ohne ztest und generiert sich dann zu jedem so gerenderten screenpixel-tiefenwert eine line-list, bei der jeder knotenpunkt ein tiefenwert entspricht(also maximaler overdraw). das geht nicht mit dx9, doch vermutlich mit den geometrie-shadern.
dann hat man für jeden bildschirm-pixel die vollständige tiefeninformation.
prob ist, dass die information nicht geordnet ist und somit wenig nützt. man muss also außerdem eine relation der einzelnen tiefenwerte innerhalb jedes bildschirmpixel finden, so dass man einfache strahlentests von jedem bildschirmpunkt in diese volumeninformationen durchführen kann. da häng ich gerade, weil ich auch nicht genau weiß, was man alles mit den neuen grafikkarten machen kann(beliebiger zugriff auf beliebige texturen aus shadern, texturerzeugung aus shadern, übergabe von erzeugten/bekannten texturen an shader, schleifen, etc.).
ziel war es die volumeninformation nur auf das nötigste einzuschränken mit den vorteil alles im screenspace zu berechnen und damit die grafikkarte zu nutzen. wenn einem das alles gelingt, kann man dann echtes screenspace-raytracing berechnen.
dazu benötigt man allerdings noch alle anderen umgebungsinformationen(für okluder außerhalb des view-fustrum). das erreicht man, in dem man den ersten schritt einfach insgesamt sechs mal für eine cubemap ausgeführt wird.
vermutlich ist das ne sinnlose idee, weil die tiefenwerte durch den render-alles-und-bilde-eine-tiefen-liste-pass einfach mal zu irreglulär verteilt sind, und nicht so schön auffindbar sind, wie in einem octree.