SaarCOR: Echtzeit-Ray-Tracing [Archiv]

zeckensack

2003-02-04, 07:53:41

Originally posted by Hellspawn
Hi leute!

Könnt mir vielleicht wer von euch erklären worin der vorteil von raytracing gegenüber polygon grafik besteht? Und womit arbeitet Raytracing? Kann man es hardwarebeschleunigen? usw hehe bin wissbegierig ;)

mfg Raytracing kann auch Polygonbasiert sein, das schließt sich nicht aus :)

Rasterizer (= PC-Grakas) zeichnen Dreiecke logisch gesehen nacheinander, und unabhängig voneinander. Innerhalb eines Dreiecks sind auch die einzelnen Pixel weitgehend unabhängig voneinander. Das ist sehr einfach parallelisierbar und deswegen sind hohe Leistungen auch vergleichsweise einfach zu erreichen.

Raytracer zerteilen erstmal das ganze Bild in Pixel und schießen pro Pixel einen 'Sehstrahl' durch, der zurückverfolgt wird bis er auf eine Oberfläche trifft. Von dort geht's dann weiter zu den Lichtquellen. Dabei wird immer geprüft, ob die Strahlen, die durch die Szene hüpfen, von anderen Oberflächen unterbrochen (solides Objekt), aufgeteilt (Halbtransparenz), oder abgelenkt (Brechung an Glas, Wasser, etc) werden.
Im Endeffekt wird so für jeden Pixel zurückverfolgt, wieviel Licht von dort an der gedachten Kamera ankommt.

Der Raytracer erzeugt also automatisch physikalisch korrekte Beleuchtung und Schattenwürfe, muß dafür aber bevor er überhaupt anfangen kann zu rechnen, die komplette Szene kennen. Und um Schnitte mit den Strahlen feststellen zu können, muß er diesen Datensatz auch laufend untersuchen.

Steht btw auch in der PCGH 2/2003, Seite 156
*hüstl*

Raytracing in Hardware zu machen, ist offenbar nicht ganz einfach und ein heftig umkämpftes Forschungsgebiet. Der Ansatz von den Jungs da oben ist IMO einer der besseren und könnte tatsächlich den Durchbruch bringen.

Labberlippe

2003-02-04, 09:02:25

:O

Junge sieht Quake3 genial aus.
Schade nur das noch einige järchen vergehen werden, bis so etwas am Bildschirm sehen.

Gruss Labberlippe

Mave

2003-02-04, 12:45:10

Gibt es bei Raytracing nicht auch irgendwo eine sinnvolle Grenze bei
der Anzahl an z.B. Oberflächen, von denen ein Strahl reflektiert wird?
Oder ist das für den Rechenaufwand egal (was ich mir nicht vorstellen kann)

Mave

2003-02-04, 17:21:07

Originally posted by Mave
Gibt es bei Raytracing nicht auch irgendwo eine sinnvolle Grenze bei
der Anzahl an z.B. Oberflächen, von denen ein Strahl reflektiert wird?
Oder ist das für den Rechenaufwand egal (was ich mir nicht vorstellen kann)

Hab den Artikel gelesen. Frage hat sich somit erledigt.

Dafür habe ich jetzt eine neue *g*. Mir ist nicht ganz klar wozu
der BSP Tree benutzt wird ? Um die geometrischen Objekte bzw. die Dreieckspunkte zu speichern oder die aktuellen Daten der Rays beim
Auftreffen auf ein Objekt ?

HiddenGhost

2003-02-04, 17:40:58

Von welchem Q3A Screen sprecht ihr eigentlich ??

Beschleunigt der genannte Chip wirklich Raytraycing. Ich kann mir irgendwie nur schwer vorstellen, dass es 3d Chips gibt, die nicht nach Rasterizing arbeiten ? Funzt das wirklich ?!?

Demirug

2003-02-04, 17:53:49

Originally posted by HiddenGhost
Von welchem Q3A Screen sprecht ihr eigentlich ??

Beschleunigt der genannte Chip wirklich Raytraycing. Ich kann mir irgendwie nur schwer vorstellen, dass es 3d Chips gibt, die nicht nach Rasterizing arbeiten ? Funzt das wirklich ?!?

Schau die mal das pdf an das ich oben verlinkt habe.

Ja der Chip (bzw die Chips) ist ein Hardwareraytracer. Ist aber nichts kommerzielles sondern ein Forschungsprojekt.

SShock3

2003-02-04, 18:27:43

Die Lightmaps von Quake 3 werden ja auch nach einem Raytracingverfahren generiert. Allerdings findet das alles natürlich vor dem eigentlichen Rendering statt, weil's ja sonst unspielbar langsam wäre. Oder täusche ich mich da jetzt ?

EDIT: Was wohl John Carmack dazu sagen würde ?
Der träumt bestimmt davon mal so'ne Hardware in den Händen halten zu dürfen.
Das ist ja praktisch sowas wie der Heilige Gral der Computergrafik.

GUEST

2003-02-04, 19:37:58

Das pdf gibs auch in Deutsch (nicht das hier nicht alle engl. könnten ;) )
Wie hoch schätzt ihr die reelen Marktchansen von dem Projekt ein? Würden ATI oder Nvidia soetwas auch "anfangen"?
Was meint ihr würde da rauskommen wenn eine Grafikkartenfirma wie Nvidia oder ATI das machen würden ? Ich meine In wie weit sich dann Raytracing in HW noch treiben lassen würde?

MFG GUEST

Demirug

2003-02-04, 19:48:15

Originally posted by GUEST
Das pdf gibs auch in Deutsch (nicht das hier nicht alle engl. könnten ;) )
Wie hoch schätzt ihr die reelen Marktchansen von dem Projekt ein? Würden ATI oder Nvidia soetwas auch "anfangen"?
Was meint ihr würde da rauskommen wenn eine Grafikkartenfirma wie Nvidia oder ATI das machen würden ? Ich meine In wie weit sich dann Raytracing in HW noch treiben lassen würde?

MFG GUEST

Primär gibt es hier mal wieder das Henne Ei Problem. Da sich die Technik sehr stark vom normalen Rendern unterscheidet braucht man eine spezielle API. Die Spieleentwickler werden aber nur wenig unterstützung dafür leisten wenn niemand Karten hat und es kauft keiner Karten wenn es keine Software gibt. Darum wird das mit dem RayTracing woll erst was wenn die grossen Hersteller Combi Chips bauen die beides können. Mit aktuellen DX9 Chips läst sich ja schon eine Art von Raytracing durchführen und je weiter die Programmierbarkeit zunimmt desto besser wird die Wahrscheinlichkeit das sich ein vollständiger Raytracer im Grafikchip programmiert werden kann.

SShock3

2003-02-05, 09:47:53

Eigentlich würde es ja auch schon reichen, wenn die Entwickler die derzeitig zur Verfügung stehende Technologie von aktuellen Grafikchips, besser ausnutzen würden. Ein Raytracer bleibt wohl zumindest für die nächsten 5 Jahre (wenn nicht noch länger) was die Qualität der Bilder angeht,pure Zukunftsmusik. Eigentlich ist es ja wircklich so, dass man eigentlich immer versucht hat sich an das perfekte Rendering eines Raytracers asymptotisch anzunähren, was ja auch Stück für Stück gelingt. Hoffen wir das beste

Kennung Eins

2003-02-09, 22:57:37

Originally posted by zeckensack
Raytracer zerteilen erstmal das ganze Bild in Pixel und schießen pro Pixel einen 'Sehstrahl' durch, der zurückverfolgt wird bis er auf eine Oberfläche trifft.Ist das nicht Raycasting ???

Demirug

2003-02-09, 23:10:03

Originally posted by Kennung Eins
Ist das nicht Raycasting ???

Auch.

Der unterschied ist das beim Raycasting nach dem man das nächste Hinderniss gefunden hat aufhört mit dem berechnen.

Beim Raytraceing wird der Strahl dann weiterverfolgt zu den Lichtquellen und/oder zu anderen Objekten.

Kennung Eins

2003-02-09, 23:49:34

Originally posted by Demirug

Auch.

Der unterschied ist das beim Raycasting nach dem man das nächste Hinderniss gefunden hat aufhört mit dem berechnen.

Beim Raytraceing wird der Strahl dann weiterverfolgt zu den Lichtquellen und/oder zu anderen Objekten. Hm. Raycasting: Wenn man einen Strahl losschickt, (normalerweise doch sicher von der Kameraposition), dieser trifft dann auf ein Objekt, dann gilt für diesen Punkt: "Pixel setzen". Lichberechnung erfolgt über Normalenvektor auf diesem Objekt.

Der Strahl zeigt ja weiter "geradeaus" und wird zu 99,999999% nicht auf die Lichtquelle treffen.
Wie kann man den dann noch zu den Lichtquellen weiterverfolgen? Biegen kann man ihn ja nicht :)

zeckensack

2003-02-09, 23:54:28

Demirug

2003-02-10, 00:07:07

Originally posted by Kennung Eins
Hm. Raycasting: Wenn man einen Strahl losschickt, (normalerweise doch sicher von der Kameraposition), dieser trifft dann auf ein Objekt, dann gilt für diesen Punkt: "Pixel setzen". Lichberechnung erfolgt über Normalenvektor auf diesem Objekt.

Der Strahl zeigt ja weiter "geradeaus" und wird zu 99,999999% nicht auf die Lichtquelle treffen.
Wie kann man den dann noch zu den Lichtquellen weiterverfolgen? Biegen kann man ihn ja nicht :)

klar biegen kann man in nicht. Aber das ist ja auch gar nicht notwendig.

Also unser Strahl ist auf der oberfläche eines Objekts aufgetroffen. Nun bestimmt man ein paar eigenschaften dieses Oberflächen Punktes. Die wichtigste ist ist erst mal der Spiegelanteil.

Ist dieser >0% spiegelt die fläche und es muss ein neuer Vektor in die Szene geschossen werden. Dieser neue Vektor berechnet sich aus dem alten und der normalen des Punktes und dann eben Einfallswinkel = Ausfallswinkel. Wenn dieser Strahl fertig grechent ist entsteht ein Farbwert der dann Anteilsmässig in den Endgültigen Farbwert einfliessen wird.

Ist der Spiegelanteil gelich 100% kann die Beleuchtungsberechnung entfallen. Ansonsten wird nun geprüft von welche Lichtquellen der Punkt beleuchtet werden könnte. Zu jeder Lichtquelle die bei dieser Prüfung übrig bleibt wird nun ein direkter Strahl ausgesandt. Kann dieser die Lichtquelle ohne behinderung erreichen wird für diesen Pixel für die entsprechende Lichtquelle der beleuchtungsanteil bestimmt. Die Formeln dafür sind die gleichen wie beim Rendern.

Alle Lichtquellenergebnisse werden addiert und mit dem Spiegelanteil verrechnet.

Kennung Eins

2003-02-10, 08:56:24

nochmal "hm".

Ich hab mal ein kleines Bildchen gemalt (s.u.).
Die roten Pfeile sind das Licht, der Blaue Strich ist mein Raycast-Strahl, der grüne Kreis der Schnittpunkt des Strahls mit einer der Würfelebenen.

Keiner der Lichtstrahlen zeigt als reflektierter Lichtstrahl in die Kamera.

Bei glatter Oberfläche des Würfels, und bei einer gerichteten Lichtquelle, da würde ich diese Seite des Würfels, wenn nicht sogar den ganzen Würfen, überhaupt nicht sehen.

Wenn ich das in OpenGL progge, einen Würfel ganz normal aus GL_QUADS erstelle, und dann da ein GL_POSITION Licht draufstrahle, sehe ich diese Fläche aber doch!
Warum?

Oder nimmt OpenGL per default ein "mattes" Material?

Demirug

2003-02-10, 09:19:16

Beim Licht wird der Strahl vom Auftreffpunkt zur Lichtquelle gerechnet und nicht die Strahlen die von der Lichtquelle ausgehen. (s.B.) Man prüft dabei dann ob der Strahl vom Auftreffpunkt zur Lichtquelle zu dem Menge der Strahlen gehört die von der Lichtquelle ausgehen.

OpenGL als RenderAPI kennt sowas wie eine Spiegeloberfläche von sich aus nicht. Spiegeleffekt muss man selbst bauen. Aus diesem Grund folgt OpenGL (und D3D auch) einen vereinfachten Beleutungsmodel. Es wird für jeden Vertex der Beleutungswert berechnet. Dabei spielen dann dinge wie Art und Parameter der Lichtquelle und des Material sowie die Lage von Lichtquelle und Vertex zueinader eine Rolle. Die entsprechenden Formeln kannst du der Dokumenatation entnehmen. Zwischen den Vertexen wird dann interpoliert.

Kennung Eins

2003-02-10, 09:34:56

:idea:

da lag also mein Fehler... merci beaucoup!
Nun ists mir klar...

syronth

2003-02-17, 21:04:27

Hm, das deutsche PDF ist mir zu allgemein gehalten, ich kann dort nichts lesen, womit der enorme Rechenaufwand verlustfrei reduziert wird. Wo ist der Trick - und der Haken dabei?
Steht im englischen PDF mehr außer dem groben Konzept? Noch zögere ich, mich mit meinen behäbigen Englisch hindurchzuquälen ;-) Es klingt für mich wie ein Fake, es wundert mich, daß die Profis hier das für realistisch halten. Gegenwärtig werden bis zu ganzen Renderfarmen eingesetzt (s. Kino) und nun soll eine einzige(r) Chip/Graka (annährend) dasselbe können? Klingt für mich reichlich unwahrscheinlich.

Demirug

2003-02-17, 21:21:51

Im deutschen steht im Prinzip das gleiche wie im englischen. In Englisch gibt es aber noch ein zusätzliche Dokument mit viel mehr Details:

http://graphics.cs.uni-sb.de/Publications/2002/Schmittler-AHardwareArchitectureForRayTracing.pdf

Hinter dem Projekt steht die UNI von Saarbrücken und Stanford. Dort macht man keine billigen Fakes.

Das ein Chip viel schneller Raytracen kann als die CPU liegt an der Spezialisierung. Versuche mal das gleiche was heute eine Grafikkarte rendert auf einer CPU zu rendern. Da liegen Welten dazwischen und das gleiche haben wir auch beim Raytracen nur mit dem unterschied das bisher noch niemand einen kommerzielen Raytracerchip gebaut hat.

syronth

2003-02-17, 21:58:56

Daß "in Hardware gegossene" Algorithmen schneller rechnen als entsprechend programmierte Universal-CPUs ist mir schon klar. Nur sind im Raytraycing enorme Rechenkapazitäten notwendig, die gegenwärtig eben entsprechend Hardware _auftürmen_, und die sich imho nicht so leicht wegdiskutieren lässt.
Diese in einer einzigen, handlichen Einheit unterzubringen erscheint mir etwas absurd, sei sie noch so spezialisiert. Also liegt für mich zwingend irgendein Haken verborgen.

Sollte ein Fünkchen Wahrheit drin stecken, so kann man aber sehr bald mindestens mit derartigen Karten im Profibereich (CAD) rechnen - der Impact wäre immer noch enorm genug, um Bereichsübergreifend förmlich für Hysterie zu sorgen. Da das Konzept zudem noch weniger Silizium verschlingt als die Transistormonster von nVidia/Ati und nicht einmal schneller RAM nötig ist, könnte durch irrwitzig niedrige Preise der Markt trotz der genannten Widerstände sehr kurzfristig umgekrempelt werden und die großen Hersteller von heute wären nur noch die Dinosaurier von gestern.

Ich werde mir die Sache mal näher ansehen mal 'ne Mail an C't schreiben - die wären sich auch sehr daran interessiert. Auch wenn meine Mail höchstwahrscheinlich im Wust von tausend anderen untergeht, ein Versuch's ist wert.

syronth

2003-02-17, 22:00:56

>> Hinter dem Projekt steht die UNI von Saarbrücken und Stanford. Dort macht man keine billigen Fakes. <<

Hmm, who know's, ob es sich hier nicht um einen intellektuellen Scherz handelt. Allein Namen traue ich nicht, obwohl sie gewichtig sind.

Demirug

2003-02-17, 22:08:44

Pat Hanrahan (Stanford) ist nicht der Typ für billige Fakes die Sache hat also schon Hand und Fuss.

Raytraceing ist eigentlich gar nicht so aufwendig und lässt sich hervorragend parrallel abarbeiten. Das "Problem" dabei ist das man für Raytraceing eine komplett andere API braucht und sich deshalb vorhanden Anwendungen nicht so einfach anpassen lassen.

zeckensack

2003-02-17, 23:04:28

syronth,
Skeptisch bin ich normalerweise immer, wenn ich was von HW-Raytracern höre, aber der scheint einem ganz guten Ansatz zu folgen:
Man macht sich zu Nutze, daß die Strahlen oft kohärent sind. Das heißt, statt jeden Strahl einzeln durchzurechnen, werden Bündel zu 64 Strahlen gemeinsam verfolgt, und erst bei Bedarf wird kleiner zerlegt. Dadurch wollen die Herrschaften vor allem Speicherzugriffe sparen, und ich finde schon daß die Erklärung vernünftig klingt :)

Einen Nachteil habe ich aber gefunden, und zwar scheint das Verfahren eine axis aligned BSP zu erfordern, womit es für Animation leider ungeeignet ist. BSP-Kompilation dauert für Echtzeitanwendung immer noch zu lange. Es wäre aber denkbar, daß das ganze trotzdem in der Lage ist, 'klassische' Tracer zu schlagen.

peanball

2003-02-18, 08:38:25

Kennt ihr noch diese Voxel-Engines von NovaLogic?
Vor allem in DeltaForce 2 oder ööhm... dem Panzerspiel - weiß den Namen nicht mehr genau.
Wenn man jetzt das Level selbst als BSP aufbaut und von dem Chip rechnen lässt und die Figuren mit normalen Shadern, die dann eh besser aussehen (multitexturing etc...) kombiniert, hat man sicherlich seeeehr interessante Ergebnisse.
OK, Schatten der "Actors" im Level müssen dann aber wieder gepfuscht werden. Tag/Nacht-Wechsel könnte dann aber die Raytracing-Engine übernehmen.

edit:

was ich sagen will: Voxels durch Hardware-Raytracing ersetzen.

zeckensack

2003-02-18, 09:28:13

Da muß ich dich enttäuschen, die Voxel-Engines von Novalogic benutzen garkeine 'richtigen' Voxel (ebensowenig wie Outcast).
Das Verfahren was dort zur Anwendung kommt basiert auf zweidimensionalen Höhenfeldern, oder auch height maps. Das 'darf' man jetzt übrigens auch displacement mapping nennen ;)

Mave

2003-02-18, 18:13:26

In dem pdf von dem demirug sprach steht auch das sie Multisampling getestet habe. Handelt es sich hier nicht eher um eine art Supersampling? Sie nehmen einfach jeden Strahl vierfach. Multisampling müsste doch auch möglich sein. Also schauen ob ein Strahl ein Objekt trifft, dann aufteilen in z.B. vier "Unter" Positionen und nur wenn ein bis drei davon nicht auf das objekt treffen mit diesen weiter machen ???

peanball

2003-02-19, 09:17:49

Voxels sucken eh, in jeder Hinsicht...

Mit richtigen Voxels hätte man auch Höhlen oder so machen können...
Schon eine krasse Technik eigentlich aber ziemlich rechenaufändig.

Die Engines von NovaLogic - besonders der "Voxel" Teil - sahen eh total beschissen aus. Finde ich zumindest.

Demirug

2003-02-19, 09:39:09

Originally posted by Mave
In dem pdf von dem demirug sprach steht auch das sie Multisampling getestet habe. Handelt es sich hier nicht eher um eine art Supersampling? Sie nehmen einfach jeden Strahl vierfach. Multisampling müsste doch auch möglich sein. Also schauen ob ein Strahl ein Objekt trifft, dann aufteilen in z.B. vier "Unter" Positionen und nur wenn ein bis drei davon nicht auf das objekt treffen mit diesen weiter machen ???

Ja man könnte theoretisch sowohl Super wie auch Multisampling AA durchführen. Der Unterschied ist nur wieder einmal das für SSAA kaum bis gar keine Änderungen an der Hardware erforderlich sind. Für MS muss die Hardware eben entsprechend ausgelegt werden. Ein MS Verfahren in Verbindung mit einem Raytracer müsste wie folgt funktionieren.

Jeder Strahl wird in x Sub strahlen zerlegt. Die Anordnung dieser Strahlen zueinander spielt dabei die gleiche Rolle wie das Grid beim "normalen" AA. Die Strahlen werden nun alle in die Szene verfolgt bis sie auf ein Object auftreffen. Hier kommt nun das Multisampling zum Einsatz. Für alle Strahlen eines Pixels die auf das gleiche Object treffen wird nur einmal der Beleutungs einfluss, Reflectionswert und winkel sowie die Materialfarbe bestimmt.

Unregistered

2003-02-27, 23:34:40

Originally posted by syronth
>> Hmm, who know's, ob es sich hier nicht um einen intellektuellen Scherz handelt. Allein Namen traue ich nicht, obwohl sie gewichtig sind. <<

Es is bestimmt kein Fake.
Sondern das "Lieblingskind" von meinem Prof ;)

Den grössten Performancegewinn wird meines Wissens durch geschickte/durchdachte Datenstrukturen (er meinte mal in einer Vorlesung, dies allein würde Faktor 15 gegenüber normalen RT-Verfahren ausmachen) und viel Lowlevelprogrammierung.
Auf der Hardwareebene wurde halt alles genau auf das Verfahren angepasst.

Und viele machen hier den Fehler, die Fortschritte mit denen grosser Firmen zu vergleichen.
Da sitzen keine hunderte Leute hintendran, sondern nur sehr wenige. Der gesamte Lehrstuhl ist nicht soo riesig. Und OpenRT/SaarCOR sind nur 2 Forschungsbereiche von vielen (auf der Cebit is zum Beispiel noch die MultimediaBox zu bewundern ;) ).
Das diese Leistungen auch von den Firmen wie Nvidia und Ati gewürdigt werden, sieht man ja daran, dass die Graphics Hardware 2002 in SB an der Uni war.

Unregistered

2003-02-28, 08:40:43

Originally posted by Unregistered

Es is bestimmt kein Fake.
Sondern das "Lieblingskind" von meinem Prof ;)

Den grössten Performancegewinn wird meines Wissens durch geschickte/durchdachte Datenstrukturen (er meinte mal in einer Vorlesung, dies allein würde Faktor 15 gegenüber normalen RT-Verfahren ausmachen) und viel Lowlevelprogrammierung.
Auf der Hardwareebene wurde halt alles genau auf das Verfahren angepasst.

Und viele machen hier den Fehler, die Fortschritte mit denen grosser Firmen zu vergleichen.
Da sitzen keine hunderte Leute hintendran, sondern nur sehr wenige. Der gesamte Lehrstuhl ist nicht soo riesig. Und OpenRT/SaarCOR sind nur 2 Forschungsbereiche von vielen (auf der Cebit is zum Beispiel noch die MultimediaBox zu bewundern ;) ).
Das diese Leistungen auch von den Firmen wie Nvidia und Ati gewürdigt werden, sieht man ja daran, dass die Graphics Hardware 2002 in SB an der Uni war.

Hi;

kann man mit dem System jetzt auch bewegte Szenen in Echtzeit rendern, oder nur einzelne Frames, wie hier spekuliert wurde.

Danke

Flash2000

2003-02-28, 10:08:50

Originally posted by Unregistered
Hi;

kann man mit dem System jetzt auch bewegte Szenen in Echtzeit rendern, oder nur einzelne Frames, wie hier spekuliert wurde.

Danke

Momentan muss man eine BSP-Hierarchie vorberechnen, was sehr rechenaufwendig ist. Dies geschieht dann in einem Preprocess. In einer solchen statischen Szene kann man sich danach in Echtzeit bewegen, die Geometrie darf sich dann aber nicht mehr wesentlich ändern. Man kann den Algorithmus sicher aufbohren, dass die BSP-Hierarchie in engen Grenzen dynamisch angepasst werden kann - dies ist aber sicher nicht Aufgabe der aktuellen Engine. Es ist so ähnlich wie bei aktuellen Radiosityberechnungen: Viel viel Vorberechnung, danach kann man sich in den statischen Umgebungen flott bewegen.

Flash2000

2003-02-28, 10:28:23

Ich will damit nicht sagen, dass Dynamik überhaupt nicht möglich wäre. Wenn sich nur ein geringer Prozentsatz der Geometrie zwischen Frames ändert kann man schon was machen. Nur die Grundidee ist es halt statisch.

Mave

2003-02-28, 14:53:35

Die Beleuchtung wäre aber dynamisch möglich ?
Also sich ändernde Lichtstärke und Position der Lichtquellen?

Unregistered

2003-02-28, 15:25:16

Originally posted by Mave
Die Beleuchtung wäre aber dynamisch möglich ?
Also sich ändernde Lichtstärke und Position der Lichtquellen?
Ja, Anzahl und Parameter der Lichtquellen kann man variieren, die Zahl der Lichtquellen geht aber linear in die Laufzeit ein, wenn man reines Raytracing implementiert (ohne Distanzdämpfung). Möchte man dann auch noch korrektes Shading in höheren Rekursionsstufen (also nach Reflexion und Transmission) sehen, steigt die Laufzeit ins Unerträgliche (Auflösung * 2^Rekursionstiefe * Lichtquellen). Das wird aber für Real-Szenen eher unwahrscheinlich sein.

Mave

2003-03-01, 15:02:56

Das der Aufwand mit steigender Rekursionstiefe 2^Rekursionstiefe steigt kann ich mir nicht vorstellen und die Tabellen im pdf sagen auch was anderes aus. Die FPS sinken nur auf 81% bei Rekursionstiefe drei. Mehr Lichter bedeuten allerdings ein starkes Absinken der FPS (bei drei Lichtern nur noch 25%)

Flash2000

2003-03-02, 12:29:33

Originally posted by Mave
Das der Aufwand mit steigender Rekursionstiefe 2^Rekursionstiefe steigt kann ich mir nicht vorstellen und die Tabellen im pdf sagen auch was anderes aus. Die FPS sinken nur auf 81% bei Rekursionstiefe drei. Mehr Lichter bedeuten allerdings ein starkes Absinken der FPS (bei drei Lichtern nur noch 25%)

Der exponentielle Verlust ergibt sich theoretisch. In der Praxis sind nicht alle Öberflächen spiegelnd UND transparent. Die Rekursion bricht bspw ja ab, wenn man auf ein rein diffuses Objekt trifft. Für "typische" Szenen mag ein Verlust von 20-50% korrekt sein.

micki

2003-03-03, 01:54:00

raytracing hardware? also der kyro chip macht raycasting in hardware, das rekursiv und "schawub" hat man raytracing in hardware... vielleicht kann man das auch auf vertexprogramms und fragmentshadern machen, in der arbeit hab ich einen radiosity renderer damit gemacht, also ginge raytracing auch.

man kann 16 textur reads machen, eine textur kann 128bit/pixel haben, weil floating point. in 64werten (16reads*4float) kann man eventuell genug einbauen um 4 ebenengleichungen + ein längenwert abzuspeichern (und das reicht erstmal um für ein triangle einen trace zu machen). den ergäbnis farbwert, die postion, reflection vector + refraction müßte man wohl im zweiten pass durchrechnen, aber das sollte möglich sein denk ich mir....

übrigens ist der VP-3dlabs chip sehr gut programmierbar, darauf könnte sowas vielleicht genial gut laufen...

MfG
micki

*auchsonegrakahabenwillfürexperimente*

Demirug

2003-03-03, 08:09:24

Nein Kyros arbeiten nicht mit Raycasting. Auch dort haben wir es mit einem Chip zu tun der einen Z-Buffer für die Tiefensortierung benutzt.

micki

2003-03-03, 11:49:37

der kyro hat keinen zbuffer, er arbeitet nach dem deferred rendering verfahren, schau dir einfach mal den passenden artikel bei 3dcenter.de an, er sammelt sich die ganze geometriedaten und zerteil dann den ganzen bildschrim in 32*16(?)pixel-blöcke, dort rechnet er dann den ersten trace durch, das ist der grund, weshalb er als einziger (mir bekannter) chip auch in hardware transparente flächen richtig sortiert zeichnen kann, weil er nicht den zbuffer nutzt, sondern pro pixel traced.

MfG
micki

Demirug

2003-03-03, 12:16:38

Originally posted by micki
der kyro hat keinen zbuffer, er arbeitet nach dem deferred rendering verfahren, schau dir einfach mal den passenden artikel bei 3dcenter.de an, er sammelt sich die ganze geometriedaten und zerteil dann den ganzen bildschrim in 32*16(?)pixel-blöcke, dort rechnet er dann den ersten trace durch, das ist der grund, weshalb er als einziger (mir bekannter) chip auch in hardware transparente flächen richtig sortiert zeichnen kann, weil er nicht den zbuffer nutzt, sondern pro pixel traced.

MfG
micki

Er hat einen Z-Buffer. Nur ist dieser direkt in der Logic des Chips eingearbeitet. Das mit den Blöcken und dem sammeln habe ich ja nicht abgestritten. Sonst wäre es ja auch kein TBDR.

Das ermitteln der sichtbaren Pixel arbeitet nach wie vor nach dem Z-Buffer Prinzip. Die Berechung der Z-Korrdinaten ist anders als bei einem IMR gelöst aber das ändert am Prinzip nichts.

Und das die Rheienfolge unabhängige Transparenz (eine Technik die PowerVR beherscht) auf den Kyros wirklich funktioniert habe ich bis zum heutigen Tag nicht gesehen. Das mag aber auch damit zuzusammenhängen das ein solches Feature weder von DirectX noch von OpenGL direkt unterstützt wird.

Ich werde bei Gelegenheit mal die Threads raussuchen wo das schon mehrfach besprochen wurde.

micki

2003-03-03, 12:34:34

in früheren dx versionen konnte man dieses feature enablen und auf der dreamcast ist es grundsätzlich an.

http://www.3dconcept.ch/reviews/3dprophet4500/6.htm
steht wie das läuft. im grunde wird jedes dreieck "aufgeteilt" in 4 ebenen, mit den ersten berechnungen ermittelt man dann den schnittpunkt des eye-rays mit der dreiecksebene und dann mit 3 dotprodukts (4float vectoren) ob der ebenenschnittpunkt im dreieck liegt.

MfG
micki

Demirug

2003-03-03, 13:45:19

Originally posted by micki
in früheren dx versionen konnte man dieses feature enablen und auf der dreamcast ist es grundsätzlich an.

http://www.3dconcept.ch/reviews/3dprophet4500/6.htm
steht wie das läuft. im grunde wird jedes dreieck "aufgeteilt" in 4 ebenen, mit den ersten berechnungen ermittelt man dann den schnittpunkt des eye-rays mit der dreiecksebene und dann mit 3 dotprodukts (4float vectoren) ob der ebenenschnittpunkt im dreieck liegt.

MfG
micki

Jetzt glaube ich zu wissen wo unser gegenseitiges Verständnissproblem ist.

Die Tatsache das in den Kyros aufgrund einer Pixelposition der Z-Wert für ein Dreieckbestimmt wird macht den Chip damit noch nicht zu einen Raycaster. Diese Berechnung ist zwar auch beim Raycasten notwendig aber eben nicht nur dort. Im Endeffekt ist diese Berechnung in jedem 3D Chip mit eigenem TriSetup enthalten. Das Ergebniss welches durch das HSR der Kyros erzeugt wird entspricht zwar dem was man auch mit Raycasting erreichen könnte nur ist das Verfahren das man in den Kyros benutzt viel Resourcenschonender.

Was die Kyros nun wirklich machen ist ganz einfach folgendes:

Über das zerlegen in die Tiles sind wir uns ja schon einig.

Für jede Tile werden nun die gespeicherten Dreiecke in genau der ursprünglichen Rheienfolge eingeladen. Für jeden Pixel innerhalb der Tile wird nun bestimmt ob das Dreieck diesen Pixelbedeckt und welcher Z-Wert sich ergibt. Falls notwendig wird ein Z-Vergeleich durchgeführt und bei Bedarf der "Interen" Z und Pixel-Buffer aktualisiert. Der Pixelbuffer enthält keine fertigen Pixel sonder verweist auf die zum enstsprechenden Dreieck gehörenden Rendersettings. Sind alle Dreiecke durchgelaufen wird der Pixel-Buffer der nächsten Einheit übergeben welche dann mit den dort vorhanden Angaben die entgültige Pixelfarbe bestimmt.

micki

2003-03-03, 16:16:22

ja aber genau so läuft auch raytracing, du hast für jeden pixel einen strahl, damit durchstichst du ein dreieck(ebenfalls in beliebiger reihenfolge) und vergleichst den "internen" z-wert einer variable, da der kyro gleichzeitig 16*32 pixels durcharbeitet pro poly, sollte man das nicht zbuffer nennen, da in raytracern mit ISSE auch des öfteren 2 oder 4 z-werte gespeichert werden und ab wann würdest du's buffer nennen? ich würde es so nennen wenn es nichtmehr in einem register des chips steht und gebuffer werden müßte, das ist aber beim kyro nicht der fall.

das verfahren des kyro ist eher raytracing als standart zbuffer rastarisation. 4 ebenen durch die ein strahl geschickt wird aus dem eyeview und mittels mathematischer berechnungen und nicht mittels bruteforce z-buffer rastarisation wird bestimmt ob der pixel auf dem screen zu sehen ist... nichts anderes macht ein raytracer.

ich glaube du hast den artikel zu schnell überflogen, sonst würdest du sehen dass " Der Pixelbuffer enthält keine fertigen Pixel sonder verweist auf die zum enstsprechenden Dreieck gehörenden Rendersettings." nicht zutrift, es ist der blockbuffer, der speichert sich eine polygonlist der buffer aber enthällt massig pixel.

damit passiert vor deiner folgenden aussage:
" Sind alle Dreiecke durchgelaufen wird der Pixel-Buffer der nächsten Einheit übergeben welche dann mit den dort vorhanden Angaben die entgültige Pixelfarbe bestimmt."
das raycasting, block für block. und das ist das, was dem kyro den vorteil bringt, den man hat einen durchschnittoverdraw von ~3.5 gemessen, da der kyro pro takt ein poly testet und das für 16*32 pixel, muss er vielleicht nur 7 bis 10 polys (also takte) testen und füllt dann 16*32 pixel, was sehr hoch ist verglichen mit anderen pipline bei 8pixel pro takt... nur die textur nachladen und blenden und bla... dauert eben.

ich hab mir wirklich sau viele paper zur kyro durchgelesen, die haben selber gesagt, dass es raytasting ist. genau so zu rasterisen wie normale karten würde entweder zuviel clipping kosten oder zuviel pixelleistung wegen dem band-gart glaube ich.

MfG
micki
MfG
micki

Demirug

2003-03-03, 17:37:03

micki, ich halte mich vorzugsweise an die Patente. ;)

Ob man die 16*32 Register welche die Z-Werte einer Tile halten nun als Z-Buffer Buffer oder als Z-Registerfeld oder wie auch immer bezeichnet ist ja im Endeffekt auch egal. Ich ziehe es aber normalerweise vor eine Trennung zwischen Speicherzellen und Register vorzunehmen. Und da mehr Z-Werte gespeichertwerden müssen als gleichzeitig bearbeitet werden können ist das für mich nun mal ein Z-Buffer. Aber das ist Ansichtssache und wegen einem Begriff möchte ich mich nicht streiten. Das entscheidene ist das für die Z-Werte normalerweise kein Speicher im Grafikkarten RAM und auch keine Bandbreite gebraucht wird.

Das HSR des Kyros ist sogar ganz übles bruteforce. ;) Für jedes Dreieck egal wie gross es ist wird für alle Pixel der Tile der Z-Wert berechnet. Da dies aber alles innerhalb des Chips und massiv parralle abläuft kümmert das keinen.

Ich wiederhole mich zwar jetzt schon wieder, aber der Kyro ist kein Raycaster und erst recht kein Raytracer. Beim Raycastverfahren wird für jeden Pixel ein strahl erzeugt und dann für jedes Dreieck der Schnittpunkt mit diesem Strahl bestimmt. Und dabei das Dreieck das dem Betrachter am nächsten liegt ermittelt. Diese Technik erfordert es das für jeden Pixel alle Dreiecke durchsucht werden müssen. Selbst wenn man eine Tiling Technik einsetzt um die Anzahl der möglichen Dreiecke pro Pixel zu reduzieren hat man einen Bandbreiten fresser.

Die Kyrochips arbeiten viel intelegenter. So wird zum Beispiel auch nicht für jeden Pixel die komplizierte Berechung des Z-Wert durchgeführt sondern nur einmal pro Dreieck zwei Delta Werte bestimmt und dann die Z-Werte der einzelnen Pixel durch eine einfache fortlaufende Addition bestimmt.

Aber ich habe den Eindruck das du mir sowieso nicht glaubst weswegen ich mir jetzt weitere Erklärungen sparen.

micki

2003-03-03, 17:58:44

tja, solange du mir das nicht glaubst, der artikel dessen link ich postete ist auf deutsch und besagt wohl dass die ein patent nutzen bei dem die pro dreieck 4 ebenen speichern... wozu wenn nicht zum schnittpunktberechnen?

glaubs mir nicht, dann ist halt der artikel von concept3d falsch... und die haben ein patent umsonst eingetragen.

MfG
micki

Demirug

2003-03-03, 18:28:12

Originally posted by micki
tja, solange du mir das nicht glaubst, der artikel dessen link ich postete ist auf deutsch und besagt wohl dass die ein patent nutzen bei dem die pro dreieck 4 ebenen speichern... wozu wenn nicht zum schnittpunktberechnen?

glaubs mir nicht, dann ist halt der artikel von concept3d falsch... und die haben ein patent umsonst eingetragen.

MfG
micki

Der Artikel ist nicht direkt falsch. Die mathematischen Grundlagen sind alle richtig. Die Technische umsetzung in den Kyros ist allerdings etwas anders weil PowerVR dort bestimmte Mathematische Tricks benutzt. Zudem haben reine Raycaster auch gewisse Kombatibilitätsprobleme bezüglich des Stencilbuffers und spielereien mit dem Z-Test die in den Kyrochips nicht zu finden sind.

Ich vermute mal das der Autor des Artikels nur Zugriff auf die alten Patente von 1995/96 hatte welche die neuerungen für Serie3 natürlich nicht enthalten. Das ist ja das Problem mit den Patenten das sie immer erst lange nachdem die entsprechende Hardware erschienen ist ebenfalls öffentlich werden.