Wann wird es vielleicht mal Raytracing-Grakas geben??

[Thanatos]

Hi :wave:

In der neuesten PCGH habe ich einige Bilder gesehen die mit Raytracng gemacht wurden, und naja es sah sehr gut aus (naja, raytracing ist ja nicht wirklich was neues).

Aber was wirklich interessant war............es wurde auch berichtet das ene Forschungseinrichtung daran arbeitet wie man Raytracing i chtzeit, und auf Grakas machen kann.

Sie habe auch schon einige Prototypen, und diese liefern nach ihrer Ausage schon "Spektakuläre effekte".

Hört sich schonmal sehr gut an, nun meine frage, wann könnte man den schon ungefähr mit solchen Karten Rechnen =)



:uhippie:PEACE!:uhippie:


Thanatos

[PrefoX]

is schon alt, gibt nen chip der is mit 90MHz getaktet und kann raytracing in echtzeit aber zu welchem preis?

es gibt methoden die sehen nahezu genausogut aus und brauchen viel weniger power.
raytracing brauch man net wirklich um gute grafik zu bekommen.

mach dir mal lieber sorgen ob ein radiositychip oder global illuminationchip kommt, sowas brauch die welt :)

[aths]

Hört sich schonmal sehr gut an, nun meine frage, wann könnte man den schon ungefähr mit solchen Karten Rechnen =)Das düfte noch lange dauern.

[RLZ]

is schon alt, gibt nen chip der is mit 90MHz getaktet und kann raytracing in echtzeit aber zu welchem preis?
Wie gut das Prototypen von Nvidia und ATi ja soooo billig sind. :rolleyes:

es gibt methoden die sehen nahezu genausogut aus und brauchen viel weniger power.
Dann erzähl mal....

mach dir mal lieber sorgen ob ein radiositychip oder global illuminationchip kommt, sowas brauch die welt :)
Inwiefern sollten sich solche Chips von nem Raytracingchip unterscheiden?

[Monger]

Irgendwie überzeugt mich Raytracing nicht wirklich. Wenn man versucht, mit einem einheitlichen Renderverfahren alles zu erschlagen, kann das imho unmöglich performant sein...
Beispiel Doom3: Die Stencilschatten wurden vor gar nicht so langer Zeit noch als großer Wurf gedeutet. Endlich einheitliche Beleuchtung, endlich keine prinzipiellen Unterschiede zwischen Charakteren und Levelbau mehr...

Aber jetzt wo ich Doom3 gesehen habe, kann ich mir nicht vorstellen, dass das der große Wurf wird. Wie der Rechenaufwand mit mehr Polygonen explodiert, ist durch nichts auszugleichen.
Deshalb verwendet ja die Unreal3 Engine anscheinend drei verschiedene Beleuchtungssysteme, um wirklich für jeden Fall das Optimum bieten zu können.

Ich hab mich noch nicht ausreichend mit Raytracing beschäftigt, aber ich wette das hat auch seine massiven Schwächen. Wie sieht es z.B. mit offenem Gelände aus? Was passiert, wenn ich einen Lichtstrahl erstmal an ein zwei Kilometer entferntes Ziel senden muss, um dort festzustellen dass die leichten Schattierungen eines Blattes und der leichte Dunstkreis eines furzendes Eichhörnchens meinen Lichtwert für diesen Pixel um 0,0005% dimmen?

[RLZ]

Irgendwie überzeugt mich Raytracing nicht wirklich. Wenn man versucht, mit einem einheitlichen Renderverfahren alles zu erschlagen, kann das imho unmöglich performant sein...
Da wären wir beim nächsten Vorurteil....
Beispiel Doom3: Die Stencilschatten wurden vor gar nicht so langer Zeit noch als großer Wurf gedeutet. Endlich einheitliche Beleuchtung, endlich keine prinzipiellen Unterschiede zwischen Charakteren und Levelbau mehr...
Jedes Spiel hat atm nur ein Renderverfahren. Rasterisierung. Auch U3.

Aber jetzt wo ich Doom3 gesehen habe, kann ich mir nicht vorstellen, dass das der große Wurf wird. Wie der Rechenaufwand mit mehr Polygonen explodiert, ist durch nichts auszugleichen.
Raytracing hat zur Anzahl der Polygone logarithmische Laufzeit...
Deshalb verwendet ja die Unreal3 Engine anscheinend drei verschiedene Beleuchtungssysteme, um wirklich für jeden Fall das Optimum bieten zu können.
Man kann auch mit Raytracing verschiedene Beleuchtungssystem bauen.
Ich hab mich noch nicht ausreichend mit Raytracing beschäftigt,
genau DAS ist das Problem fast aller Leute die über Raytracing herziehen.
Vielleicht sollte man sich erst mal mit etwas beschäftigen, bevor man drüber urteilt oder noch schlimmer verurteilt!
Wie sieht es z.B. mit offenem Gelände aus? Was passiert, wenn ich einen Lichtstrahl erstmal an ein zwei Kilometer entferntes Ziel senden muss, um dort festzustellen dass die leichten Schattierungen eines Blattes und der leichte Dunstkreis eines furzendes Eichhörnchens meinen Lichtwert für diesen Pixel um 0,0005% dimmen?
Erstens wäre es nicht sonderlich schlimm und zweitens gibts für sowas immer noch LOD.

Btw. ich hab hier schon oft genug was zu den üblichen Vorurteilen über Raytracing geschrieben. Die Suchfunktion hilft da weiter...

[Monger]

...

genau DAS ist das Problem fast aller Leute die über Raytracing herziehen.
Vielleicht sollte man sich erst mal mit etwas beschäftigen, bevor man drüber urteilt oder noch schlimmer verurteilt!

...

Btw. ich hab hier schon oft genug was zu den üblichen Vorurteilen über Raytracing geschrieben. Die Suchfunktion hilft da weiter...

OK, ich seh's ein. Nach etwas Sucherei hab ich eigentlich nur eins rauslesen können: bis Raytracing auf einem "normalen" PC in Echtzeit bessere Bilder als
Rasterizing produzieren kann, ist wohl noch sehr, SEHR viel Arbeit nötig.

[turbokitty2k]

Dem Raytracing gehört die Zukunkt, die Frage ist nur wann die Graka Hersteller damit anfangen.

Ich wage mal zu behaupten das ein Raytracing-Chip mit der Transistorenanzahl und dem Takt einer aktuellen Grafikkarte schon sehr leistungsfähig wäre.

Das gleiche Problem ist die x86 CPU seit 20 Jahren gibts was besseres aber keiner will es wegen Kompatibilität etc..

[Godmode]

Hat Nvidia nicht gesagt, das der nächste Chip in eine ganz andere technologische Richtung gehen wird?

[Thanatos]

Wenn diese neue Technik schon echtzeit Raytracing waäre, wäre das natürlich Genial =)

Aber das wird es wahrscheinlich nicht :usad:

[Selle]

Wie gut das Prototypen von Nvidia und ATi ja soooo billig sind. :rolleyes:

Wie meinen?? Raytracing-Prototypen von nV & ATi ? :|

[PrefoX]

öhm ihr wisst das Raytracing nur spiegelungen sind?

es heisst auch auf deutsch strahlenverfolgung, mehr ist es net...
just a simple mirror jungs :)

hat nix mit schatten engine oder sonstwas zutun.

einfach nur perfekte spiegelungen..
€: die prototypen waren nicht von nV oder ATI, und der chip war auch net wirklich teuer...

der chip für radiosity bräuchte ca. 100-300 mal soviel leistung, das ist der unterschied..

[RLZ]

öhm ihr wisst das Raytracing nur spiegelungen sind?
Ich weiss, dass du nicht weisst was Raytracing ist ;)
es heisst auch auf deutsch strahlenverfolgung, mehr ist es net...
just a simple mirror jungs :)
Damit wird aber es ganze Bild berechnet und nicht nur Spiegelungen du Scherzkeks.
hat nix mit schatten engine oder sonstwas zutun.
Ne Schattenengine? Was ist denn das?
Ach und schonmal was von Shadowrays gehört?
einfach nur perfekte spiegelungen..
Einfach nur Schwachsinn.
€: die prototypen waren nicht von nV oder ATI, und der chip war auch net wirklich teuer...
Der war vom CGUdS.
Und billig war der FPGA bestimmt nicht.
Abgesehen von den Entwicklungskosten.

der chip für radiosity bräuchte ca. 100-300 mal soviel leistung, das ist der unterschied..
GlobIllum ist nicht unbedingt Radiosity.
Radiosity hat quadratische Laufzeit.
Wird also so schnell nicht kommen.


Erstmal informieren und dann posten...

[aths]

Hat Nvidia nicht gesagt, das der nächste Chip in eine ganz andere technologische Richtung gehen wird?Kaum in Richtung Raytracing. Allerdings ließen sich Raytracing-Engine begrenzt mit SM3 umsetzen. Auf WGF-Grakas sollte es noch etwas einfacher sein.

[Coda]

öhm ihr wisst das Raytracing nur spiegelungen sind?Nein. Das war mir bisher fremd...

es heisst auch auf deutsch strahlenverfolgung, mehr ist es net...
just a simple mirror jungsDu weißt schon das in echt Licht auch Strahlen sind (zumindest kann man damit die meisten Effekte erklären) ? Muss man mehr sagen? :rolleyes:

hat nix mit schatten engine oder sonstwas zutun.Hat es sehrwohl. Mit Raytracing ist das sogar extrem simpel zu machen. Weit simpler als mit jedem Rasterizer.

einfach nur perfekte spiegelungen..Nein.

€: die prototypen waren nicht von nV oder ATI, und der chip war auch net wirklich teuer...Ein Chip bis zum Tapeout zu bringen ist immer teuer.

der chip für radiosity bräuchte ca. 100-300 mal soviel leistung, das ist der unterschied..Radiosity ist ursprünglich ein reines Rasterizing Verfahren. Man kann aber zur Lösung auch Monte Carlo Raytracing verwenden.

Andererseits ist Photon Mapping weitaus besser geeignet für einen Raytracer.

[Thanatos]

Also 1 mal bash0rn reicht doch ;D

[marco42]

wenn raytracing so toll ist, wer hat hier eigentlich schon mal einen geschrieben, warum sind die meisten offline renderer wie renderman rasterizer? globale beleuchtungsmodelle wie sie raytracer nutzen bauchen nun einmal sehr viel mehr rechenpower und lassen sich viel schwerer optimieren. und man braucht sie gar nicht so oft. was vielleicht sinnvoll waere, ist ein low resolution forward raytracer, der lightmaps fuer animierte objekte on the fly berechnet(photon mapping), dass sieht sehr gut aus und kostet nicht so viel. das kann dann aber doch wieder die CPU uebernehmen, denn wie gesagt, raytracing ist sehr viel schwerer zu parallelisieren und ein flexibles design wie die CPU ist da ganz ok. da kommt dann aber wieder das schattenproblem hinein, denn low resolution photon mapping fuer die ganze scene ist dann natuerlich auch wieder overkill, ausserdem spielt da auch noch radiosity hinein. alles nicht so einfach. aber wirklich gutes licht ist fuer eine scene IMHO viel wichtiger als tolle texturen. unser auge ist da recht sensible und lokale beleuchtungsmodelle ala phong produzieren da halt nur eine grobe annaehrung.

[Coda]

wenn raytracing so toll ist, wer hat hier eigentlich schon mal einen geschrieben, warum sind die meisten offline renderer wie renderman rasterizer?Weil es derzeit noch schneller ist. Rasterizing skaliert O( n ) mit der Anzahl der Primitives, Raytracing ist dagegen O(log( n )).
D.h. sobald man die nötige Grundpower hat ist es bei einem Raytracer eigentlich völlig egal wieviel Polygone man rendern will

globale beleuchtungsmodelle wie sie raytracer nutzen bauchen nun einmal sehr viel mehr rechenpower und lassen sich viel schwerer optimieren.1. Ist Raytracing kein globales Beleuchtungsmodell.
2. Ist es ziemlich einfach zu optimieren weil man es ziemlich gut parallelisieren kann.

was vielleicht sinnvoll waere, ist ein low resolution forward raytracer, der lightmaps fuer animierte objekte on the fly berechnet(photon mapping), dass sieht sehr gut aus und kostet nicht so vielDas ist kein Photon Mapping.

raytracing ist sehr viel schwerer zu parallelisieren und ein flexibles design wie die CPU ist da ganz ok.WTF? Das skaliert bei OpenRT absolut linear mit der Anzahl der Prozessoren.

da kommt dann aber wieder das schattenproblem hinein, denn low resolution photon mapping fuer die ganze scene ist dann natuerlich auch wieder overkill, ausserdem spielt da auch noch radiosity hinein.Was hat jetzt Radiosity mit Photon Mapping zu tun? :|

Radiosity rechnet man normal auf Lightmaps, das ist aber etwas ganz anderes.

[marco42]

Weil es derzeit noch schneller ist. Rasterizing skaliert O( n ) mit der Anzahl der Primitives, Raytracing ist dagegen O(log( n )).


Da raytracing sehr stark davon abhaengt, wie tief die recursionstiefe ist und ob du distributed raytracing verwendest ich halte das, was du mit der O notation hier hin schreibst daher fuer quatsch. Du solltets in diesem fall auch mal an speicherlokalitaet denken, die bei rasterizern gegeben ist, bei raytracern nicht. raytracing haengt extrem stark von der verwendeten datenstruktur ab, es kommt bei der schnittberechnung schon darauf an, ob du nun einen octree oder bounding volumes vewendest.


D.h. sobald man die nötige Grundpower hat ist es bei einem Raytracer eigentlich völlig egal wieviel Polygone man rendern will


du hast noch nie einen raytracer geschrieben.


1. Ist Raytracing kein globales Beleuchtungsmodell.


http://en.wikipedia.org/wiki/Global_illumination

wenn es kein globales beleutungsmodell waere, dann koenntest du ja raytracing ohne zufaelligen zugriff das model implementieren. :-)


Das ist kein Photon Mapping.


AFAIK ist es forward raytracing mit caching der beleuchtung. das caching kannst du also in einer texture vornehmen. sorry, es ist lange her, dass ich mich damit beschaeftigt habe, aber IMHO verbreitest du hier halbwissen.

[Shagnar]

Interessanter Thread! =)

PURE Renderingkarte, guggst du! ;) (http://store.artvps.com/)

Ansonsten soll doch mit dem Shadermodell 4 so ziemlich alles möglich werden sofern die Rechenleistung das noch packt oder?

[marsbiker]

hm, also ich find an raytracing sehr angenehm, dass man perfekte schatten hat, ohne irgendeinen umweg zu nehmen, wie shadowvolumes, shadowmaps oder ähnliches. Das selbe bei Spieglungen etc.
Die das Q3-Raytracing läuft doch auch schon mit 20 FPS sobald man 7 (warns glaub ich) normale PCs zusammen rechnen lässt. Und das wesentlich besser aussehend als auf Rastergrafik gerendert, weil die so Effekte einfach zu implementieren sind und nicht viel Performance kosten (echte Brechung z.b.)

ich würde auch wetten, dass ein Raytracing-chip mit der Taktung und Transistoranzahl von Highendgrafikchips nicht langsam ist *g*

[Vasco]

Da raytracing sehr stark davon abhaengt, wie tief die recursionstiefe ist und ob du distributed raytracing verwendest ich halte das, was du mit der O notation hier hin schreibst daher fuer quatsch. Du solltets in diesem fall auch mal an speicherlokalitaet denken, die bei rasterizern gegeben ist, bei raytracern nicht. raytracing haengt extrem stark von der verwendeten datenstruktur ab, es kommt bei der schnittberechnung schon darauf an, ob du nun einen octree oder bounding volumes vewendest.

Die O-Notation ist zur Laufzeitangabe vollkommen korrekt.

Die Speicherlokalität bei Rasterizern betrifft nur die Buffer Objects (Vertex/Index/Texture) - keine Lokalität bzgl. der Datenstrukturen!

Die Beschleunigungsstruktur eines Raytracers ist nahezu identisch zu der eines Rasterizers: ein Szenengraph der von der CPU durchlaufen (traversed) wird. Ob das nun ein B-Tree, hierarchical Bounding-Volumes oder Octrees sind ist total egal.

Du kannst ne 3D Engine schreiben die sowohl Rastern als auch Raytracen kann (oder Conetracen, oder Beamtracen mit Radiosity oder Photon Mapping) - und den selben Szenengraph mit einen der o.g. Datenstrukturen benutzt.


wenn es kein globales beleutungsmodell waere, dann koenntest du ja raytracing ohne zufaelligen zugriff das model implementieren. :-)


Naives Raytracing benutzt ein lokales Beleuchtungssystem (Phong) als BRDF-Annäherung.
Erst mit einem global Beleuchtungssystem wie Radiosity oder Photon Mapping wird die BRDF komplett.


AFAIK ist es forward raytracing mit caching der beleuchtung. das caching kannst du also in einer texture vornehmen. sorry, es ist lange her, dass ich mich damit beschaeftigt habe, aber IMHO verbreitest du hier halbwissen.

Nur blöd wenn sich die Lichtquellen im Raum bewegen.

Kurzumes Resumée zu Rasterizern:
Schatten (Stencil Shadows): gefaked
Globales Beleuchtungsmodell (precalculated Lightmaps): gefaked
Lokales Beleuchtungsmodell (vereinfachtes Phong): gefaked
Oberflächendarstellung (approximiert durch endliche Polygone): gefaked


Cheers,
Vasco

[Vasco]

wenn raytracing so toll ist, wer hat hier eigentlich schon mal einen geschrieben

/me

warum sind die meisten offline renderer wie renderman rasterizer?

???

globale beleuchtungsmodelle wie sie raytracer nutzen bauchen nun einmal sehr viel mehr rechenpower und lassen sich viel schwerer optimieren.

Dafür lassen sie sich im Gegensatz zu Rasterizern wunderbar parallelisieren.

was vielleicht sinnvoll waere, ist ein low resolution forward raytracer, der lightmaps fuer animierte objekte on the fly berechnet(photon mapping), dass sieht sehr gut aus und kostet nicht so viel.

Klingt nach Pfusch. Warum nicht gleich einen vollwertigen RT in HW? :>

das kann dann aber doch wieder die CPU uebernehmen, denn wie gesagt, raytracing ist sehr viel schwerer zu parallelisieren

LOL, du kannst es ganz einfach parallelisieren. Bild in Kacheln einteilen und von entsprechend vielen dedizierten einheiten berechnen lassen.

und ein flexibles design wie die CPU ist da ganz ok.

Ganz im Gegenteil. Eher limitiert..

da kommt dann aber wieder das schattenproblem hinein, denn low resolution photon mapping fuer die ganze scene ist dann natuerlich auch wieder overkill

Tjo warum nicht gleich richtiges Photon Mapping?

ausserdem spielt da auch noch radiosity hinein.[/quote
Was hat Radiosity jetzt damit zu tun?

Radiosity != Photon Mapping != Naive Raytracing

[quote]alles nicht so einfach.

korrekt.

aber wirklich gutes licht ist fuer eine scene IMHO viel wichtiger als tolle texturen. unser auge ist da recht sensible und lokale beleuchtungsmodelle ala phong produzieren da halt nur eine grobe annaehrung.

Genau. Daher kombiniert man in einer BRDF üblicherweise lokale (Lambert/Phong/Blinn/CookTorrance/TrowbridgeReitz) mit globalen wie Radiosity oder Photon Mapping, welche auch den Energieaustausch der Objekte untereinander in einer Szene berücksichtigen.

Raytracing ist dann nur eine Methode die Informationen auf den Bildschirm zu bekommen.


Cheers,
Vasco

[Coda]

du hast noch nie einen raytracer geschrieben.Habe ich :)

Die O Notation stimmt sehr wohl, wenn man sich's genau überlegt ist es auch klar. Du brauchst halt irgend eine Szene Subdivison, reines brute-force Raytracing ist natürlich auch O( n ).

Schau dir mal das an ftp://graphics.cs.uni-sb.de/oasen/GI04-MWZC-RayTracing.avi
2 Mio Polygone ohne LOD. Da würde jeder Rasterizer einbrechen.

Oder auch sehr aktuell: http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=65091
Da wäre ein Rasterizer nicht mehr viel schneller bei der Polygonmenge.

wenn es kein globales beleutungsmodell waere, dann koenntest du ja raytracing ohne zufaelligen zugriff das model implementieren. :-)
Nein. Raytracing ist KEIN globales Beleuchtungsmodell.
Globales Beleuchtungsmodell würde indirekte beleuchtung mit in Betracht ziehen, das ist aber sicherlich nicht der Fall bei normalen Tracern.

Warum attestierst du mir Halbwissen wenn du selber 3 krasse Fehler in deinen Aussagen hast? (Laufzeit, Parallelisierbarkeit und GI)

[marsbiker]

Klingt nach Pfusch. Warum nicht gleich einen vollwertigen RT in HW? :>

ein Kommilitone von mir schreibt grad ein programm das kritische stellen einer mit Rastergrafik gerenderter Szene Raytraced - in dem Fall Stellen an denen die Shadowmap mist baut - hat den vorteil sehr schnell zu sein und schaut trotzdem fast wie raytracing aus (beim schatten zumindest)

und ich hab auch schon nen kleinen raytracer programmiert...

[Vasco]

ein Kommilitone von mir schreibt grad ein programm das kritische stellen einer mit Rastergrafik gerenderter Szene Raytraced - in dem Fall Stellen an denen die Shadowmap mist baut - hat den vorteil sehr schnell zu sein und schaut trotzdem fast wie raytracing aus (beim schatten zumindest)

Ich hab mal im Rahmen einer Seminararbeit (http://www-public.tu-bs.de:8080/~y0010065/Seminar.pdf) über Interaktives Raytracing auf PCs verschiedene Ansätze zusammentragen müssen. Soweit ich mich erinnere schimpft sich des "Perceptually Guided Perspective Splatting".

Damals war auch der Coder von Realstorm (http://www.realstorm.com/) am Insitut und hatte nen Vortrag über sein System gehalten. Schade dass ich mir die Folien net besorgt hab.


Cheers,
Vasco

[RLZ]

Zum Thema Polygonzahl kann ich da nur sagen, dass sie bei einem ordentlichen Raytracer wirklich fast egal sind, solange die Daten alle in den Speicher passen oder sich schnell genug nachladen lassen. Aber es gibt ja noch notfalls einfaches LOD und 64 Bit Rechner mit genug Speicher.
Ich finds immer noch lustig wieviel Falschwissen es in der Richtung gibt. Da frag ich mich zB wo das Gerücht über Renderman herkommt? Jeder der schonmal nen Rendermanshader geschrieben hat, sollte eigentlich wissen, dass es kein reiner Rasterizer ist...
Wo marco aber begrenzt recht ist die Speicherlokalität.
Wenn viele einzelne Strahlen in der Entfernung immer nur alleine ein komplexes Objekt treffen ist das nicht unbedingt erfreulich. Allerdings muss das Objekt aufm Bildschirm die Grösse von wenigen Pixel haben und kann dann eh problemlos gegen ein einfacheres ersetzt werden.

2 Mio Polygone ohne LOD. Da würde jeder Raytracer einbrechen.
Du meinst wohl Rasterizer?
2 Millionen sind ausserdem noch schwer untertrieben ;)

[Vasco]

Schau dir mal das an ftp://graphics.cs.uni-sb.de/oasen/GI04-MWZC-RayTracing.avi
2 Mio Polygone ohne LOD. Da würde jeder Raytracer einbrechen.

Oder auch sehr aktuell: http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=65091
Da wäre ein Rasterizer nicht mehr viel schneller bei der Polygonmenge.

Na nen Raytracer sollte im optimalen Falle auch keine Polygone darstellen.
Sondern direkt High-Order Surfaces (Bézier-/NURBS-Patches), Subdivision Surfaces oder anderen beispielsweise mathematisch einfach beschreibbaren Körpern wie Polyhedra oder Quadriken direkt (ohne Tesselierung in Polygone/Dreiecke) verarbeiten.

Die Darstellung von Polygonen ist eine reine Notwendigkeit des Rasterizers (und zugleich seine größte Schwäche).
Er hat keine Informationen mehr über das eigentlich darzustellende Objekt.
Er sieht nur noch einzelne nahezu unabhängige Triangles/Quads.


Cheers,
Vasco

[RLZ]

Na nen Raytracer sollte im optimalen Falle auch keine Polygone darstellen.
Sondern direkt High-Order Surfaces (Bézier-/NURBS-Patches), Subdivision Surfaces oder anderen beispielsweise mathematisch einfach beschreibbaren Körpern wie Polyhedra oder Quadriken direkt (ohne Tesselierung in Polygone/Dreiecke) verarbeiten.
Für frei modellierte Modelle sind Polygone meistens immer noch am Besten geeignet. Ausserdem ist die Intersection mit nem Dreieck immer noch am schnellsten.
Sinnvoll wäre ein Mischmodus. Da muss man aber erst jemanden finden, der einem die Modelle bauen kann....

[marsbiker]

Ausserdem ist die Intersection mit nem Dreieck immer noch am schnellsten.
wie kommst du darauf?

[Vasco]

Für frei modellierte Modelle sind Polygone meistens immer noch am Besten geeignet.

Glaub mir, du möchtest keine Polygonnetze per Hand editieren.
Und für den Raytracer sind genau solche Netze der Overkill.
Der Schnittpunkt mit EINER Fläche ist immer noch einfacher als der Schnittpunkt mit EINEM Dreieck aus einem Polygonnetz (alle Dreiecke müssen getestet werden).


Cheers,
xyzw

[RLZ]

wie kommst du darauf?
Was ist denn schneller als ne Dreiecksintersection über baryzentrische Koordinaten?

[Vasco]

Was ist denn schneller als ne Dreiecksintersection über baryzentrische Koordinaten?

Weil du hunderte bis Tausende Dreiecke auf den Schnitt testen musst.
Nur um am Ende festzustellen, daß Du nix getroffen hast.

Bounding-Volumes wie AABBs oder Polytopes beschreiben die konvexe Hülle (eines beliebig großen Polygonnetzes) nur ungefähr.


Cheers,
Vasco

[RLZ]

Der Schnittpunkt mit EINER Fläche ist immer noch einfacher als der Schnittpunkt mit EINEM Dreieck aus einem Polygonnetz (alle Dreiecke müssen getestet werden).
Dafür gibts ja Beschleunigerstrukturen, dass man nicht alle testen muss.
Bei Objekten die sich einfach über Freiformflächen realisieren lassen sind sie schneller. Bei Objekten bei denen das nicht gut geht langsamer.
Ausserdem arbeiten Designer nunmal meistens am liebsten mit Dreiecken.
Bounding-Volumes wie AABBs oder Polytopes beschreiben die konvexe Hülle (eines beliebig großen Polygonnetzes) nur ungefähr.
Ein ordentlich optimierter kd-tree sollte nicht allzuviel Rechenleistung mit vergeuden nen Strahl zu testen der nix trifft. Nur in Grenzfällen wird das langsam.

[marsbiker]

Was ist denn schneller als ne Dreiecksintersection über baryzentrische Koordinaten?
eine fläche die über EINE Gleichung beschrieben wird? und auch nur einmal getestet werden muss...

[RLZ]

eine fläche die über EINE Gleichung beschrieben wird? und auch nur einmal getestet werden muss...
Ok Grenzen wir das ein.
Etwas was schneller ist und womit man vernünftig mit modellieren kann.
Der Rest ob Kugeln oder sonstwas sind theoretisch ja schön, aber in der Praxis fast nie interessant.

[Coda]

Nene die Polygone müssen bleiben, andere Primitives eigenen sich einfach nicht so gut beim Modelling.
Außer man benützt NURBS etc. Aber da ist die Intersection dann sicher teurer.

Weil du hunderte bis Tausende Dreiecke auf den Schnitt testen musst.
Nur um am Ende festzustellen, daß Du nix getroffen hast.
Dafür gibt's ja den Scenetree (egal ob BSP, Occ, KD). Sonst hätte man auch keine logarithmische Laufzeit.

[PrefoX]

also wer raytracing ausserhalb von spiegelungen benutzt verschwendet einfach nur power.

daher wird überall nur raytracing benutzt wenn man spiegelungen benutzt.
klar kann man es für alles verwenden, aber das ist schwachsinn.

[RLZ]

also wer raytracing ausserhalb von spiegelungen benutzt verschwendet einfach nur power.

daher wird überall nur raytracing benutzt wenn man spiegelungen benutzt.
klar kann man es für alles verwenden, aber das ist schwachsinn.
Begründung bitte....

[Vasco]

Nene die Polygone müssen bleiben, andere Primitives eigenen sich einfach nicht so gut beim Modelling.
Außer man benützt NURBS etc. Aber da ist die Intersection dann sicher teurer.
Dafür gibt's ja den Scenetree (egal ob BSP, Occ, KD). Sonst hätte man auch keine logarithmische Laufzeit.

Ich rede nicht von der Modellierung einer Szene mit vielen Objekten.
Sondern die Modellierung eines einzigen Objekts und dessen Polygonnetzes.

Willst Du da auch Beschleunigungsstrukturen einsetzen?
Was ist mit dynamisch veränderbaren Objekten wie Soft-Objects z.B. Haut oder Marmelade?
Willst Du Deformationen in einem Polygonnetz durchführen statt auf den High-Order-Patches die es beschreiben?

Kann mir nicht vorstellen, daß jemand mitm 3D Modeller keine Freiformflächen benutzt sondern reine Polygonnetze.

Die generiert man daraus am Ende, wenn man die mit einer beliebigen 3D-Rasterizer Engine darstellen will.


Cheers,
Vasco

[Vasco]

also wer raytracing ausserhalb von spiegelungen benutzt verschwendet einfach nur power.

Wenn ich die Power habe, interessiert mich das eigentlich nicht.

daher wird überall nur raytracing benutzt wenn man spiegelungen benutzt.

Ach, Reflektieren Objekte nicht in der realen Welt?
Was ist mit Refraktionen? Gibt es in Deiner Welt keine Transluzenz? Schon mal ein großes und schön rotes Objekt neben eine weisse Wand gehalten?

Mit 3D-Grafik will ich die Realität möglichst genau abbilden, und nicht wie momentan mit Rasterizern nur geschummelt an allen Ecken und Enden.

klar kann man es für alles verwenden, aber das ist schwachsinn.

Dein Horizont scheint arg begrenzt :biggrin:


Cheers,
Vasco

[RLZ]

Ich rede nicht von der Modellierung einer Szene mit vielen Objekten.
Sondern die Modellierung eines einzigen Objekts und dessen Polygonnetzes.

Willst Du da auch Beschleunigungsstrukturen einsetzen?
Mehrstufige Beschleunigerstrukturen.
Du hast ne Toplevel-Beschleunigerstruktur in dem die Boundingboxes drin sind und für jedes Objekt nochmal nen Beschleunigerstruktur. Wenn ein Strahl die Boundingbox trifft wird der Strahl ins Koordinatensystem des Objekts transformiert und traversiert dort weiter.

Was ist mit dynamisch veränderbaren Objekten wie Soft-Objects z.B. Haut oder Marmelade?
Willst Du Deformationen in einem Polygonnetz durchführen statt auf den High-Order-Patches die es beschreiben?
Das ist ein Problem.
Da wird momentan aber auch dran gearbeitet. Afaik macht die Uni Bonn da was.
Aber wieviel Prozent der Geometrie einer Szene sind statisch und wieviel dynamisch?

Kann mir nicht vorstellen, daß jemand mitm 3D Modeller keine Freiformflächen benutzt sondern reine Polygonnetze.
Viele machen von Anfang an Boxmodelling. Andere nehmen wirklich Freiformflächen und triangulieren sie bevor sie die Details hinzufügen.
Komplexe Objekte die nicht trianguliert findet man sogut wie garnicht.

[Coda]

Kann mir nicht vorstellen, daß jemand mitm 3D Modeller keine Freiformflächen benutzt sondern reine Polygonnetze.
Das machen mehr als du denkst. Vor allem bei technischen Dingen.

Aber ich weiß nicht worauf du hinauswillst. Die Freiformflächen-Intersections sind teurer als die für das entsprechende Polygonnetz.

[Matti]

Für praktisch anwendbare Raytracer sollte es außer Dreiecken auf jeden Fall noch Kugeln als Primitiven geben. Denn die Schnittpunkt-Berechnung mit einer Kugel geht schneller als mit einem Dreieck, und außerdem läßt sich so die Modellierung vereinfachen. Daß Freiformflächen einen Performance-Gewinn bringen, kann ich mir aber nicht vorstellen.

An dieser Stelle möchte ich noch ein Vorurteil beseitigen:
Es ist korrekt, daß Raytracer (mit einem Bounding-Volumes-Tree) in Abhängigkeit von der Anzahl der Polygone (bzw Primitiven) einen logarithmischen Aufwand haben. Es ist jedoch falsch, daß Rasterizer immer einen linearen Aufwand haben! Verwendet man Occlusion-Culling, erreicht man auch hier logarithmischen Aufwand.

Langfristig wird man um Ray-Tracing nicht herum kommen, denn viele Effekte sind nur mit Ray-Tracing korrekt darstellbar. Zum Beispiel Reflexionen können zwar mit Environment-Mapping ziemlich realistisch dargestellt werden, aber in bestimmten Fällen werden Reflexionen an gebogenen Objekten mit diesem Verfahren falsch dargestellt. Dann braucht man Ray-Tracing.

Prinzipiell ist Ray-Tracing schon mit heutigen DX9-Grakas machbar. Jedoch gibt es afaik 2 Probleme:
1. die noch zu geringe Shader-Leistung. Bis jetzt sind nur einfache Szenen in geringer Auflösung möglich.
2. die Geometrie-Daten müßte man in Texturen unterbringen, was ziemlich ineffektiv ist. Afaik gibt es keine Möglichkeit, mit 2.0-Shadern beliebig große Arrays zu definieren, in denen man z.B. eine komplette Doom3-Map unterbringen könnte. Derzeit ist man auf wenige tausend Elemente beschränkt.

[zompel]

Ich habe noch mal was bezüglich Raytracing in Games ausgegraben.
Ich denke es könnte den einen oder anderen vielleicht noch interessieren. :smile:
Link 1 (http://www.gamestar.de/magazin/reports/18431/index.html) (Unreal 3, Quake 3 Raytraced & Co)
Link 2 (http://www.gamestar.de/magazin/specials/hardware/17734/) (englischsprachige Diskussion zwischen dem Chef-Wissentschaftler von Nvidia, David Kirk, und dem renommierten Informatik-Professer Philipp Slusallek von der Uni Saarbrücken)

[Gast]

Um mal auf die Eingangsfrage zurück zu kommen hier meine Gedanke die ich in dieser Richtung so hatte. Und zwar ausgehend von folgender Meldung:
http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/44828&words=Xeon%20Raytracing

32 Xeons à 3,2 Ghz ermöglichen also Echtzeit Ractracing.
Nach Moore's Law verdoppelt sich ca. alle 18 Monate die Schaltungsdichte, was häufig als doppelte Leistung alle 2 Jahre interpretiert wird.

Daraus ergibt sich das wir in 10 Jahren ungefähr die Rechenleistung des oben erwähnten Clusters im Desktop haben (egal ob das jetzt single-, dual- oder sonstige Cores sind)
Das ganze ist sicherlich etwas ungenau da ein Cluster nie mit 100% skaliert und ich meine Rechnung ohne "spezial Chips" wie GPUs gemacht habe. Andererseits lässt sich Raytracing relativ gut auf mehrere CPUs verteilen.

Ich frag mich eher ob es überhaupt noch besondere GraKas geben muss wenn eine handelsübliche CPU solche Leistung bringt. Oder ob wir dann nur noch dumme Pixelzeichner mit Framebuffer haben in die die Daten geschoben werden.

So und jetzt viel Spaß bei einer kontroversen Diskussion :-)



Gruß

Rechner-Tester

[Coda]

Für praktisch anwendbare Raytracer sollte es außer Dreiecken auf jeden Fall noch Kugeln als Primitiven geben. Denn die Schnittpunkt-Berechnung mit einer Kugel geht schneller als mit einem Dreieck, und außerdem läßt sich so die Modellierung vereinfachen. Daß Freiformflächen einen Performance-Gewinn bringen, kann ich mir aber nicht vorstellen.
Öhm, wo hast du das letzte mal in einem Spiel eine perfekte Kugel gesehen?
Das lohnt sich keinen deut dafür Transistoren zu verschwenden.

Ich frag mich eher ob es überhaupt noch besondere GraKas geben muss wenn eine handelsübliche CPU solche Leistung bringt.Dedizierte Hardware ist immer schneller, in 10 Jahren wird man für die CPUs schon wieder andere Verwendungen haben.
Außerdem ist die gezeigte Grafik ja wohl noch nicht wirklich das Maß aller Dinge. Vor allem fehlt noch GI.

[RLZ]

Öhm, wo hast du das letzte mal in einem Spiel eine perfekte Kugel gesehen?
Das lohnt sich keinen deut dafür Transistoren zu verschwenden.
Ich würde eher mit rechnen, dass Karten einen programmierbaren Intersector haben werden. Dass sie getrennte Einheiten für Intersection und Shading haben ist unwahrscheinlich, weil man die Aufteilung nie richtig wählen kann.
Insofern könnte man Objekten einen eigenen Intersector zuweisen, wie heute einen Vertexshader.

Es ist korrekt, daß Raytracer (mit einem Bounding-Volumes-Tree) in Abhängigkeit von der Anzahl der Polygone (bzw Primitiven) einen logarithmischen Aufwand haben. Es ist jedoch falsch, daß Rasterizer immer einen linearen Aufwand haben! Verwendet man Occlusion-Culling, erreicht man auch hier logarithmischen Aufwand.
Nur ist Occlusion-Culling in vielen Fällen schwer machbar und kostet wenn mans denn einbaut oft genausoviel Leistung wie es bringt.
Raytracing hat halt kostenloses pixelgenaues Occlusion Culling und es werden nie mehr Sachen geshadet als wirklich benötigt werden.


Aber im Endeffekt kann ich mir nicht vorstellen, dass ein Programmierer sich dagegen wehrt. Ich merk ja den Unterschied zwischen der Programmierung bei Oasen und meiner OpenGL-Engine.
Auch die Spieleentwickler mit denen ich bisher geredet hab, waren nach ner Präsentation eigentlich alle begeistert.
Die Sache liegt imo eigentlich nur noch bei den Hardwareherstellern, die nicht mitziehen wollen.

[marco42]

Habe ich :)
Nein. Raytracing ist KEIN globales Beleuchtungsmodell.
Globales Beleuchtungsmodell würde indirekte beleuchtung mit in Betracht ziehen, das ist aber sicherlich nicht der Fall bei normalen Tracern.


ok, du meinst backward raytracing, sind spiegelungen keine indirekte beleuchtung?

[marco42]

Ich finds immer noch lustig wieviel Falschwissen es in der Richtung gibt. Da frag ich mich zB wo das Gerücht über Renderman herkommt? Jeder der schonmal nen Rendermanshader geschrieben hat, sollte eigentlich wissen, dass es kein reiner Rasterizer ist...


wie, unterstuetzen sie mittlerweile die trace anweisung? damals ging das nur mit dem BMRT.

bei speicherlokalitaet bezog ich mich vor allem auf die caches, und da sind moderne prozessoren halt sehr empfindlich. bei raytracern, hast du ja bei den strahlenberechnunge immer bedingte anweisungen, wie bei spiegelungen und schattenberechnungen, und das wirkt sich nicht gerade positiv auf den cache aus. ausserdem sind bedingte anweisungen anscheinend nicht so leicht in hardware zu implementieren ohne performanceverlust. ausserdem musst du um das aliasproblem beim raytracing zu loesen zu distributed raytracing greifen und das ist auch nicht so billig. ich bezweifel nicht, das du einen fall konstruieren kannst, wo raytracing besser ist. ich habe in diesere diskussion einfach nur gefuehl das keien argumente, sondern nur behauptungen ausgetauscht werden. zB wurde ueberhaupt noch nicht auf das problem der harten schatten in raytracing eingegangen, du musst um das zu loesen ja wieder sehr viel mehr strahlen in die szene schiessen und das kostet. stelle dir mal vor, da ist ein baum und der wirft schatten, dass kann ganz schoen teuer unter raytracing werden, weil du jedesmal sehr tief in die szenenstruktur gehen musst.

[Vasco]

ich habe in diesere diskussion einfach nur gefuehl das keien argumente, sondern nur behauptungen ausgetauscht werden. zB wurde ueberhaupt noch nicht auf das problem der harten schatten in raytracing eingegangen, du musst um das zu loesen ja wieder sehr viel mehr strahlen in die szene schiessen und das kostet. stelle dir mal vor, da ist ein baum und der wirft schatten, dass kann ganz schoen teuer unter raytracing werden, weil du jedesmal sehr tief in die szenenstruktur gehen musst.

Für weiche Schatten kombiniert man nen naiven Raytracer (lokales Beleuchtungsmodell) mit Radiosity oder Photon Mapping für (Global Illumination).

Nen purer Raytracer wäre idR recht langweilig.


Cheers,
Vasco

[Matti]

Öhm, wo hast du das letzte mal in einem Spiel eine perfekte Kugel gesehen?
Das lohnt sich keinen deut dafür Transistoren zu verschwenden.


Klar findet man in heutigen Spielen kaum alleinstehende Kugeln, aber manche komplexen Objekte enthalten Kugeln. Und selbst wenn es keine Kugeln geben würde: bei Ray-Tracing sind Kugeln als Bounding Volume viel effektiver als AABBs. :)

[Demirug]

Aber im Endeffekt kann ich mir nicht vorstellen, dass ein Programmierer sich dagegen wehrt. Ich merk ja den Unterschied zwischen der Programmierung bei Oasen und meiner OpenGL-Engine.
Auch die Spieleentwickler mit denen ich bisher geredet hab, waren nach ner Präsentation eigentlich alle begeistert.
Die Sache liegt imo eigentlich nur noch bei den Hardwareherstellern, die nicht mitziehen wollen.

Programmierer leiden fast alle unter Technoholism und sind somit nicht unbedingt die beste Gruppe um als Massstab herzuhalten.

Ich kenne die entsprechenden Presentation nicht und kann daher nicht sagen in wie weit sie mich überzeugen würde. Aber die Kritik an der Öffentlichkeitsarbeit der Gruppe will ich mir hier sparen da ich die Gründe für die Verschwiegenheit wenn es um Details geht nicht kenne.

Wie schon gesagt ist es nicht schwer die unter Technoholism leidenen Entwickler zu überzeugen. Nur haben die in dieser Richtung keine Entscheidungsverfügung. Darüber ob man eine neue Hardwaregruppe unterstützt entscheiden immer noch die Leute mit dem Geld. Im Grossteil aller Fälle also die Publisher.

Und genau hier ist der Knackpunkt. Um eine Unterstützung für die verbreitete 3D-Technik kommt man nicht herum. Warum also noch etwas zusätzliches Unterstützen das noch gar nicht verbreitet ist?

Ich kenne die für vorgesehen API nicht und kann daher nicht abschätzen wie gross die notwendigen Änderungen an Software und Content sind. Aber jeder Cent der dabei anfällt ist ein Stein in der Mauer die "NEIN" schreit. Von der technische Seite sehe ich die Notwendigkeit für Änderungen ein von der kaufmanischen allerdings nicht. Das war unter anderen auch einer der primären Gründen warum nVidia damals mit dem NV1 heftig auf die Schnauze gefallen ist und 3dfx erst mal das grösste Stück des Kuchens holen konnte.

Die Hardwarehersteller bauen das was der Markt verlangt wobei sie natürlich im eigenen Intresse versuchen das Verlangen des Marktes zu steuern. Kein Hersteller der überleben will wird sich jedoch gegen einen unaufhaltsamen Trend stemmen. Derzeit ist ein Trend in Richtung Raytracing aber nicht mal mit gutem Willen zu erkennen.

IMHO muss daher Raytracinghardware zuerst einen Wirtschaftlichkeitstest bestehen der vorallem zeigt das sie mit "Alt"-APIs wie OpenGL und D3D zurecht kommt und dabei ein gutes Transitoren zu Leistung Verhältniss hat. Nur so wäre überhaupt das erreichen einer kritischen Masse möglich.

[marco42]

Nur ist Occlusion-Culling in vielen Fällen schwer machbar und kostet wenn mans denn einbaut oft genausoviel Leistung wie es bringt.
Raytracing hat halt kostenloses pixelgenaues Occlusion Culling und es werden nie mehr Sachen geshadet als wirklich benötigt werden.


Dafuer hast du eine ganze menge schnittstellenberechnungen. ok, vielleicht vergleichen wir die jetzt mal etwas detailiierter:

Bei einem rasterizer kann erstmal alles weggeschmissen werden, was aich ausserhalb er kamera befindet. mit hilfe von den entsprechenden bounding volumes wie k-DOPs ist das auch nicht so teuer. laeuft auf der CPU. bei raytracing geht das nicht, da es ja bei spiegelungen und schatten die komplette szene in betracht ziehen muss. dafuer braucht man bei rasterizer dort multipass algorithmen. mit hilfe von anderen high level occulusion calling alogorithmen, wie portal calling senkst du das noch weiter. auch da hast du bei raytracern deine probleme auf grund der globalen strukturen. aber dass findet dort sowieso spaeter statt und spaeter ist meistens teuerer. da es dort pro strahl geschieht und hier nur einmal pro pass. es wird also bei rasterizern mit nichten immer das ganze modell berechnet, ganz im gegenteil, es wird viel frueher getestet. es waere also eher O(1).

bei rasterizern wird im allgemeinen ein die tarnsformation on the fly durchgefuehrt, bei multipass heisst das, dass es fuer jeden pass geschieht. transformation ist aber nicht so teuer, also ist es nicht so schlimm. beim raytracing kommt es darauf an, wie statisch die szene ist. wir haben damals die ganze scene komplett transformiert und dann erst getraced, aber das kommt halt darauf an, wie dynamisch die szene ist und wie tief die recursion etc..

was hier teurer ist, ist die frage. muesste man ausprobieren. jetzt kommt das imho entscheidene. beim raytracer musst du jetzt straheln hineinschicken, und damit es gut aussieht nimmst du distributed raytracing und das kostet. nicht so sehr das shading, aber die schnittberechnungen. aber dass kommt wieder auf das modell an. beim rasterizer hast du jetzt das rastern, dass geht recht gut in hardware und dann das shading und das kostet. du musst also versuchen moeglichst wenig zu shaden. dass kannst du mit high level algorithmen verhindern. fuer schatten brauchst du allerdings multi passes und du brauchst auch mehr lichter auf grund der lokalen beleuchtung. die lichter kannst bei statischer geometry natuerlich vorrendern. beim raytracer haengt jetzt wirklich alles von den schnittberechnungen, recursionstiefe, anzahl er strahlen ab. ehrlich gesagt wird mir das hier zu aufwendig, aber ich wuerde einfach mal gern detailierte argumente sehen(mit moeglichen zitaten) und nicht nur behauptungen. also, ich glaube nicht, dass ein reiner raytracer die mittlere zukunft ist. ich setze eher auf hybridrenderer. das ganze erinnert mich so ein bisschen an den streit von statisch getypten sprachen gegen dynamische. na klar programmiere ich schneller in python und ich nehmr es auch fuer die meisten meiner sachen, aber C++ ist halt doch noch etwas schneller was die laufzeit angeht. raytracing ist einfacher, aber ich glaube nicht daran, dass wir im moment schon so viel rechenzeit ueber haben, dass es sich durchsetzen wird. in einer der letzten siggarph proceedings wurde zB noch beschrieben, wie ein low level raytracer zur lichtberechnung eingesetzt wurde, aber des rest noch ein rasterizer war. normaler weise ist der offline bereich dem echtzeit bereich etwas voraus.

[marco42]

Für weiche Schatten kombiniert man nen naiven Raytracer (lokales Beleuchtungsmodell) mit Radiosity oder Photon Mapping für (Global Illumination).

Nen purer Raytracer wäre idR recht langweilig.


Und das ich echtzeit oder werfen animaierte objecte keine schatten?

[RLZ]

bei speicherlokalitaet bezog ich mich vor allem auf die caches, und da sind moderne prozessoren halt sehr empfindlich.
Prefetchen bei Software oder bei Hardware die Latenzen komplett verbergen wie bei Saarcor hilft.
ausserdem musst du um das aliasproblem beim raytracing zu loesen zu distributed raytracing greifen und das ist auch nicht so billig.
distributed Raytracing nimmt man immer dann, wenn man zu faul ist sich mehr Gedanken zu machen.
Antialising kann man wunderbar, einfach und schnell adaptiv lösen.
zB wurde ueberhaupt noch nicht auf das problem der harten schatten in raytracing eingegangen, du musst um das zu loesen ja wieder sehr viel mehr strahlen in die szene schiessen und das kostet.
Das kann man adaptiv machen oder halt mit nem GlobIllum Ansatz.
Falls man zu faul war Antialiasing adaptiv zu machen, kann man immer noch auf Interleaved Sampling zurückgreifen.

stelle dir mal vor, da ist ein baum und der wirft schatten, dass kann ganz schoen teuer unter raytracing werden, weil du jedesmal sehr tief in die szenenstruktur gehen musst.
Mach mal nen Baum mit Stencilschatten.
Bin mal gespannt, ob das billig wird ;)
Das teuerste beim Raytracer an der Sache wären/sind die Alphatexturen im Baum.
Wenn man die Alphattexturen schon im Intersector prüft, wäre es wohl schon wesentlich schneller.
Man könnte auch die Blätter auf Kosten von mehr Polygonen einfach besser approximieren.
Ne Intersection zu finden ist bei ner ordentlichen Beschleunigerstruktur nie teuer.

[marco42]

distributed Raytracing nimmt man immer dann, wenn man zu faul ist sich mehr Gedanken zu machen.
Antialising kann man wunderbar, einfach und schnell adaptiv lösen.


ok, und wie?

[Demirug]

marco42, ich gehe da sogar noch einen Schritt weiter und behaupte das wird was das Objekt Culling angeht bei den Rasterizeren noch sehr weit am Anfang stehen. Bisher hat es sich nur wenig gelohnt aber je häufiger es zu Dingen wie Texturezugriffen im Vertexshaderbereich kommt desto interesanter wird das ganze.

GPUs werden daher die Fähigkeit bekommen schnelle Schichtbarkeitsprüfungen für AABB (oder ähnliches) durchzuführen und aufgrund der Ergebnisse komplette Rendersequenzen einfach zu überspringen.

[marco42]

marco42, ich gehe da sogar noch einen Schritt weiter und behaupte das wird was das Objekt Culling angeht bei den Rasterizeren noch sehr weit am Anfang stehen. Bisher hat es sich nur wenig gelohnt aber je häufiger es zu Dingen wie Texturezugriffen im Vertexshaderbereich kommt desto interesanter wird das ganze.

GPUs werden daher die Fähigkeit bekommen schnelle Schichtbarkeitsprüfungen für AABB (oder ähnliches) durchzuführen und aufgrund der Ergebnisse komplette Rendersequenzen einfach zu überspringen.

k-DOPs(18-DOP) in hardware waere wirklich interessant, sind ja eine verallgemeinerung von AABBs(ein AABB ist ein 6-DOP). du meinst also, dass man ein bound volume an ein object heftet und dann sagt, zeiche es nur, wenn es nicht verdeckt ist? findet das dann nicht immer noch auf pixel ebene statt, dann wuerde sich ja auch ein sehr viel hierachischer zbuffer lohnen oder sehe ich das jetzt falsch.

[RLZ]

ok, und wie?
Man lässt hinterher ne Erkennung drüberlaufen, welche Stellen nachgefiltert werden müssen. Dort schiesst man dann einfach zu ein paar zusätzliche Strahlen.
Irgendwann hatte ich hier im Forum sogar mal Bilder dazu gepostet...

[Coda]

ok, du meinst backward raytracing, sind spiegelungen keine indirekte beleuchtung?
Das meine ich nicht. Ich meine diffuses Licht als indirekte Beleuchtung.
GI bedeutet das Licht von einem Raum auch noch indirekte Räume daneben erhellen kann obwohl man von dort die Lichtquelle nicht sieht.
Und das kann Raytracing normal nicht ohne Photon Mapping oder ähnliches.

Und wegen der Laufzeit. Sehr viele Papers die ich gelesen habe bestätigen den Laufzeitunterschied zwischen Rasterizer und Raytracer.
Raytracing wird bei sehr hohen Polygonzahlen wirklich deutlich effizienter als Rasterizing.

Occlusion Culling könnte man bei Raytracing genauso anwenden wenn man die Spiegelungen weglässt und dann wäre die Laufzeit immer noch O(log( n )) gegen O( n ).

Nochmal was schönes:
http://www.intrace.com/gallery/boeing777.php

[Thanatos]

Ich habe noch mal was bezüglich Raytracing in Games ausgegraben.
Ich denke es könnte den einen oder anderen vielleicht noch interessieren. :smile:
Link 1 (http://www.gamestar.de/magazin/reports/18431/index.html) (Unreal 3, Quake 3 Raytraced & Co)
Link 2 (http://www.gamestar.de/magazin/specials/hardware/17734/) (englischsprachige Diskussion zwischen dem Chef-Wissentschaftler von Nvidia, David Kirk, und dem renommierten Informatik-Professer Philipp Slusallek von der Uni Saarbrücken)


Hmmm also irgendwie wirft da die lame Star was ganz schön durcheinander, erst reden sie das raytracing mit Quake 3 möglich ist, aber dann bringen sie screenshots von UT2003/4?

Später stimmts ja wieder aber am Anfang?:ugly:


http://www.gamestar.de//graphics/bild_db/10200/10219/PopUp_800x600.idg

Aber am lustigsten find ich ja die Bilder, hmmmm 2009, so ne gute Grafik :eek:.

Sieht für mich eher nach der grafik von UT2004 aus ;D

[Gast]

coda, kannst du mal die paper angeben, mich wuerde das interessieren.

[Demirug]

k-DOPs(18-DOP) in hardware waere wirklich interessant, sind ja eine verallgemeinerung von AABBs(ein AABB ist ein 6-DOP). du meinst also, dass man ein bound volume an ein object heftet und dann sagt, zeiche es nur, wenn es nicht verdeckt ist? findet das dann nicht immer noch auf pixel ebene statt, dann wuerde sich ja auch ein sehr viel hierachischer zbuffer lohnen oder sehe ich das jetzt falsch.

Ja schnelles Z-Culling kann da nützlich sein vorallem da man bei WGF das ganze mit den occlusion querys verbinden möchte. nVidia hat dafür auch schon eine experimentelle OpenGL Extension für aktuelle Karten.

[RLZ]

Ja schnelles Z-Culling kann da nützlich sein vorallem da man bei WGF das ganze mit den occlusion querys verbinden möchte. nVidia hat dafür auch schon eine experimentelle OpenGL Extension für aktuelle Karten.
leicht offtopic aber was solls :)
Wo find ich dazu ne Doku?
In der offiziellen Registry hab ichs mal noch nicht gefunden :(
Schon in den aktuellen Treibern drin? Und wie ists von der Performance her?

[zompel]

Hmmm also irgendwie wirft da die lame Star was ganz schön durcheinander, erst reden sie das raytracing mit Quake 3 möglich ist, aber dann bringen sie screenshots von UT2003/4?

Später stimmts ja wieder aber am Anfang?:ugly:


http://www.gamestar.de//graphics/bild_db/10200/10219/PopUp_800x600.idg

Aber am lustigsten find ich ja die Bilder, hmmmm 2009, so ne gute Grafik :eek:.

Sieht für mich eher nach der grafik von UT2004 aus ;D

:rolleyes: Ja, ja...die gute alte Gamestar.

Manchmal bin ich auch ein wenig geschockt über deren Unwissenheit. Aber in
der Regel nur wenn es um sehr technische Details geht. (nicht, daß ich viel Ahnung habe, nur man liest ja auch 3DC :cool: )
Allerdings erwarte ich von der Gamestar auch nicht wirklich viel in dieser Richtung, mich interessieren dort hauptsächlich Spiele.

Aber bei dem Interview finde ich das bestätigt, was Demirug etwas weiter oben geschrieben hat....es geht den Firmen hauptsächlich um den Wirtschaflichkeitsfaktor. Die Äußerungen von David Kirk lassen zumindest darauf schließen, daß es in absehbarer Zeit keine reinen Raytracingoptimierten Karten von nVidia geben wird!

[Demirug]

leicht offtopic aber was solls :)
Wo find ich dazu ne Doku?
In der offiziellen Registry hab ichs mal noch nicht gefunden :(
Schon in den aktuellen Treibern drin? Und wie ists von der Performance her?

Dazu wirst du auch nichts finden weil es nicht dokumentiert ist.

Ich weiß nur das es die Extension gibt und das sie im Treiber implementiert ist. Irgendwo habe ich auch die Prototypen der zusätzlichen Funktionen dafür rumliegen. Aber das war es auch schon.

[Coda]

Im nVidia SDK gibt's ein Demo zu der Extension, daran könnte man sich orientieren.
Aber NVX Extensions können sich jederzeit ändern, deshalb würde ich da nicht drauf vertrauen.

[Cenmocay]

Hmmm also irgendwie wirft da die lame Star was ganz schön durcheinander, erst reden sie das raytracing mit Quake 3 möglich ist, aber dann bringen sie screenshots von UT2003/4?

Später stimmts ja wieder aber am Anfang?:ugly:


http://www.gamestar.de//graphics/bild_db/10200/10219/PopUp_800x600.idg

Aber am lustigsten find ich ja die Bilder, hmmmm 2009, so ne gute Grafik :eek:.

Sieht für mich eher nach der grafik von UT2004 aus ;D

die bilder sind ja geil,hab garnicht gewußt das die grafik 2005 so schlecht wird ;D

[karlmeier]

Die Äußerungen von David Kirk lassen zumindest darauf schließen, daß es in absehbarer Zeit keine reinen Raytracingoptimierten Karten von nVidia geben wird!

Ja vielleicht nicht von nVidia, aber schau mal hier www.saarcor.de (http://www.saarcor.de)

Für papers über Ray-Tracing, caustics GlobIllum etc schau mal www.openrt.de (http://www.openrt.de)

Die von nVidia sind ja auch nicht blöd uns wissen dass Grafik in diese Richtung gehen wird, ich glaube aber, dass Sie mehr an der Erweiterung der GPUs festhalten um sie effizient für Ray-Tracing einstzbar zu machen.

Auch der neue Cell-Prozessor soll (was man so mitkriegt) sehr geeignet für Ray-Tracing sein.

Für PC-Spiele wird es aber wahrscheinlich noch ne Weile dauern, aber ich denke dass die Spielehersteller sehr bald Realtime Ray-Tracing für die vorberechneten Sachen wie Shadow-maps u.ä. einsetzen werden.

Wir werden sehen.

M.

[_TTS_]

Damals war auch der Coder von Realstorm (http://www.realstorm.com/) am Insitut und hatte nen Vortrag über sein System gehalten. Schade dass ich mir die Folien net besorgt hab.


Hallo Vasco,

ich war damals derjenige bei Euch am Institut :-) Wenn du die Folien noch haben moechtest, ich habe die noch auf dem Rechner.

Mail mich dann einfach kurz an: contact@realstorm.de

Grüsse

Michael Piepgras
Engine Programming
www.realstorm.com