Raytracing?

[MadMan2k]

Ich bin durch Zufall im Grafigchip-Forum auf diese Engine (http://www.realstorm.de/) gestoßen, die ja ein echtzeit Raytracer sein soll.
Also hab ich sie mir grad mal runtergeladen und durchlaufen lassen - von der Bildqualität ist sie der Doom3-Engine ja bei weitem Überlegen, aber dafür hab ich bei max. Details @ 1024x768 auch ganze 5spf... ;)
Nun habe ich IMO das polygonbasierte Rendering soweit kapiert, aber Raytracing = Bahnhof.
Könne mir vielleicht jemand von den Gurus kurz die Unterschiede erklären?

/edit

Outcast verwendete ja eine Voxel-Engine - schmeckt das so ähnlich, wie Raytracing?

[RLZ]

Raytracer können auch polygonbasiert sein mal vorneweg.
Das was du wahrscheinlich meinst sind die normalen Rasterizer, die in der Mainstreamgrafik zu finden sind. Bei ihnen werden (inzwischen von den GPU´s) die Polygone auf die Bildfläche projektiert.

Raytracer gehen nun anders vor. Wie der Name schon sagt werden Rays getraced. Also auf deutsch Strahlen verfolgt. Überlicherweise schiesst man also Lichtstrahlen von der Kamera aus durch die Bildebene (oder auch Linsensystem wenn man Lust hat) in den Raum hinein und schaut was man trifft. An diesem Punkt schaut man nun was man weiter macht, schiesst Strahlen auf Lichtquellen, Reflektionsstrahlen usw wie man Lust hat und berechnet sich damit eine Oberflächenfarbe die man zurückgibt. Ein Vorteil davon ist vorallem, dass Schatten praktisch kostenlos entsteht. Wenn ein Lichtstrahl nicht bei der Lichtquelle ankommt bleibts halt dunkel. Ein andere Vorteil ist, dass die Beschleunigerstrukturen nur die Objekte überprüfen müssen die wahrscheinlich von einem Strahl getroffen werden.
Sollte als grundsätzliche Erklärung mal langen.
Die Demos von der Page zeigen imo keine so beeindruckende Bildqualität und ich halte OpenRT (eine Raytracing-API, die vom Grafiklehrstuhl an der Uni Saarbrücken entwickelt wird) für noch wesentlich leistungsfähiger. "Leider" sind die Informationen dazu etwas spärlich. Bis die normalen Enduser das ganze zuhause am PC für Spiele verwenden können wird aber noch einige Zeit vergehen....

[Coda]

von der Bildqualität ist sie der Doom3-Engine ja bei weitem Überlegen, aber dafür hab ich bei max. Details @ 1024x768 auch ganze 5spf...
Weshalb? Die Schatten sind genauso hart und das Licht ist auch nur Dot3 ...

[MadMan2k]

erstmal danke an RLZ :up:

Original geschrieben von Coda
Weshalb? Die Schatten sind genauso hart und das Licht ist auch nur Dot3 ...
hast mal am Aanfang auf den Dampf geachtet?
Wenn du da durchschaust, wird alles dahinter korrekt Verzerrt.
so schönes Wabbern hab ich bisher in keinem Spiel gesehen :)

[MadMan2k]

so, nur nochmal zum Verständniss:

wir haben als Ausgangssituation einen Würfel per Verktoren, die zu Polygonen zusammengesetzt sind, (Matrizen?, hatte sowas noch nicht in Mathe) unendlich genau definiert.
Den Seiten des Würfels sind Texturen zugeordnet, die Farbinformationen enthalten.
Außerdem haben wir eine Kamera, sich im Würfel befindet.
(evtl. Lichtquelle)
Jetzt wird beides, relativ von der Kamera, durch irgendwas perspektivisch korrekt Verzerrt.

Rasterizer:
legt ein endlich genaues Raster auf das "Objektiv(Projektionsfläche)" (=> Aliasing), meinetwegen 1024x768, und nimmt für jeden Pixel(im zentrum des Pixels = 1xAA) die dahinterliegende Farbe.
Evtl. Beleuchtung übernimmt der VS auf Polygonbasis. (Doom3)

Raytracer:
legt ebenfalls ein endlich genaues Raster auf das Objektiv, verschießt jedoch von jedem Polygon aus einen Strahl, der auf die Seitenwände trifft und von ihnen Abgelenkt wird.
Wenn dieser irgendwann die Lichtquelle Erreicht, die bei diesem Verfahren unbedingt da sein muss, wird er angezeigt.

was ist alles falsch?

Dann hast du noch gesagt, dass man beim Raytracer nicht unbedingt, Polygone benutzen muss - in dem Falle wird alles gleich mit Vektoren beschrieben, oder ganz anders?

und ist die Voxel-Engine dann nochmal was ganz anderes?

[Coda]

hast mal am Aanfang auf den Dampf geachtet?
Wenn du da durchschaust, wird alles dahinter korrekt Verzerrt.
so schönes Wabbern hab ich bisher in keinem Spiel gesehen
Mag sein, aber ob es deshalb so unglaublich viel besser aussieht als Doom 3 sei dahingestellt. Du kannst diesen Effekt auch mit nem Rasterizer erreichen übrigens ...
In Zukunft wird es hoffentlich auch bei der Hardware in Richtung Raytracing gehen, weil viele Sachen die jetzt entstehen (das ganze dynamische Licht usw.) einfach besser und einfacher zu berechnen sind und das sogar schneller wenn richtig implementiert.

Du kannst mit einem Raytracer alles rendern bei dem du mathematisch berechnen kann wo und ob ein Ray/Strahl trifft.

Also, Kugeln z.B. lassen sich genau beschreiben (ohne Millionen Polygone) weil es für ray/sphere collision eine Formel gibt

Bei Figuren die zu einer Formel hoch 4 oder mehr führen muss man mit Newton Raphson ran oder ähnliche Näherungsverfahren

Legt ebenfalls ein endlich genaues Raster auf das Objektiv, verschießt jedoch von jedem Polygon aus einen Strahl, der auf die Seitenwände trifft und von ihnen Abgelenkt wird.
Wenn dieser irgendwann die Lichtquelle Erreicht, die bei diesem Verfahren unbedingt da sein muss, wird er angezeigt.
Nene. Pro Pixel auf dem Bildschirm wird ein Strahl vom "Auge" aus durch das Pixel des Bildschirms "geworfen" und berechnet wo dieser zuerst auftrifft, bei diesem Punkt wird dann berechnet wie er weiter verläuft (bei Refraktion und Reflexion) oder welche Lichtquellen sichtbar sind (mit weiteren Rays)

[betasilie]

Also Voxel sind quasi Pixel, die um eine Dimension erweitert wurden; quasi 3D-Pixel. Sie sind die kleinsten Elementes eine gerasterten Raumes. Mit Raytracing hat das aber nichts zu tun. ... Die Voxelgrafik wird übrigens bei medizinischen Messungen oft benutzt (Computertomographie), da man so halt den gescannten Raum mit der Voxeltechnik als Rasterraum darstellen kann, wohingegen sich Polygone eher mit der Öberflächengeometrie von Körpern "beschäftigen". ;)

Und ein Raytracer muss nicht zwingend Polygone nutzen. Es können auch Nurbs benutzt weren. Das sind Linien die durch Stützpunkte zu beliebigen Kurven verformbar sind.

[Coda]

Also die Engines am PC die sich "Voxel Engines" schimpfen (was sie eigentlich nicht sind, im klassischen Sinne) haben schon was mit Raytracing zu tun (eher Raycasting, aber das ist ein anderes Thema)

[RLZ]

Original geschrieben von MadMan2k

Rasterizer:
legt ein endlich genaues Raster auf das "Objektiv(Projektionsfläche)" (=> Aliasing), meinetwegen 1024x768, und nimmt für jeden Pixel(im zentrum des Pixels = 1xAA) die dahinterliegende Farbe.
Evtl. Beleuchtung übernimmt der VS auf Polygonbasis. (Doom3)


Was meinst du in dem Zusammenhang mit Aliasing?
Raytracing schützt da auch nicht davor :(


Raytracer:
legt ebenfalls ein endlich genaues Raster auf das Objektiv, verschießt jedoch von jedem Polygon aus einen Strahl, der auf die Seitenwände trifft und von ihnen Abgelenkt wird.
Wenn dieser irgendwann die Lichtquelle Erreicht, die bei diesem Verfahren unbedingt da sein muss, wird er angezeigt.

was ist alles falsch?


Also nochmal von Vorne :)
Du legst ein Raster auf die Projektionsfläche und schiesst dadurch Strahlen von einem Punkt aus. Dadurch ist ganze automatisch perspektivisch verzerrt (geht aber auch ohne die Verzerrung wenn man will). Diese Strahlen verfolgt man durch den Raum und tut jedes Objekt das möglicherweise getroffen wird auf einen Schnittpunkt überprüfen. Aus was dieses Objekt besteht ist egal, solange man einen Schnittpunkt ausrechnen kann. Das kann von Nebel über Dreieck, Rechteck,Splines,Nurbes, Kugel, Torus, Würfel, etc alles sein, das irgendwie mathematisch beschrieben werden kann. Wenn man nun eine den nächstgelegensten Schnittpunkt berechnet hat, kommt das Shaderkonzept zum Tragen. Objekt getroffen -> Shader aufrufen. Dieser Shader soll nun eine Farbe zurückgeben. Wie er das macht, ist eigentlich egal. Wenn der Shader keine Lichtquellen berücksichtigt braucht man auch keine. Wenn Reflektion darstellen will schiesst er in Reflektionsrichtung einen (oder auch mehrere bei Distributed Raytracing) Strahl und kriegt von diesem Strahl ja wiederrum eine Farbe zurück, die er entsprechend ins Ergebnis einfliessen lassen kann. Durch dieses einfache Konzept sind die Shader unabhängig voneinander und arbeiten auf Reflektionen usw einwandfrei zusammen (naja meistens jedenfalls ;) ).
Bei OpenRT kann man diese Shader zB als eine C++ Funktion schreiben. Es gibt aber auch extra Sprachen dafür wie zB Renderman, die von Pixar und damit in vielen Kinofilmen verwandt wird.

[zeckensack]

Original geschrieben von MadMan2k
Rasterizer:
legt ein endlich genaues Raster auf das "Objektiv(Projektionsfläche)" (=> Aliasing), meinetwegen 1024x768, und nimmt für jeden Pixel(im zentrum des Pixels = 1xAA) die dahinterliegende Farbe.
Evtl. Beleuchtung übernimmt der VS auf Polygonbasis. (Doom3)

Raytracer:
legt ebenfalls ein endlich genaues Raster auf das Objektiv, verschießt jedoch von jedem Polygon aus einen Strahl, der auf die Seitenwände trifft und von ihnen Abgelenkt wird.
Wenn dieser irgendwann die Lichtquelle Erreicht, die bei diesem Verfahren unbedingt da sein muss, wird er angezeigt.

was ist alles falsch?Ich würde den Unterschied ganz anders ansetzen.
Rasterizer arbeiten seriell ein Dreieck nach dem anderen ab, haben also kein 'Wissen' über die Gesamtszene. Es werden wirklich nur die resultierenden Pixelfarben und Z-Werte dauerhaft gespeichert, aber keine Oberflächeneigenschaften, und auch nicht wie die Pixel entstanden sind. Salopp gesagt kann ein Rasterizer einen Screenshot nicht von einem selbst erzeugten Bild unterscheiden.

Raytracer arbeiten mit vollständigen Szenenbeschreibungen. Bevor nicht alle in der Szene vorhandenen Objekte bekannt sind, wird mit dem Rechnen garnicht erst angefangen.

[MadMan2k]

Original geschrieben von RLZ
Was meinst du in dem Zusammenhang mit Aliasing?
Raytracing schützt da auch nicht davor :(

wollt´ nur nochmal überprüfen, ob ich aths Artikel verstanden habe :)



Also nochmal von Vorne
Du legst ein Raster auf die Projektionsfläche und schiesst dadurch Strahlen von einem Punkt aus. Dadurch ist ganze automatisch perspektivisch verzerrt (geht aber auch ohne die Verzerrung wenn man will). Diese Strahlen verfolgt man durch den Raum und tut jedes Objekt das möglicherweise getroffen wird auf einen Schnittpunkt überprüfen. Aus was dieses Objekt besteht ist egal, solange man einen Schnittpunkt ausrechnen kann. Das kann von Nebel über Dreieck, Rechteck,Splines,Nurbes, Kugel, Torus, Würfel, etc alles sein, das irgendwie mathematisch beschrieben werden kann. Wenn man nun eine den nächstgelegensten Schnittpunkt berechnet hat, kommt das Shaderkonzept zum Tragen. Objekt getroffen -> Shader aufrufen. Dieser Shader soll nun eine Farbe zurückgeben. Wie er das macht, ist eigentlich egal. Wenn der Shader keine Lichtquellen berücksichtigt braucht man auch keine. Wenn Reflektion darstellen will schiesst er in Reflektionsrichtung einen (oder auch mehrere bei Distributed Raytracing) Strahl und kriegt von diesem Strahl ja wiederrum eine Farbe zurück, die er entsprechend ins Ergebnis einfliessen lassen kann. Durch dieses einfache Konzept sind die Shader unabhängig voneinander und arbeiten auf Reflektionen usw einwandfrei zusammen (naja meistens jedenfalls ;) ).
Bei OpenRT kann man diese Shader zB als eine C++ Funktion schreiben. Es gibt aber auch extra Sprachen dafür wie zB Renderman, die von Pixar und damit in vielen Kinofilmen verwandt wird.

so, ähnlich hab ich mir das schon gedacht:
eigentlich wie in RL® - nur in die andere Richtung, um Overdraw zu vermeiden.

[Aquaschaf]

Original geschrieben von zeckensack

Raytracer arbeiten mit vollständigen Szenenbeschreibungen. Bevor nicht alle in der Szene vorhandenen Objekte bekannt sind, wird mit dem Rechnen garnicht erst angefangen.

Ergeben sich daraus irgendwelche Vorteile?

[MadMan2k]

Original geschrieben von Aquaschaf
Ergeben sich daraus irgendwelche Vorteile?
eher schon Nachteile > siehe. pre HSR Ära der Rasterizer.
Aber nicht so extrem wie bei den Rasterizern, bzw. gar nicht, da beim Raytracing automatisch HSR mit drin ist...

[Ailuros]

Original geschrieben von Aquaschaf
Ergeben sich daraus irgendwelche Vorteile?

Siehe Vor- und Nachteile jeglicher Form von deferred rendering/shading.

http://www.beyond3d.com/articles/deflight/

Es gibt Spekulationen die von programmierbarer HW mit selective ray tracing sprechen, aber nicht vor 2005/6.

Interessanter Link:

http://citeseer.nj.nec.com/cache/papers/cs/25937/http:zSzzSzgraphics.stanford.eduzSzpaperszSzrtongfxzSzrtongfx.pdf/purcell02ray.pdf

John Carmack on ray tracing:

Now there's two directions to go about this. There's companies that have made ray-tracing acceleration chips, that do ray-tracing in a fairly conventional way, where it's object/ray intersections. There's some benefit there... it's going to be a little bit of a hard sell. It might show up in some specialized markets. That type of thing might happen when ray-tracers are getting their asses kicked so thoroughly by rasterizers using real-time hardware that that type of hardware may wind up getting some small market there... but I don't see it really as effective enough for the real-time gaming market. You've still got all of the scene data management issues.

What I do think is still a potential interesting thing is, and this is something I've thought... there can be some opportunity to maybe make a go at, is ray-tracing into voxels basically, where you make an obtuse, surface-skin voxelization of the world. That's something that's so ideally suited for hardware rasterization on there... it's one of those things where it's tantalizingly close to the type of thing that I tend to do, to like... try and write a hardware rasterizer for voxel tracing. I'm surprised there hasn't been a university project or something like that, because that's something which could be done really, really fast and would give you effectively unlimited geometric detail. There's a bunch of trade-offs there in how you wind up exactly getting some of the specular effects that you're used to getting, where you're not sure about surface geometry, but there's interesting potential directions for a lot of the bi-directional ... [*obscured*] ... at a voxel level.


SA:

Ray tracing is primarily useful for specular and refractive touchups IMO.

Transformed geometry is much more efficient for first hit computation and first order diffuse and specular reflection. Soft shadows with area lights approximated by stocastic multiple sources are handled much more efficiently using antialiased shadow maps than with distributed ray tracing. The situations that transformed geometry can handle cover the vast majority of real world scenes with essentially the same amount of realism as ray tracing.

That said, a hardware ray tracer will be very useful for touching up those parts of a scene where refraction and specular reflection require it and the sooner such a capability is available the better.

Irgendwie hab ich das Gefuehl beim Lesen verschiedener Meinungen, dass selbst fuer selective ray tracing, Multisampling eine eher schlechte Idee sein koennte. Wenn selective ray tracing, dann auch selective Supersampling dafuer (unter anderem).

[RLZ]

Immerhin das erste Mal das ich nicht der Meinung von JC bin.
Das Szenenmanagement lässt sich imo in den Griff kriegen. Zum Teil ist das auch schon recht fortgeschritten, lässt sich aber bestimmt noch erweitern und verbessern. Man darf halt nur nicht auf den eingelatschten Pfaden umherwandern :)
Weiche Schatten sind echt ein Problem mit RT in Echtzeit. Es geht aber... Allerdings das Resultat zu vergleichen ist auch unfähr, weil es wesentlich realistischer aussieht als ein aufgeweichter Stencilschatten bei dem nur die Kanten weich sind. Sobald man Antialiasing verwendet gibts mit Interleaved Sampling sogar ne Beschleunigungsschub bei weichen Schatten ;)

[Ailuros]

Keine Sorge die Meinungsverschiedenheit hatten viele mit JC im Thread bei B3D wo ich den Kommentar herausgefischt habe.

Ich muss mich entschuldigen dass ich die relevanten Links vergessen habe; hier der Thread aus dem der obrige Kommentar stammt:

http://www.beyond3d.com/forum/viewtopic.php?t=2961&highlight=ray+tracing

[RoKo]

Es gibt Spekulationen die von programmierbarer HW mit selective ray tracing sprechen, aber nicht vor 2005/6.
Ob sowas mit DXNext in Software sinnvoll wäre - wenn ich auf der GraKa einen Array anlege, in dem alle Punkte stehen, deren spekulare Reflektion eine gewisse Intensität übersteigt, am besten noch mit Object ID, das auslese und an diesen Punkten nochmal mit einem SoftwareRaytracer nachbessere, dessen Bild ich einfach nochmal über das rasterisierte drüberzeichne :kratz2:
Und Refrection, eigentlich sind das doch nur bunte Schatten - also eine ShadowMap und eine ColorMap kombinieren...so fürs erste :kratz2:

[MadManniMan]

Original geschrieben von RoKo
Und Refrection, eigentlich sind das doch nur bunte Schatten - also eine ShadowMap und eine ColorMap kombinieren...so fürs erste :kratz2:

:| Refractions sind Brechungen.

Vielleicht meinst du ja Radiosity? IMHO der große Vorteil des Raytracings. Wenn es auch doch Performance zieht und ohne Volume Shadows (welche noch mehr Performance ziehen :eyes: ) seltsam ausschaut, so ist es doch für eine wirklich glaubwürdige Ausleuchtung unabdingbar. Und dann noch Photon Mapping... *schwärm*

BTW: stimmen die Gerüchte, daß DX Next mit eben Radiosity und Photon Mapping kommen soll? Und wenn dem so ist und Stencil Shadows ordentlich beschleunigt vorgesehen sind, sind diese Shatten dann wenigstens weich? Müssen ja keine Volumes sein, aber mit harten Schatten erscheint Radiosity wie gesagt eher seltsam.

Aber so langs den Kram nicht in HW gibt, freu ich mich einfach darüber, daß die Tapete neben meinem schwarzen Rechner dunkler ist, als neben meinem beigen Schreibtisch :D


edit: wie zum Henker kommt ein Rasterizer eigentlich mit Radiosity klar? Der kennt die Szene doch gar nicht! :grübel:

[Coda]

Weiche Schatten sind echt ein Problem mit RT in Echtzeit.
Nein. Bei genügender Leistung kannst du Photon Mapping in nen Hardware Tracer implentieren und du hast überhaupt keine Lichttechnischen Probleme mehr...

[del_4901]

Original geschrieben von Coda
Nein. Bei genügender Leistung kannst du Photon Mapping in nen Hardware Tracer implentieren und du hast überhaupt keine Lichttechnischen Probleme mehr...

Dazu noch ne Edge-Detection, und andere Späße in HW, und der Chip platzt aus allen Näten.

[Coda]

Bis Raytracing für Consumer in Hardware gegossen wird vergehen wohl noch paar Jährchen, also macht mir das keine Sorgen

[RoKo]

Original geschrieben von MadManniMan
:| Refractions sind Brechungen.
Achscho - na ich unwissende Englischnull. Hatte mal was drüber gelesen, wie man Glas rendert. Da stand dann, Refractions werden nicht berücksichtigt aber ein Bild um sie zu zeigen war dabei, und in dem ist mir nur die Projektion des Glasteils an die Wand aufgefallen.
Wie peinlich, sowas grundsätzliches :sulkoff:
Da kann man doch einfach das Zeugs hinter dem lichtbrechenden Irgendwas verzerren, ist doch mittlerweile üblich.

[ethrandil]

kann man mit RT eigentlich endlich nichtpunktuelle Lichtquellen machen?
z.B. Eine echte Neonröhre?

Dann hätte man doch auch weiche Schatten, oder?

[Coda]

Kommt drauf an. Mit Photon Mapping schon, mit reinem Raytracing sehen die Schatten aus wie in Doom 3 (identisch)

[Gast]

Original geschrieben von ethrandil
kann man mit RT eigentlich endlich nichtpunktuelle Lichtquellen machen?
z.B. Eine echte Neonröhre?

Dann hätte man doch auch weiche Schatten, oder?

Mit Photonmapping oder Distributed Raytracing.
Beides aber arg teuer. Einen Schatten zu erzeugen bei dem nur die Kanten weich sind, kommt mir allerdings einfacher vor. Werd ich mal testen wenn ich wieder zeit hab...

[Fragman]

neonroehren erzeugt man einfach mit zylindrischen lichtern, in cinema zb so integriert. am besten natuerlich mit photon mapping, allerdings geht dann die kontrolle ueber die schatten verloren, da es ja keine definierbare lichtquelle mit schattenoptionen ist.

[egdusp]

Auf der aktuellen Gamestar DVD ist ein Video mit verschiedenen Grafikdemos (u.a. Ruby und Lula (oder wie heißt die NV Nixe)) wo auch ein Raytracer gezeigt wird, der Q3 in Echtzeit mit 200 Modellen darstellt. Ich weiß nicht mehr genau wie gut die Schatten sind Der Programmierer war IIRC von einer deutschen Q3 Seite, evtl. sogar www.quake3.de. Bei Bedarf schau ich nochmal nach.

mfg
egdusp

[RLZ]

Programmierer war Daniel Pohl und er hat den Raytracer nicht selber geschrieben, sondern OpenRT verwendet ;)

Weitere Infos und Spiele unter
http://graphics.cs.uni-sb.de/RTGames/

[Mave@Work]

Original geschrieben von egdusp
und Lula (oder wie heißt die NV Nixe))

Meinst du Dawn ?

[SERUS]

also die grundlagen hab ich jetzt ja verstanden, aber wie genau macht des der raytracer bei der berechnung von global illumination (des is meiner meinung nach mit den vorteilen durch reflektion/refraction einer der größten von RT und wies aussieht wurde des in keinem der OpenRT Demos verwendet- weshalb nur? ^^)?

[Gast]

Radiosity und Photonmapping sind 2 Beispiele wie man GI realisieren kann.
Bei Radiosity samplet man die obere Hemisphäre ab um zu ermitteln wieviel Licht welcher Farbe aus welcher Richtung kommt.
Bei Photonmapping beachtet man das Verhalten von ner gewissen Anzahl von Photonen und ermittelt dadrüber die Beleuchtung. (mal jetzt primitiv erklärt)
Für beides bietet OpenRT Unterstützung an und es gibt auch Demos dafür. Für Spiele ists aber NOCH zu langsam. Es wird aber fleissig dran geforscht ;)
Links kann ich dir jetzt keine bieten, weil der Webserver grade streikt. Aber Citeseer liefert dir jede Menge Ergebnisse zu Interactive Global Illumination, von denen viele auch vom CGUDS sind.

[Gast]

Server geht wieder
Auf www.openrt.de findest du direkte Links auf das Zeugs und Bilder dazu....

[del_4901]

Original geschrieben von Mave@Work
Meinst du Dawn ?
Nein er Meint Nalu! Dawn ist doch schon wieder veraltet... kurze Haare sind OUT!