Wollte mal kurz auf folgende Newsmeldung aufmerksam machen, die mir sehr interessant vorkommt - und eventuell auch einen Vorgeschmack der nicht ganz so fernen Zukunft von CG bietet:

http://www.golem.de/0406/31631.html

Die verwendete Hardware ist nicht gar so weit von dem entfernt, was sich auch ein normaler User leisten kann - IMHO wird es in Zukunft ohnehin eher darum gehen, massiv parallele Systeme aufzubauen und intelligent (fehlertolerant) anzusteuern, anstatt mit viel Aufwand immer noch schnellere Boliden aufzustellen.
Ob sich eine solche Technik auch im Heimbereich durchsetzen wird, bleibt abzuwarten - ich denke aber eigentlich schon.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Hey,
aber wenn die Hardware bereit ist,
wird es dann von euch auch eine OpenRT-Unit geben?
Ich glaub schon das sich das durchsetzt.
Oder vielleicht wird Delphi
von den OpenRT Entwicklern (Elchtest?)
gleich unterstützt?
Das war auch im GameStar.

_________________
Diese Signatur ist defekt. Bitte wählen Sie die Numer 12846712894671893230917497617383216 (gültig ab 32.13.2671)

Auf der Seite der Gamestar ist ein Streitgespräch zwischen dem Chefentwickler von NVidia und dem Professor aus Saarbrücken, der diese Raytracing HW entwickelt hat abgedruckt.
http://www.gamestar.de/magazin/specials/hardware/17734/

Vielen Dank für den Link, ich habe leider erst jetzt Zeit gefunden, mir das Ganze durchzulesen - leider hat mich der Report nicht besonders befriedigt, daher möchte ich jetzt meine eigene Meinung dazu loswerden:
Das ist ja nicht mehr wirklich schön, wie die beiden rumkeppeln wie kleine Kinder. Anfangs schien Slusallek die besseren Argumente zu haben, fiel mir dann aber auch unangenehm auf, wie er versuchte seine eigene Hardware zu propagieren (vor allem nachdem er vorher auf seine Unabhängigkeit als Unimitarbeiter gepocht hatte - dann aber kann man etwas mehr Offenheit und weniger Werbung erwarten, an sich sollte "Lehre und Forschung" nicht von Profilierungstendenzen gezeichnet sein - bei Kirk war's ja ohnehin klar, dass er NVidia Hardware verteidigen "muss").

Nachdem ich mich vor einiger Zeit auch intensiv mit der Thematik beschäftigt habe, kann ich versichern, dass Raytracing sich wunderbar parallelisieren lässt (die Schwierigkeit bei der Programmierung massiv paralleler Systeme ist ja, dass es durchaus nicht einfach ist, "gute" Algorithmen dazu zu entwickeln - Strahlverfolgung kann aber für jedes Pixel unabhängig berechnet werden, sodass kein Prozessor auf das Ergebnis eines anderen warten muss (etwa könnte jede Scanline einem anderen Prozessor zugeordnet werden) - genügend Speicherbandbreite vorausgesetzt, muss man hier nicht besonders kreativ sein.

Aus eben diesem Grund erscheint mir Slusalleks Argument, dass ihre proprietäre Hardware etwa einem Cluster von 20 AMD Prozessoren im Bezug auf Homecomputing vorzuziehen sei, eher schwächlich: das weiß er auch selbst in Wirklichkeit besser, dass 20 existierende Prozessoren (egal welchen Typs) billiger sind, als irgendwelche proprietäre Hardware, bzw. dass es bereits heute mit Consumerhardware (Prozessorplatinen) möglich wäre, ein solches Cluster in einem normalen PC Gehäuse unterzubringen.
Wer weiß, vielleicht kann man in Zukunft Rechenpower mit Steckplatinen aufrüsten, wie heute den Ramspeicher.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Mir ist da folgendes aufgefallen:
1) Kirk meinte, dass ein Großteil des Chips für die Shader zuständig ist, und dieser große Anteil, dann natürlich auch bei den Raytracer Karten vorhanden sein müßte. Ich vermute dann würden 90MHz nicht mehr ausreichen. Diese Raytracer Karte macht ja nur normales OpenGL Licht.

2) Ich stimme dem NVidia Entwickler zu, wenn er meint für den ersten Schnittpunkt wäre Rendern besser und für den Rest dann bei Bedarf Raytracing im Shader. Diese Raytracing Effekte wie z.B. die runden Spiegel benötigt man vermutlich nur an ganz wenigen Stellen. Dafür dann überall Raytracing zu machen ist ja auch nicht unbedingt sinnvoll.

3)Ich kann mir zudem nur schwer vorstellen, daß es vom Prinzip her effizienter sein soll, für jeden Pixel den Strahl zum Licht zu testen und dabei natürlich Schnittpunkte mit der Geometrie zu berechnen, an Stelle ein paar Mal den im Stecil Buffer +1 oder -1 zu rechnen oder die Entfernung des nahsten Schnittpunktes direkt aus der Shadowmap zu lesen.

4)Die Karten berechen dank den ganzen ZBuffer Optimierungen heutzutage sowieso nur noch die sichtbaren Pixel. Sogar im Stencil Schatten läuft alles schneller, weil der Licht Shader weniger oft ausgeführt wird. Mit den OcclusionQueries ist es nicht notwendig die gesammte Geoemtrie auf der Karte zu haben. Dafür gibt es bereits mehrere Demos (www.inf.bme.hu/~kenez/occl.html und die PowerPlant Demo bei www.delphi3d.net). Das Problem mit den verdeckten Flächen ist bereits allgemein gelöst. Es gibt noch so Extensions wie nvx_conditional_render die das ganze noch besser anwendbar machen.

5) Den ganzen Demos sieht man bislang nicht an, dass dafür Raytracing notwendig wäre. Die beiden Kugeln müßten in einem Spiel sowieso noch mit einer Bumpmap belegt werden und dann würde auch eine Cubemap ausreichen um das zu Rendern. Das geht ab einer GF3. Ob es wirklich rund ist, ist ja egal, solange die Kugel eben kleiner unterteilt ist, als die Pixel groß sind, was ja heutzutage wenn es denn unbedingt sein soll, machbar wäre.

6) Auch Rendering ist parallelisierbar und das wird ja in allen Karten auch gemacht. Bei der Voodoo2 ging das ja ganz gut mit mehreren Karten.
Auch bei professionellen Film Szenen wird nur in Ausnahmefällen Raytracing benutzt.

Ich bin mir nicht sicher ob Raytracing der bessere Weg ist.

Ray-Tracing lässt sich auf Radiosity erweitern
Ich glaube schon, dass Ray-Tracing eine fabelhafte Möglichkeit ist.
Nur weil der Rasterizer der heutigen Hardware so sehr optimiert ist...
Nein, das ist kein Grund nicht etwas neues zu entwickeln.
Man sollte einmal Hybrid-Karten produzieren, mit Ray-Tracing und der Pipeline.
Yeah, meine Meinung.

_________________
Diese Signatur ist defekt. Bitte wählen Sie die Numer 12846712894671893230917497617383216 (gültig ab 32.13.2671)

@Lars
Ich stimme dir in allen Punkten zu, auch darin, dass das Gesehene nicht besonders beeindruckend war, halte aber die Methode für jede Aufgabe immer spezialisiertere Chips zu entwickeln für suboptimal.

Dass "normale" Rasterizer so schnell nicht abgelöst werden ist ohnehin klar - außerdem lassen sich auch "normale" Vertex- und Fragmentprogramme wunderbar parallelisieren, da es zur Zeit ohnehin voneinander unabhängige Entitäten sind. Raytracing ist auch nicht unbedingt korrekt, sondern auch nur ein "Modell" der Darstellung (eventuell wird die Darstellung von 3D-Daten auf einem 2D-Schirm ohnehin in ein paar Jahren obsolet )

IMHO ist der Vorteil von Raytracing nicht, dass es "besser" oder schöner ist, als herkömmliche Methoden 3D-Daten in Echtzeit zu visualisieren, sondern v.a. einfacher. Man braucht dazu halt keine spezialisierte Hardware, sondern mit einem gar nicht mal so schnellen Prozessor, den man dafür in Massen zu einem parallelen System zusammenschließen kann, lässt sich - eben auf Grund dieser Einfachheit - ein brauchbares System kreieren.
Eventuell ein schneller Prozessor, der für Transformationen zuständig ist, eine Menge langsamerer Prozessoren, die sich die tatsächlich gerenderten Pixel aufteilen, sollten eigentlich schon heute in durchaus leistbare Hardware umgesetzt werden können.
Der SLI Modus der Voodoo 2 Karten besteht meines Wissens auch darin, dass sich die beiden Karten einfach die horizontalen Scanlines aufteilten, die Füllrate konnte damit beschleunigt werden, T&L gabs noch nicht (und wäre durch sowas auch nicht beschleunigt worden).

Der Nachteil von "normalen" Rasterizern ist nicht, dass sie qualtitativ schlechter wären, aber es ist umständlicher ihnen die gewünschten Effekte zu entlocken. Ein Raytracer braucht viel mehr Rechenpower - da er sich aber sehr gut parallelisieren lässt, können das durchaus viele gleichartige langsame Prozessoren sein - die dann eventuell (aber nicht notwendigerweise) in einem Chip zusammengefasst werden (ein heutiger Prozessor kann im Vergleich zu früheren Modellen auch als Multiprozessorsystem gesehen werden, bei dem jeder Teil aber auf eine andere Aufgabe spezialisiert ist).

@uzingLG
diese Hybriden sind ja im Prinzip schon da, als man solche Funktionen theoretisch auch mit einem komplexen Fragmentprogramm umsetzen kann - wie Lars bereits anmerkte, könnte man dies dann an den Stellen tun, an denen es am Beeindruckendsten aussieht.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/