Diskussion:Raytracing/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Raytracing/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Raytracing/Archiv#Thema_1

Aus dem Review (Juli 2005)

Ich habe den Artikel vor kurzem überarbeitet und würde gerne Meinungen einholen, um ihn eventuell letztendlich zum exzellenten Artikel zu machen. Phrood 2. Jul 2005 18:13 (CEST)

Vor allem die Fußnoten stören. Literatur sollte wie es sich gehört mit Verweis auf das Literaturverzeichnis angegeben werden. Die Entwickler könnte ja auch eigene Personenartikel bekommen, das mit den Kreuzen ist aber nichts (entweder Lebensdaten oder garnichts). Bei "Besonderes" und an anderen Stellen fallen die Weblinks unangenehm auf. Soviel zum Formalen. --Saperaud ☺ 3. Jul 2005 14:11 (CEST)

Im Grunde ist sind die Titel Fachpublikationen. Eine Eingliederung in den Literatur-Abschnitt halte ich nicht für sinnvoll, da die Texte zu spezialisiert sind. Sie sollten aber IMHO, ebenso wie die Weblinks, unbedingt irgendwo erwähnt werden, um dem Text fachliche Seriosität zu verleihen. Wäre ein eigener Abschnitt "Wegweisende Publikationen" oder Ähnliches OK? Was die Personen anbetrifft, werde ich mal sehen, was sich zu ihnen sagen läßt. Phrood 3. Jul 2005 14:33 (CEST)

Natürlich müssen Fachpublikationen, wenn sie als Quelle dienen oder aus anderen Gründen wichtig sind auch mit in das Literaturverzeichnus. Dein Problem läßt sich lösen, wenn du das LIteraturverzeichnis auftrennst in "Allgemeine Literatur" und "Fachliteratur". Natürlich gibt es auch die Möglichkeit der thematischen Trennung, siehe etwa bei dem direkt hier drüber gelisteten River Continuum Concept. Gruß -- Achim Raschka 3. Jul 2005 14:38 (CEST)

Ich habe die Fachliteratur in einen eigenen Abschnitt ausgegliedert. Phrood 3. Jul 2005 19:44 (CEST)

Ich weiß nicht, ob separate Artikel für die Entwickler sinnvoll sind. Obwohl die im Bereich der Computergrafik mehr oder weniger bekannt sind, sehe ich keine besondere Relevanz für die Enzyklopädie; ich lasse das mal. Ist der Artikel "exzellenzwürdig"? Phrood 8. Jul 2005 07:46 (CEST)

Hallo? Will denn niemand mehr sein Feedback loswerden? Phrood 19:35, 12. Jul 2005 (CEST)

Ich würde den Artikel eigentlich auf die Kandidatenliste setzen. Das Oberflächliche ist behoben und für die Details und das genauere Überprüfen findet sich vielleicht dort noch jemand. --Saperaud ☺ 01:52, 16. Jul 2005 (CEST)

An ein paar Ecken würde ich noch feilen. Im Abschnitt Einsatzgebiete heisst es: In Bereichen wie der Virtuellen Realität, in der räumliche Darstellungen in Echtzeit berechnet werden müssen, spielt Raytracing derzeit keine Rolle. und etwas später: Bisher konnte sich Raytracing nicht für den Echtzeitbereich durchsetzen. Diese Dopplung muss nicht sein.

Die Liste der Programme würde ich mir nochmal gut überlegen. Jetzt mag es noch übersichtlich sein, aber jeder will sein Lieblingsprogramm da einfügen, und bald quillt das über. Besser gar keine konkreten Programme auflisten, wenn ein Programm enorme Wichtigkeit in dem Bereich hat, lässt es sich auch im Fliesstext unterbringen.

Die Grafiken sind im Übrigen sehr gut und anschaulich. Das finde ich gut. :-)-- Dishayloo [ +] 02:08, 16. Jul 2005 (CEST)

Danke. Die Dopplung ist enfernt, ebenso die Softwareliste, da es in dem Bereich IMHO keine "Standardprogramme" gibt. Phrood 07:32, 16. Jul 2005 (CEST)

"Es ist heute neben Radiosity eines der großen, und, aufgrund seiner Flexibilität und Eleganz, auch das populärste Verfahren der Bildsynthese." Das ist doch...falsch. Raytracing ist zum einen eines der zwei heute üblichen Verfahren des 3D-Renderings (siehe englischer Artikel zu Rendering) und zum anderen ein sehr eingeschränktes globales Beleuchtungsmodell. Radiosity ist hingegen direkt vergleichbar mit Verfahren ala Photon Mapping. RoKo 21:26, 16. Jul 2005 (CEST)

Daß Raytracing eines der zwei üblichen Verfahren ist, wird im Satz erwähnt. Raytracing ist aber eindeutig populärer (die meisten bekannten Renderprogramme verwenden primär Raytracing, nicht Radiosity). Daß Raytracing nur ein "sehr eingeschränktes globales Beleuchtungsmodell" wäre, ist ebenfalls falsch. Verglichen mit Radiosity ist Raytracing das allgemeinere Verfahren. Path Tracing (mit oder ohne Photon Mapping), Primitives Raytracing+Photon Mapping, (Bidirektionales) Path Tracing und MLT sind alles globale Beleuchtungsverfahren. Dagegen hat Radiosity Probleme mit allgemeinen, speziell glänzenden und spiegelnden, BRDFs. Und schließlich ist Radiosity absolut nicht vergleichbar mit Photon Mapping. Photon Mapping basiert auf Raytracing und ist kein eigenständiges Verfahren, sondern dient der Erweiterung sowohl primitiven Raytracings als auch von Path Tracing. Phrood 21:40, 16. Jul 2005 (CEST)

Radiosity ist auch kein eigenständiges Verfahren. Zumindest wüsste ich nicht, wie ich allein mit Radiosity ein Bild auf den Bildschirm bekomme. Sowohl Photon Mapping als auch Radiosity rechnet man zuerst und unter Zuhilfenahme der daraus gewonnenen Daten kann man dann tracen oder rastern (beim Photon Mapping wohl eher nur tracen).

Oder wie geht das? Wie bekommt man allein mit Radiosity ein Bild auf den Schirm? RoKo 22:34, 16. Jul 2005 (CEST)

Radiosity ist ein eigenständiges Verfahren, weil es die Helligkeit aller Patches berechnet. Die anschließende Projektion ist nur eine Kleinigkeit. Dagegen ist Photon Mapping nicht komplett, weil es (in seinen gängigen Varianten) nicht zur Berechnung der direkten Beleuchtung verwendet wird. Diese muss beim Raytracing vom Augpunkt aus addiert werden. Das zugrundeliegende Prinzip bei Photon Mapping und Radiosity ist jedenfalls völlig verschieden. Phrood 22:45, 16. Jul 2005 (CEST)

Eine Kleinigkeit, die man aber entweder per Rastern oder Raytracing erledigt. Komplett in jeder Beziehung ist wohl allenfalls Forward-Raytracing. Jedenfalls empfinde ich den Satz "Es ist heute neben Radiosity eines der großen, und, aufgrund seiner Flexibilität und Eleganz, auch das populärste Verfahren der Bildsynthese." als verwirrend und denke, man sollte herausstellen, dass Raytracing eines der beiden Rendering-Verfahren ist, neben der Rasterisierung. Wie eben im genannten englischen Artikel zum Rendering. RoKo 22:57, 16. Jul 2005 (CEST)

Wäre eine Formulierung wie "Wie auch Scanline Rendering ist es ein Verfahren zur Szenendarstellung. Neben Radiosity ist es ausserdem einer der großen, und, aufgrund seiner Flexibilität und Eleganz, auch der populärste Algorithmus zur Berechnung der Lichtverteilung." OK? ("Rendering" bezieht sich ja nicht nur auf die Projektion und Ermittlung der Sichtbarkeit, sondern auch auf Shading und den ganzen Rest.)

Komplett im Sinne von "ermittelt die globale Beleuchtung" ist übrigens nicht nur Forward Raytracing. Es ist nur das "extremste" und "robusteste" Verfahren, was aber nicht bessere Bildqualität bedeuten muss. Phrood 23:24, 16. Jul 2005 (CEST)

Diese Formulierung wäre hervorragend. Dass genau dieser Dualismus sonst nicht herausgestellt wird, stört mich meistens, wenn ich etwas über Raytracing lese.

Vielen Dank für eine produktive Diskussion :-) RoKo 00:23, 17. Jul 2005 (CEST)

Bilder

Ist dieses Bild es wert, in den Artikel aufgenommen zu werden:

Es ist mit Raytracing berechnet worden, allerdings sieht man halt nicht so viel davon --Jonathan Hornung 18:07, 18. Jul 2005 (CEST)

Ich habe es mal an den Anfang des Artikels gestellt; hoffentlich stört das nicht den Text bei hohen Auflösungen. Phrood 19:16, 18. Jul 2005 (CEST)

Hallo, wurde das Bild: Global_Illumination_wjp.jpg nicht mit einem Radiosity- bzw. einem kombinierten Raytracing/Radiosity-Verfahren errechnet. Ich beziehe mich auf die diffusen Lichtwuerfe der Lampen an der Wand, zumal auch das Bild als Title schon "global illumination" traegt und auf radiosity hindeutet.

Laut dem Ersteller des Bildes wurde es mit Raytracing erstellt. Nebenbei ist mit reinen Raytracing-Methoden Global Illumination leichter zu bewerkstelligen als mit Radiosity oder hybriden Methoden. --Phrood 15:28, 21. Jan 2006 (CET)

Verbesserungsvorschläge

hallo, der artikel ist verständlich formuliert und deckt das thema gut ab. vielleicht kann man einige der folgenden aspekte noch hinzufügen. manche fakten kommen zwar schon im artikel vor; zum teil fehlt aber die präzisierung.

• basic ray tracing = nur sichtbarkeitsberechnung! (manchmal als ray casting bezeichnet)
• recursive ray tracing = basic ray tracing plus umgang mit schatten, brechung, beugung und reflektion (oft gleich ray tracing, weil damit das globales beleuchtungsmodell gemeint ist)

• basic ray tracing mit shadow rays erstmals von appel 1968 beschrieben
• basic ray tracing erweitert um spekulare reflektionen und transperenz erstmals von whitted und kay 1980

• beispiel für schnittpunktberechnung: bei 1000x1000 pixeln und 100 primitiven gibt das 100 mio berechnungen
• whitted fand heraus, daß 75-95% der system zeit für schnittpunktberechnung benötigt werden.

• effizienzsteigerung des basic ray tracings:
  • optimierung der schnittpunktberechnung
    • liegt ein strahl parallel zu einer der koordinatenachsen kann die schnittpunktberechnung durch den z-buffer algorithmus bestimmt werden (und das geht richtig fix)
    • kompliziert zu prüfende objekte werden durch bounding volumes (wie kugeln, ellipsoide, quader) umschrieben. fällt das bounding volume durch den schnittest, braucht das zu prüfende objekt nicht getestet werden.
  • vermeiden der schnittpunktberechnung
    • idealerweise sollen nur solche objekte auf schnitt getestet werden, die der strahl auch wirklich schneidet. weiterhin ist das primitiv von interesse, welches der strahl als erstes schneidet. diese forderungen können durch "scenenanalysierende" verfahren erreicht werden.
    • hierarchisches partitionieren: objekte werden bzgl. physischen struktur zusammengefaßt (oft angewandt in kombination mit bounding volumes) (z.b. wenn der gesamte tisch beim schnittest durchfällt, braucht jedes einzelne tischbein nicht geprüft werden)
    • räumliches partitionieren: objekte werden bzgl. räumlicher anordnung zusammengefaßt (scene wird in identische würfel unterteilt. schnittest wird nur durchgeführt, wenn objekt in einem vom strahl durchstoßenen würfel liegt)

• alle infos aus: foley, van dam, feiner, hughes - computer graphics: principles and practice ('ne art standardwerk in der computergrafik)

• ende 2004 ist es erstmals gelungen, ray tracing in echtzeit zu realisieren. dazu wurde an einer dt. uni eine spezielle version von quake3 implementiert und diese auf einer kleinen rechnerfarm handelsüblicher pc's zum laufen gebracht. da gibts sogar ein video zum download.

• meiner auffassung nach fehlt im artikel eine klare abgrenzung zwischen
  • was kann ray tracing gut bzw. wozu wird es gern benutzt (z.b. spekulare reflektionen)
  • und was kann ray tracing nicht bzw. nur mit mühe (z.b. weiche schatten, einfluß ambienten lichts).

was haltet ihr von den vorschlägen? feedback wäre schön. grüße, --Murkel ^(anmurkeln) 02:05, 28. Jul 2005 (CEST)

Ich habe auch den Foley. Das Problem ist, er ist für 3D total veraltet. Alles, was über rekursives Raytracing hinausgeht, wird nur, wenn überhaupt, sehr oberflächlich behandelt. Von daher sollte man das Buch heutzutage nicht mehr als Standardwerk beterachten :-)

Was deine Vorschläge betrifft:

• Die Unterschiede zwischen den einzelnen Varianten, und deren Entwickler, werde ich noch besser herausstellen. Den Satz oft gleich ray tracing, weil damit das globales beleuchtungsmodell gemeint ist verstehe ich allerdings nicht. Für Raycasting gibt es einen eigenen Artikel.
• Die Zahlenbeispiele werde ich eventuell noch einbauen (mit den 75-95% sollte man allerdings vorsichtig sein, da die Angabe ziemlich alt ist und von vielen Faktoren abhängt).
• Was die Beschleunigungstechniken angeht: davon gibt es einfach zu viele. Sicher wäre es möglich, einen weiteren Artikel zu dem Thema zu dem Thema zu schreiben, aber da es nunmal keine Standardmethode gibt, halte ich es für besser, in diesem Artikel nur vom allgemeinen Prinzip der "Unterteilungen" zu sprechen, genauso, wie ich auch die Details der Schnittpunkttests weggelassen habe. Es gibt nicht nur hierarchische Quader und Voxelgitter, sondern auch "Adaptive Grids", "Hierarchical Grids", "Ray classification", "kd-Bäume", um nur einige zu nennen. Alle davon sind gebräuchlich. Ein Artikel, der nur einen Überblick über alle diese Techniken bieten würde, wäre dreimal so lang wie dieser Artikel. Der Trick mit dem Z-Buffer ist übrigens bedeutungslos, da er nur auf Primärstrahlen angewendet werden kann.
• Was die erste Realisierung von Echtzeit-Raytracing angeht, so wäre ich vorsichtig mit diesen Aussagen. In Demos wurde schon lange vor 2004 Echtzeit-Raytracing angewendet. Das im Artikel erwähnte Paper ist von 2001.
• Zu deinem letzten Punkt: Raytracing wird schon lange nicht mehr nur für spekulare Reflexionen verwendet. Dass Raytracing auch weiche Schatten kann, ist im Abschnitt "Diffuses Raytracing" beschrieben. Ebenso wird die Möglichkeit der Simulation von indirektem Licht ("ambientes Licht" bedeutet ja nur, dass man die Helligkeit künstlich um einen festen Wert erhöht) im Abschnitt "Path Tracing" und den darauf folgenden beschrieben.

Phrood 02:52, 28. Jul 2005 (CEST)

• ich gebe dir recht, was die aktualität des foley's angeht. da es in diesem buch aber um computergrafik im allg. geht (und nicht nur um globale beleuchtungsmodelle) halte ich es für ein grundlegendes werk.
• zum unterschied raytracing und raycasting - habe ich so aus dem foley übernommen und er scheint mit deinem identisch zu sein, siehe Diskussion:Raycasting. soll heißen: ray casting = algorithmus zur sichtbarkeitsbestimmung; ray tracing = rekursives raytracing
• so wie ich das verstanden habe, bezieht sich die zahlenangabe nur auf den algorithmus zur sichtbarkeitsanalyse
• ich bin schon der ansicht, einige wichtige beschleunigungsverfahren mit anzugeben, da sie die praktikable nutzung von raytracing erst ermöglichen. ein eigenes lemma ist doch dafür allerdings nicht nötig.
• sekundärstrahlen kommen doch erst beim rekursiven raytracing zum einsatz; die benutzung des z-buffers zur schnelleren schnittpunktberechnung sollte legitim sein.
• die pros und cons beziehen sich auf raytracing im allg. - ich wollte damit nur ausdrücken, daß erst spezielle adaptionen des verfahrens entwickelt werden mußten, um einige effekte realisieren zu können. so 'ne hübsche übersicht ähnlich der im radiosity artikel wäre doch toll.
• danke für den link zum echtzeit raytracing; btw die quake geschichte zielte auf die erste hardwaretechnische umsetzung eines raytracing chips

--Murkel ^(anmurkeln) 13:02, 28. Jul 2005 (CEST)

Meine Sorge ist, dass der Artikel zu sehr mit Details überladen wird und daher die Motivation des Lesers abnehmen könnte. Vorschlag zur Güte: ich füge noch ein Beispielbild zur Illustration der Szenenunterteilung (ähnlich wie Fig. 15.62 im Foley) hinzu, und eine Art Pyramidendiagramm, das die Evolution der verschiedenen Raytracing-Verfahren aufzeigt. Eine Übersicht ähnlich Radiosity mit Vor- und Nachteilen erübrigt sich, da Raytracing mittlerweile auf allen Bereichen konkurrenzlos oder zumindest anderen Verfahren ebenbürtig ist. Man kennt nun mal keine praktikablen Alternativen. Phrood 13:16, 28. Jul 2005 (CEST)

du hast recht, der artikel wird dann zu voll - wäre es sinnvoll, einzelnen raytracing verfahren eigene artikel zu spendieren? die grafische darstellung der entwicklung der raytracing verfahren finde ich eine gute idee. --Murkel ^(anmurkeln) 13:37, 28. Jul 2005 (CEST)

Für die einzelnen Raytracing-Verfahren gibt es doch schon detailliertere Hauptartikel! Darauf wird in den einzelnen Abschnitten verlinkt - siehe Diffuses Raytracing, Path Tracing, Forward Raytracing, Photon Mapping. Dieser Artikel soll ein guter, klarer, knapper Übersichtsartikel sein. Phrood 13:46, 28. Jul 2005 (CEST)

Hallo, ich habe den folgende Verbessungsvorschlag für die Einleitung:
statt: "bei denen die Ausbreitung von Lichtstrahlen simuliert wird"
fände ich folgende Formulierung präziser: [...] bei denen die Reflektion von Lichtstrahlen an virtuellen Objekten simuliert wird.
Erläuterung: die Simulation der Ausbreitung (an sich) ist ja witzlos - denn die ist ja von Natur aus linear ...
Der Witz von Raytracing besteht ja darin, daß man berechnen will, was mit dem Lichtstrahl nach dem Auftreffen auf einen Körper / Objekt / etc. passiert.
193.175.23.191 23:05, 7. Dez 2005 (CET)

Der Kern von Raytracing ist nicht, zu berechnen, was bei der Interaktion mit Objekten passiert (das ist Sache des Shaders), sondern die Schnittpunkte zu berechnen. Außerdem geht es ja nicht nur um Reflexion, sondern auch Brechung, Absorption und Streuung. Beim Raytracing durch Materialien, deren Brechungsindex kontinuierlich variiert (s.a. Raytracing in der Seismologie unten) kann der Strahl auch gekrümmt sein. "Ausbreitung" ist hier in dem Sinne gemeint, dass die Lichtstrahlen durch die Szene "wandern". --Phrood 07:39, 8. Dez 2005 (CET)

Software

Mich hat bei der Lektüre des Artikels gewundert, dass nicht auf die Standard-SW hingewiesen wurde (entweder als WP-Link oder extern). Ich hätte es auchs elbst geändert, aber ich kenne nur aus alten Tagen POVray und weiss nicht, ob das heute überhaupt noch eine Referenz wert ist (Ich war eigentlich hier um mich nach Raytracing-SW umzusehen). Alecsander 19:01, 4. Aug 2005 (CEST)

Die Diskussion hatten wir schon weiter oben; es wurde beschlossen, die Softwareliste zu entfernen, da es heutzutage keine Standardsoftware mehr gibt. Wie auch im Artikel deutlich wird, verwenden heute praktisch alle Renderer Raytracing in irgendeiner Form. Phrood 20:48, 4. Aug 2005 (CEST)

Da ich nicht die Diskussion gelesen hatte, habe ich den Link "Software" mit dem Verweis auf POV-ray eingefügt der später von Benutzer Phrood gelöscht wurde.

Ich möchte mich mit Raytracing beschäftigen und habe erwachtet das es im Artikel einen Verweis auf Software gibt die meistens benutzt wird.

Wenn es keine Standardsoftware mehr gibt, wie heißen den bitte die "Renderer" die in irgendeiner Form Raytracing benutzen? Wo bekomme ich diese Software und was ist für einen Einsteiger geeignet und was für einen Profi? Es gibt immer wieder Bilder die ich sehe die mir gefallen. Womit wurden diese berechnet - welche Software wird von Firmen benutzt um Bilder die man in der Werbung sieht zu berechnen? Gibt es gute Programme im Freeware Bereich die mit professionellen Programmen vergleichbar sind?

Keine dieser Fragen kann mir der Artikel beantworten da es nur um die Technik geht. Mir ich klar das Wikipedia keine (Kauf)beratung für Software abgeben kann/soll - aber es scheint ja doch von Interesse zu sein welche Software es im Raytracing Bereich gibt. --Gedeon 17:23, 8. Dez 2005 (CET)

In diesem Artikel geht es um einen Algorithmus, nicht um Renderpakete. Einen Überblick findest du aber unter 3D-Modellierungswerkzeug (ein Artikel 3D-Renderer fehlt noch). --Phrood 18:50, 8. Dez 2005 (CET)

Exzellenz-Diskussion, 16. Juli

Aus dem Review. Als Hauptautor enthalte ich mich. --Phrood 08:39, 16. Jul 2005 (CEST)

• Dafür: Meine Kritik wurde vom Autor noch schnell abgearbetet, jetzt hab eich nichts mehr zu meckern. :-) -- Dishayloo [ +] 10:25, 16. Jul 2005 (CEST)

•  Pro dito --Jonathan Hornung 08:09, 19. Jul 2005 (CEST)

•  Pro : Ein gar nicht so einfaches Thema ist hier einigermaßen verständlich und spannend beschrieben. Gute Veranschaulichung anhand von Grafiken. Gut, daß das Programmierbeispiel in Pseudo-Code angelegt ist (auch von Nichtprogrammierern nachzuvollziehen). Auch die Erweiterungen wie Rekursives Raytracing, Diffuses Raytracing, Path Tracing , etc. sind gut abgehandelt. Die hier besonders wichtigen Faktoren des Bedarfs an Prozessorbefehlen und Speicher sind gut beschrieben. Trotzdem gleitet der Artikel nie in "Fachchinesisch" ab. Die unumgänglichen Fachbegriffe sind gut verlinkt. Eine ausführliche Literaturliste, Weblinks sowie Magazine die sich dem Thema widmen, runden den Artikel ab. Fazit: Klasse Artikel ! Gruß Boris Fernbacher 18:45, 18. Jul 2005 (CEST)
•  Pro--G 16:21, 20. Jul 2005 (CEST)
•  Pro. Endlich kann ich auch mal als Nicht-Laie hier ein Pro verteilen. Ein ganz und gar überzeugendes Machwerk zum Thema, das auch die notwendigen Hintergründe erläutert ohne dies zu übertreiben, oder damit zu langweilen. Gelungen finde ich auch die Erläuterung zur Effizienzproblematik usw. --chris 論 22:28, 20. Jul 2005 (CEST)
•  Neutral  Kontra da es hier um einen exzellenten Artikel geht, vermisse ich einen Abschnitt zur Geschichte. Welche Technik wurde wann entwickelt und wie lange dauerte ein typisches Bild zu berechnen. --Atamari … 10:09, 31. Jul 2005 (CEST)

Die Geschichte (mit Datumsangaben) lässt sich anhand des chronologisch geordneten Abschnitts "Erweiterungen" verfolgen; ein separater Abschnitt wäre daher IMHO redundant. Zur Entwicklung der Renderzeit habe ich leider keine Informationen gefunden. Phrood 21:30, 31. Jul 2005 (CEST)

Es geht hier aber um einen exzellenten Artikel, da interessiert mich die Renderzeit doch gewaltig. Diese ist zwar abhängig von der Prozessorleistung - wirkt sich aber zu Nutzen des Raytracings aus. Interessant wären Beispielbilder aus den verschiedenen Jahren um zu sehen was jetzt und vor fünfundzwanzig Jahren machbar ist und war. Sorry aber ich ändere meine Meinung von neutral auf contra, da schon bei den lesenswerte strenge Kriterien gelten, sollte möglichst bei den exzellenten keine (berechtigte) Fragen mehr offen bleiben. --Atamari … 14:24, 4. Aug 2005 (CEST)

•  Pro Die Frage nach den Renderzeiten ist berechtigt, aber deren Angabe meiner Meinung nach aus folgenden Gründen nicht zwingend notwendig:
  • Die Laufzeit ist von der gesamten Ausstattung des Rechners abhängig, es müssten also detaillierte Angaben zu Prozessor, Arbeitsspeicher, Bussystem undsoweiterundsofort gemacht werden - diese würden sich IMHO negativ auf die technische Einfachheit des Artikels auswirken.
  • Die Renderzeit ist - wer hätte es gedacht - von dem gerenderten Bild abhängig. Man kann nicht zwei Bilder mit unterschiedlichen Detailstufen direkt miteinander vergleichen.
  • Die Angabe von Renderzeiten aus unterschiedlichen Jahren macht eine Aussage darüber, wie sehr sich die Rechenleistung der Computer seitdem verbessert hat; sie macht keine Aussage darüber, was das ganze mit dem Rendering System zu tun hat.

Nach diesen Anforderungen müsste ich vom Artikel Bremse verlangen, dass er mir mit Diagrammen und historischen Entwicklungen die verschiedenen Bremswege und Reaktionszeiten verschiedener Bremssysteme aufzeigt - natürlich unter exakter Angabe, in welchem Automobiltyp von welchem Hersteller mit welcher Ausstattung die Werte ermittelt wurden. Das schießt meiner Meinung nach deutlich über das Ziel hinaus! --Thetawave 17:07, 4. Aug 2005 (CEST)

Da gebe ich Thetawave Recht. Die Renderzeit hängt von zu vielen Faktoren ab - neben der verwendeten Szene und dem verwendeten Verfahren vor allem von der Maschine. Schon beim Benchmarking von Beschleunigungsverfahren hat man Probleme beim Vergleich. Wie sagte Eric Haines, der Entwickler der Standard Procedural Databases: "With these databases we may be comparing oranges and apples, but it's better than comparing oranges and orangutans". Historische Bilder aus den verschiedenen Jahren aufzutreiben, dürfte schwierig sein (© ACM SIGGRAPH!). Phrood 21:15, 4. Aug 2005 (CEST)

•  Pro Cooler Artikel. Wenn man noch etwas mehr auf die Renderzeit eingehen will, könnte man vielleicht noch einen Halbsatz im Abschnitt "Einsatzgebiete" einfügen. In etwa wie "Mitte der 1990er Jahre hätte das noch Wochen statt Stunden gedauert" (keine Ahnung, ob das stimmt.) Für mich macht der Satz "Siehe Radiosity für einen detaillierten Vergleich zwischen Raytracing und Radiosity" in dem Abschnitt aber keinen Sinn. Radiosity wird nur mal kurz in der Einleitung erwähnt und ist da auch schon verlinkt. Deswegen schmeiße ich den Satz mal raus. --KAMiKAZOW 14:58, 5. Aug 2005 (CEST)

Nun ja, die Renderzeit hat man immer so lang gehalten wie vertretbar (meist vermutlich mehrere Stunden, genaue Infos dazu habe ich fast keine in den alten Publikationen gefunden). Das hat die Komplexität der Szenen und der Algorithmen limitiert. Zu sagen dass z. B. MLT für eine bestimmte Szene Anfang der 1980er zwei Wochen mit einem Cray anstatt heute zwei Stunden mit einem Athlon gedauert hätte, halte ich nicht für sinnvoll. Diese Information würde mehr über Computertechnologie als über den Algorithmus aussagen. Phrood 15:11, 5. Aug 2005 (CEST)

Raytracing in Akustik und Hochfrequenztechnik

Durch Zufall bin ich auf diesen für die Bildverarbeitung sehr schönen Artikel gestoßen. Was mir auffiel: Raytracing wird auch in der Akustik und Hochfrequenztechnik verwendet. Hier kommen zum Teil weitere andere Techniken zur Anwendung, v.a. auf Grund der unterschiedlichen Zielsetzung. Zielsetzung Akustik zum Beispiel: Simulation, Bauakustik, Konstruktion, Lärmbekämpfung, Design von Beschallungsanlagen, Virtuelle Realität etc. Zielsetzung HF-Technik (Mobilfunk) zum Beispiel: Netzabdeckung Techniken zum Beispiel: i.d.R. Raycasting (auch ray launching) (weil Senderzentriert), Spiegelquellen, manchmal wachsende (um den Winkel zwischen den Rays auszugleichen) kugelförmige Rezeptoren mit Erkennung des Einfallswinkels, andere Brechungs-, Streuungs-, Beugungs-, Reflexionsmodelle zum Teil stark vereinfacht, v.a. in der HF-Techik (im Vergleich zur Optik). Modellierung von Sendecharakerisiken. In der Akustik auf Grund der benötigten Rechenleitung noch Nischenphänomen bzw Foschungsthema, in der HF-Techik meines Wissens nach Stand der Technik. Bezogen auf diese Anwendungen sollte auch der Hinweis rein, dass Raytracing (zumindest in den beiden Fällen) ein Simulationswerkzeug ist, wenn Differentialgleichungen auf Grund der Geometrie/der Nebenbedingung zu komplex werden (Stichwort Maxwellgleichungen).

Als Quelle kann ich zZ leider nur google bieten.

Gibt es die Inhalte schon wo anderes? Dann wären Links und Hinweise sinnvoll. Weiß nicht, wie man den Artikel anpassen könnte ohne ihn zu zerstören/ohne dass er zu lang wird. Ggf. eine Begriffsklärung einfügen? Oder (mathematische) Techniken/Modelle und Anwendung trennen?

O weh, da hast du wohl recht. Grundsätzlich scheint Raytracing auf beliebige "Strahlen" (d.h., geometrische Annäherung von Wellen) anwendbar zu sein. Am besten wäre es IMO, wegen des grundsätzlich gleichen Verfahrens alles unter diesem Lemma zu belassen. Die einzelnen Abschnitte könnte man dann für die verschiedenen Anwendungen unterteilen. Die Frage ist, ob der Artikel noch das Label "exzellent" verdient, vielleicht sollte man ihn zur Abwahl stellen. --Phrood 12:35, 5. Dez 2005 (CET)

hmm, halte ich für recht radikal (den Artikel so zu "zerstückeln"). Mein Eindruck ist, dass die Überschneidungen zwischen den drei Bereichen (was die konkreten Techniken angeht --- abgesehen von der zugrundeliegenden Methodik der Strahlverfolgung) eher marginal sind (am ehesten noch zwischen Akustik und Optik). (Bin allerdings kein Experte, hatte nur mal ein Uniseminar, in dem alle drei Bereiche (v.a. Akustik, Bild und HF eher rudimentär) auftauchten.)). Ich würde eine Begriffsklärung ggf. mit Methodik vorschalten (Welle-Teilchen-Dualismus, eher abstrakt, ggf. auch den Ray casting Artikel mit einbinden, Sender <=> Empfänger zentirert etc.), und dann davon abhängig etwas wie RT_Computergraphik, RT_Akustik, RT_HF-Technik. Den aktuellen Artikel könnte man dann als Computergraphik-Artikel einbauen (ggf. mit einem verlagern der Methodik in den Übersichtsartikel)!? --193.174.67.20 13:10, 5. Dez 2005 (CET)

Die Grundlagen (d.h., Lösung des Sichtbarkeitsproblems) sind bei allen Verfahren gleich, ebenso dürften die Reflexionsmodelle (Spiegel, Lambert) Parallelen aufweisen. Andererseits ist wohl das Anwendungsverfahren in der Tat nicht identisch. Bei der Computergrafik wird eine Bildebene verwendet, für Akustik und HF-Technik sendet man vermutlich vom gewünschten Punkt Strahlen in alle Richtungen aus. Vernünftig wäre es wohl, am Ende des Artikels einen Abschnitt "Andere Anwendungen" o.ä. einzufügen, in dem man die Unterschiede und speziellen Anforderungen in diesen Bereichen erklärt. Ich werde versuchen, in nächster Zeit den Artikel dahingehend zu überarbeiten. Eine Begriffsklärung oder einen Hauptartikel zum Prinzip halte ich nicht für die beste Lösung, da die Computergrafik das bei weitem prominenteste Feld ist und wahrscheinlich kaum jemand in absehbarer Zeit Artikel zu den anderen Bereichen schreiben wird. --Phrood 18:20, 5. Dez 2005 (CET)

Klingt zumindest mal nach einem guten Anfang. In absehbarer Zeit kann ich aus zeitlichen Gründen selber kaum was machen (zumindest nicht in der Qualität, die ich selber von mir fordern würde ;-) )(Auch würde ich an deinem Artikel potentiel mehr kaputmachen als wert-schöpfen, da dies hier meine ersten Beiträge sind). Allerdings habe ich hier noch meinen Vortrag/meine Entwurfsschriften (vier Seiten Stichpunkte relativ selbsterklärend) (somit (bis auf Bilder im Vortrag) auch copyright-unkritisch) von besagtem Seminar rumliegen, und da mein Thema damals (vor 5 Jahren oder so) "Grundlegende Wegfindungsmethoden und Beschleunigungsmethoden beim Ray Tracing" war, aber eben auch mit Bezug zu Akustik und HF-Technik, könnte das Material ggf. bei deiner Überarbeitung helfen?! Ist allerdings aus der Sicht eines Nachrichtentechnikers (Szene als 3D-Übertragungsfunktion, Impulsantworten, Frequenzselectivität, Wellenlängen <=> Objektgrößenproblematik, Aliaseffekte durch Abtastung bei Raytracing etc.) Wenn Du mir sagst wie, kann ich Dir das gerne zukommen lassen. Alternativ gibt es in Aachen das Seminar auch noch (am ITA), und die Webseite von dem Seminar könnte evtl. auch Ansatzpunkte für die Überarbeitung liefern.--84.59.111.243 22:14, 5. Dez 2005 (CET)

Auch in der Seismologie verwendet man Raytracing, um die Laufzeit seismischer Wellen zu berechnen. Dort geht es aber, im Gegensatz zur Computergrafik, nicht um Sichtbarkeit etc., sondern um die unterschiedlichen Eigenschaften des Mediums. Mit der Tiefe nimmt die Geschwindigkeit zu, daher sind die Strahlen gekrümmt – und die Kunst ist, herauszufinden, welchen Weg der Strahl nehmen wird. Daher kann nicht mit Geraden gearbeitet werden, sondern man geht iterativ vor. --Christoph 02:41, 7. Dez 2005 (CET)

Lemma

Was ist denn hier los? "Strahlverfolgung" mag ja in Erklärungen angebracht sein, aber doch nicht als Lemma. Das ist ja noch schlimmer als Wettlaufsituation. Sollte nicht die gebräuchlichste Bezeichnung das Lemma stellen? --jailbird 20:38, 7. Dez 2005 (CET)

Für die Verschiebung war Benutzer:Stern verantwortlich ;-). Mir ist das Lemma aber eigentlich egal. --Phrood 21:20, 7. Dez 2005 (CET)

Die Verschiebung war natürlich inakzeptabel; der Begriff "Strahlverfolgung" ist absolut unüblich (und kommt witzigerweise im Artikel nach dem ersten Satz gar nicht mehr vor!). Man kann's mit der Eindeutschung auch übertreiben. Ich habe das jetzt mal rückgängig gemacht.--Eloquence 21:32, 7. Dez 2005 (CET)

"absolut unüblich"? Mhh. Schau doch mal bei Google nach. Für mich ein durchaus üblicher Begriff. Im Zweifel in der de-Wikipedia den deutschen, weil üblicheren, Begriff oder etwa nicht? Stern 22:02, 7. Dez 2005 (CET)

568 deutsche Seiten für "Strahlverfolgung". 239.000 deutsche Seiten für "Raytracing" und noch mal 42.300 für "ray tracing".--Eloquence 22:12, 7. Dez 2005 (CET)

stern, diesmal bist du zu weit gegangen. das grenzt an vandalismus. -- ∂ 22:30, 7. Dez 2005 (CET)

Strahlverfolgung ist ein bekanntes Synonym, das nicht einmal den Hauptautor des Artikels stört. Ich denke mir hier ja kein Wort aus. Stern 09:39, 8. Dez 2005 (CET)

Ich habe auch nichts gegen Strahlenverfolgung und habe es auch schon oft als Erklärung in Texten gelesen. Aber wie ich schon schrieb ist es als hauptsächliche Benennung des Vorgangs auch im Deutschen unüblich, das ist doch der springende Punkt.

Wobei's schon interessant ist, daß sich bis gestern, also drei Tage lang, niemand daran gestört hatte, aber jetzt sogar von Vandalismus geschrieben wird. Soweit gehe ich nicht, deshalb frage ich vor (Rück-)Verschiebungen ja auch nach Gründen. --jailbird 11:28, 8. Dez 2005 (CET)

"bekannt" in dem sinne, daß man erraten kann, daß raytracing gemeint ist: ja. bekannt im dem sinne, daß es eine nennenswerte verbreitung gefunden hätte: nein. -- ∂ 12:59, 8. Dez 2005 (CET)

∂ hat da schon Recht. Ich habe bisher in deutschen Papers auch immer nur "Raytracing" gelesen. Sollte man die Eindeutschung konsequent betreiben, dann müsste man das Radiosity-Verfahren auch "Ausgehende Bestrahlungsstärke" nennen, und das hört sich nun wirklich Scheiße an, oder? --Phrood 13:06, 8. Dez 2005 (CET)

Vierdimensionales Raytracing

Nach dem Benutzer Phrood sich erlaubt hat die Erläuterungen zur Besonderheit dieser Raytracing-Variante ersatzlos aus dem Artikel zu streichen, habe ich mir erlaubt daraus einen eigenständigen Artikel zu machen und lediglich mit "siehe auch" dem Leser eine Möglichkeit zum Weiterkommen an zu bieten. Das vermeidet hoffentlich einen Edit-War. Generell würde ich es aber bevorzugen, wenn solche Grenzfall-Entscheidungen nicht einsam getroffen würden, sondern eben erst zur Diskussion gestellt werden. Mir kommt der ursrpüngliche Vorgang jedenfalls vor als würde man aus einem Artikel "Kraftfahrzeug" jeden Hinweis z.B. auf Schwertransportfahrzeuge tilgen. --Alexander.stohr 19:44, 8. Dez 2005 (CET)

Der Abschnitt "Besonderes" bietet nur Beispiele, und 4D-Raytracing ist nur für spezielle Anwendungen interessant. Es gibt noch viele weitere Ergänzungen. Insofern halte ich einen eigenen Artikel und den kurzen Verweis mit dem "siehe auch" für eine gute Lösung. --Phrood 19:55, 8. Dez 2005 (CET)

Was gibts denn noch für Besonderheiten? *neugierig werd* --Alexander.stohr 22:55, 9. Dez 2005 (CET)

Z.B. Simulation von Lichtbeugung, Interferenz und dünnen Schichten, Raytracing in Materialien mit kontinuierlich variierenden Brechungsindex, komplexe Betrachtermodelle (dicke Linsen und Linsensysteme), Cone Tracing, Beam tracing, Pencil Tracing, "Light Vectors", spezielle Photon-Mapping-Erweiterungen, nicht-fotorealistische Methoden, Mikrogeometrie-Simulatoren für BRDFs, etc. --Phrood 23:29, 9. Dez 2005 (CET)

Revertierung

Mein lieber Phrood,

bevor du etwas leichtfertig revertierst, liest es dir zunächst einmal in Ruhe durch. Mein Beitrag hat nichts verkompliziert. Im Gegenteil, unsaubere und zum Teil falsche Formulierungen habe ich durch eine exakte und übliche Schreibweise ersetzt. Wenn schon solche Rechnungen im Artikel stehen, dann bitte auch richtig und nicht so ein Murks wie vorher. Ich schlage vor, du stellst die von mir verfaßte Version wieder ein - es sei denn du kannst sachliche Bedenken vorbringen. Falls alles so bleibt wie es ist und du es auch nicht für nötig hältst, mir hier zu antworten, werde ich den Artikel erneut zur Kandidatur stellen und entsprechend meine Bemerkungen dazu abgeben.

Bitte erkläre, was an der vorherigen Version inhaltlich falsch war. An deiner neuen Version habe ich zwei Dinge auszusetzen:

1. Du schreibst Eine Lichtquelle außerhalb einer solchen Kugel soll Lichtstrahlen abgeben, die sich geradlinig im Raum ausbreiten. - Was hat eine Lichtquelle beim Schnittpunkttest zu suchen? Beim Raytracing werden im Allgemeinen nicht Strahlen von Lichtquellen ausgesandt.
2. Du schreibst, Jeder dieser Lichtstrahlen stellt, geometrisch gesehen, eine Gerade dar - Das ist falsch; wie auch weiter oben im Artikel vermerkt, sind Strahlen beim Raytracing Halbgeraden, nicht Geraden. Im Übrigen werden nicht nur "Lichtstrahlen" ausgesandt; zumindest ist der Begriff irreführend. Es können auch z.B. Schattenstrahlen ausgesandt werden. --Phrood 20:57, 3. Mai 2006 (CEST)
3. Deine Ergänzungen sind unnötig kompliziert. Du magst mit einigem Recht anmerken, dass in der alten Version strenggenommen die Indizes x, y, z der Vektoren nicht definiert wurden und die Begründung, weshalb eine Hohlkugel die angegebene Gleichung hat, fehlt. Der Leser wird die Gleichungen dennoch verstehen (du konntest es ja offenbar auch). Ich glaube, dass deine Ergänzungen verwirrender als die "unsaubere", aber intuitive Schreibweise wirken. Außerdem machen sie den Abschnitt, der nur als kleines Beispiel gedacht ist, unnötig lang.

--Phrood 20:53, 3. Mai 2006 (CEST)

Bitte erkläre, was an der vorherigen Version inhaltlich falsch war. - z.B. Wenn der Wert unter der Wurzel negativ ist, so besitzt die Gleichung keine Lösung -- die quadratische Gleichung besitzt sehr wohl eine Lösung, wenn die Diskriminante negativ ist. Nur sind diese Lösungen für den Geradenparameter dann komplexe Zahlen. Diese Lösungen sind zwar nicht sinnvoll, aber sie existieren nun mal.

Was hat eine Lichtquelle beim Schnittpunkttest zu suchen? - Gegenfrage: Was ist daran so falsch? Hier geht es darum, zu veranschaulichen, wann ein Strahl etwas schneidet. Der Leser möchte sich unter dem Strahl etwas vorstellen - und was liegt da näher, als einen Lichtstrahl (der irgendwo seinen Ursprung, seine Quelle, haben muss) zu nehmen. Und dass dieser Ursprung außerhalb der Kugel liegen soll, ist sicherlich auch eine nicht zu unterschlagende Information.

sind Strahlen beim Raytracing Halbgeraden, nicht Geraden. - Ok, Strahlen sind immer Halbgeraden - Flüchtigkeitsfehler von mir.

Der Leser wird die Gleichungen dennoch verstehen (du konntest es ja offenbar auch). - Was ist das denn für ein Argument? Wir nehmen das, was schlechter ist, weil es für die Leute gut genug zu sein scheint? Wenn wir die von mir favorisierte Variante nehmen, wird es der Leser es auf jeden Fall und in wesentlich kürzerer Zeit begreifen. In der jetzigen (von dir wiederhergestellten Formulierung) ist der fragliche Abschnitt und damit der gesamte Artikel nicht exzellent.

Zu 1) Präzisiert.

Zu 2) Strahlen werden meist nur beim Photon Mapping, Forward Raytracing oder anderen von der Lichtquelle aus arbeitenden Verfahren teilweise von der Lichtquelle ausgesendet. Wir haben keinen Grund anzunehmen, dass wir diese Verfahren, die erst später im Artikel beschrieben werden, verwenden. Damit sich der Leser unter einem Strahl etwas vorstellen kann, gibt es ja die Bilder. Der Test funktioniert auch innerhalb der Kugel.

Zu 4) Ich bin nicht der Meinung, dass die höhere Rigorosität deiner Variante mangelnde Klarheit rechtfertigt. Vielleicht äußern sich noch andere Leser dazu. --Phrood 09:22, 4. Mai 2006 (CEST)

Ich bin nicht der Meinung, dass die höhere Rigorosität deiner Variante mangelnde Klarheit rechtfertigt. - Langsam geht mir deine ungeheure Ignoranz (oder ist es Arroganz?) ganz gewaltig auf den Senkel.

Wenn es schon nicht richtig gemacht wird, sollte es einfach weggelassen werden (evtl. mit Verweis auf Literatur).

Schnittpunktbeispiel

hatte eine IP gerade aus dem artikel gelöscht - war zwar nicht begründet, aber ich halte derart spezielle details auch nicht für wirklich sinnvoll in diesem artikel - andere meinungen? -- ∂ 12:18, 6. Mai 2006 (CEST)

Beispiel für einen Schnittpunkttest mit einer Kugel:

Die Oberfläche einer Kugel mit dem Radius $r$ ist durch folgende Gleichung definiert:

$x^{2}+y^{2}+z^{2}=r^{2}$.

Der Strahl mit dem Ortsvektor für den Anfangspunkt $p_{0}$ und dem Richtungsvektor $d$ ist durch folgende (vektorielle) Geradengleichung definiert:

$p_{0}+t\cdot d$ (mit $t\geq 0$).

Nun muss man die oben genannte Geradengleichung in die Gleichung für die Kugel einsetzen. Da eine Gerade eine Kugel an maximal zwei Punkten schneidet, läuft diese Umformung auf eine quadratische Gleichung hinaus.

$(p_{x}+t\cdot d_{x})^{2}+(p_{y}+t\cdot d_{y})^{2}+(p_{z}+t\cdot d_{z})^{2}=r^{2}$

Nach dem Ausmultiplizieren und Umstellen zur allgemeinen Form einer quadratischen Gleichung ergibt sich:

$(d_{x}^{2}+d_{y}^{2}+d_{z}^{2})\cdot t^{2}+2\cdot (d_{x}\cdot p_{x}+d_{y}\cdot p_{y}+d_{z}\cdot p_{z})\cdot t+p_{x}^{2}+p_{y}^{2}+p_{z}^{2}-r^{2}=0$

Die eventuellen reellen Lösungen – die Entfernungen $t_{1}$ und $t_{2}$ zu den Schnittpunkten – können durch Einsetzen in die allgemeine Lösungsformel

$t_{1,2}={\frac {-b\pm {\sqrt {b^{2}-4ac}}}{2a}}$

berechnet werden, wobei

$a=d_{x}^{2}+d_{y}^{2}+d_{z}^{2}$,

$b=2\cdot (d_{x}\cdot p_{x}+d_{y}\cdot p_{y}+d_{z}\cdot p_{z})$ und

$c=p_{x}^{2}+p_{y}^{2}+p_{z}^{2}-r^{2}$ ist.

Wenn der Wert unter der Wurzel negativ ist, so besitzt die Gleichung keine reelle Lösung, und der Strahl verfehlt die Kugel. Bei genau einer Lösung ist der Strahl tangential zur Kugeloberfläche; bei zwei Lösungen trifft er auf die Kugel.

Da nur der nächste Schnittpunkt zählt, wird bei zwei Lösungen das kleinere $t$ größer 0 verwendet. Der Schnittpunkt kann durch Einsetzen von $t$ in die allgemeine vektorielle Geradengleichung berechnet werden.

Anmerkung: Die hier vorgestellte Methode ist nur eine Möglichkeit; für die Kugel gibt es noch einen effizienteren Schnittpunkttest.

Von mir aus kann man es auch ganz weglassen. --Phrood 12:26, 6. Mai 2006 (CEST)

Das andere Bild (Fahrrad)

Korrigiert mich, wenn ich irre, aber m.E. ist das gerade KEIN Beispiel für echtes Raytracing. Der Schatten ist extrem grob und sieht eher danach aus, als sei er anhand einer recht groben (kleinen) Shadow Map berechnet - ein Alternativverfahren, um das aufwendigere eigentliche Raytracing zu vermeiden. Halte ich für ziemlich unpassend als Illustration. --DemonDeLuxe :O) 12:53, 16. Aug 2006 (CEST)

Jetzt wo du es sagst, kommt mir der Schatten auch etwas komisch vor. Bild vorsichtshalber entfernt. --Phrood 19:07, 16. Aug 2006 (CEST)

Punktwolke zum Speichersparen?

Schöner Artikel, aber folgerder Satz ist mir nicht verständlich:

"So wurden punktbasierte Repräsentationen entwickelt, die gegenüber den herkömmlichen Dreiecksprimitiven weniger Speicher belegen, bisher jedoch keine weite Verbreitung gefunden haben."

Als Laie würde man ich denken, dass Dreiecksprimitiven zwar mehr Speicher benötigen, aber man erheblich mehr Punkte braucht, um dasselbe mit einer Punkwolke darzustellen. Somit sehe ich eigentlich nicht den Speicherspareffekt. Vielleicht könnte man das besser klarstellen (evtl. auf Quelle verweisen). -- 84.190.173.96 22:52, 24. Jan. 2007 (CET)

Ich habe das nochmal überprüft, die Information war inkorrekt. Der Speicherverbrauch der Punktwolken ist im Normalfall mit dem von Dreiecken vergleichbar. Punktwolken belegen aber auch nicht zwangsläufig mehr. Sie werden gerendert, indem man einen den Strahl umhüllenden Zylinder gegen einen am Punkt ausgerichteten Kreis testet, um die Lücken zwischen den Punkten auszufüllen. Artikel wurde korrigiert. --Phrood 23:40, 24. Jan. 2007 (CET)

Speicherbedarf ist der Flaschenhals

Zitat: "Es wurde gezeigt, dass auf modernen Rechnern nicht die Prozessorleistung, sondern die Speicherzugriffe den Flaschenhals beim Raytracing darstellen. Durch sorgfältige Nutzung von Caching durch den Algorithmus ist es möglich, die Laufzeit wesentlich zu verringern." Es würden mich brennend Literaturangaben hierzu interessieren. Weiß jemand, wo das gezeigt wurde, oder wo überhaupt was darüber geschrieben wurde? -- Felix Wiemann 05:51, 20. Feb. 2007 (CET)

Aus dem Paper von Wald et. al. (PDF): "Contrary to general opinion, our careful profiling reveals that a ray tracer is not bound by CPU speed, but is in fact bandwidth-bound by access to main memory. Especially shooting rays incoherently (as done in many global illumination algorithms) results in almost random memory accesses and bad cache performance." --Phrood 13:34, 20. Feb. 2007 (CET)

Vielen Dank, Phrood, das hilft mir sehr! Ich habe eine Referenz auf das Paper in den Artikel reingesetzt. -- Felix Wiemann 06:57, 21. Feb. 2007 (CET)

Das Paper war schon im nächsten Satz verlinkt ([7]), daher habe ich deine Änderung rückgängig gemacht. --Phrood 07:16, 21. Feb. 2007 (CET)

Einsatz bei Spielen

Im SPON-Artikel Computerspiel-Grafik in Kinoqualität wird die Auslagerung der Rechenarbeit auf PC-Grafikkarten beschrieben. Wie realistisch sind denn entsprechende Lösungen für die nächsten Jahre? Ist dieses, potentiell auch kommerziell sehr bedeutende Thema für den Artikel nicht interessant? --Nemissimo 酒?!? 12:17, 2. Mär. 2007 (CET)

Den Computerbase-Artikel Raytracing in Spielen empfand ich als Laie in Bezug auf Quake 3: Raytraced auch als sehr interessant. Was sollen das den für "Spezialchips" sein die auf SPON erwähnt wurden? --Nemissimo 酒?!? 12:32, 2. Mär. 2007 (CET)

Ein relevantes Paper zur im SPON-Artikel beschriebenen Technik (“A Hardware Architecture For Ray Tracing”) ist schon verlinkt, ein weiteres des gleichen Saarländer Teams ([1]) könnte noch verlinkt werden. Solange die Technik nicht in breitem Umfang genutzt wird, wäre eine weitergehende Erwähnung ein Blick in die Glaskugel, egal was SPON schreibt. --Phrood 12:35, 2. Mär. 2007 (CET)

Danke für die schnelle Antwort. --Nemissimo 酒?!? 12:53, 2. Mär. 2007 (CET)

Erklärungen

Die Erklärung im Artikel Raytracing "Um Rauminformationen (auch Szene genannt, z.B. Raum mit Stuhl und Lampe) auf ein Bild abzubilden wird im Raytracing eine Ebene in den Raum vor die virtuelle Kamera (man spricht auch vom Augpunkt) gelegt, durch die für jedes abzubildende Pixel mindestens ein Strahl von der Kamera durch das Pixel auf der Ebene in die Szene geschickt und zurückverfolgt wird." empfinde ich als misslungen und ich rege an, dass ein Autor, der sich mit der Materie auskennt, die folgenden Unklarheiten beseitigt:

- Wer bei "Kamera" nicht an einen Punkt ohne räuliche Ausdehnung sondern an ein räumliches Gebilde denkt, hat keinen Anhaltspunkt, ob mit Augpunkt die Kamera gemeint ist oder der Raum vor der Kamera oder eine Ebene im Raum vor der Kamera.

- In der Erklärung steht, dass durch die Ebene ein Strahl durch das Pixel auf der Ebene geschickt wird, das verwirrt.

- In der Erklärung wird zwischen Pixeln auf der Ebene und abzubildenden Pixeln unterschieden. Übersichtlicher wäre es, als Pixel nur die (bereits abgebildeten) Bildpunkte zu bezeichnen, nicht die Oberflächen in der Szene.

- Da der Strahl durch "das" Pixel auf der Ebene geschickt wird, entsteht der Eindruck, es sei ein bestimmtes Pixel gemeint, alle vorher erwähnten Pixel befanden sich jedoch nicht auf der Ebene, sondern in der Szene, auch das verwirrt.

- Da der Strahl gerade ist, ist er durch zwei Punkte eindeutig definiert. In der Erklärung wird jedoch gefordert, dass er durch drei Punkte (Kamera, Pixel auf der Ebene, abzubildendes Pixel) verläuft. Das ist verwirrend wenn nicht gar falsch, da der Verlauf durch "das" Pixel auf der Ebene keine Anforderung an den Strahlverlauf ist, sondern die Lage des abgebildeten Pixels auf der Ebene das Ergebnis des Strahlverlaufs ist.

- In der Erklärung heißt es, dass ein Strahl von der Kamera in die Szene geschickt und zurückverfolgt wird. Da es egal ist, ob ein Strahl von der Kamera zu einem bestimmten Punkt in der Szene läuft oder von diesem Punkt in der Szene zur Kamera läuft, er in beiden Fällen die Ebene am selben Ort durchstößt, bleibt unklar, welche Bewandtnis es mit der Richtung hat.

J.R.Weber 13:56, 27. Jan 2005 (CET)

Antwort:

- sämtliche erwähnten Pixel befinden sich auf der Bildebene

Beim Raytracing wird ein Strahl von dem Augpunkt der virtuellen Kamera durch jedes Pixel der vor der Kamera und senkrecht zu ihr liegenden Bildebene in die Szene geschickt.

Dem jeweiligen Pixel wird ein dem Auftreffpunkt in der Szene entsprechender Farbwert zugewiesen.

Ergänzung:

Anfang Januar 2005 veröffentlichte die Informatik-Fakultät der Saarbrücker Uni, das es gelungen ist, eine Raytracing-Grafikkarte zu entwickeln.

http://www.saarcor.de/

MfG Kaeru Gaman

Rendering mit RGB-Farbwerten

Die Aussage, dass ein Renderer nur mit RGB-Farbwerten rechnet, ist inzwischen falsch geworden, da der Maxwell Render von der spanischen Firma Next Limit intern mit physikalisch korrenkten Spektralwerten rechnet, welches zu verblüffend realistisch aussehenden Ergebnissen führt.

Korrekt. Man nennt das spektrales Rendering. Phrood 2. Jul 2005 00:13 (CEST)

Raycasting

Zum interessanten Thema Raycasting vs. Raytracing habe ich unter Diskussion:Raycasting eine Diskussion eröffnet. Phrood 19:02, 18. Jul 2005 (CEST)

Pseudocode

Hallo, Phroods Änderung bzgl. des Pseudocodes des rekursiven Raytracing ist ganz okay, aber sollte man dann nicht eher auch den rekursiven Charakter darstellen (das sich die Funktion selber aufruft - oder ist hier indirekte Rekursion nach dem Beispiel A->B, B->A gemeint). Im aktuellen Pseudocode kommt dies "garnicht" bzw schwer rüber. Auch die Zeile "Wenn Nächster_Schnittpunkt(Schattenstrahl).Gewinner ≠ (kein)" ist verwirrend. Was hat "Gewinner" und "(kein)" für eine Bedeutung?

Den rekursiven Charakter habe ich versucht herauszustellen. Was die Zeile "Nächster_Schnittpunkt(Schattenstrahl).Gewinner ≠ (kein)" angeht, so bedeutet sie, dass kein Schnittpunkt vorliegt. Das wird ersichtlich, wenn man sich den Pseudocode von Nächster_Schnittpunkt ansieht. --Phrood 12:58, 18. Sep 2005 (CEST)

Bild

Raytrace.jpg

Das nebenstehende Bild wurde von Herr Klugbeisser eingebaut, da es verwaist war. Ich hatte das Bild entfernt, weil es offenbar von einem fehlerhaften Algorithmus generiert wurde (Lichtbrechung und Reflexion sehen seltsam aus). Es wäre daher wünschenswert, es durch ein korrektes Bild zu ersetzen. --Phrood 13:36, 6. Okt 2005 (CEST)

Appel beabsichtigt?

Wird die Firma nicht Apple statt Appel geschrieben?

Appel ist der Name einer Person, nicht des Unternehmens (s.a. "Erwähnte Veröffentlichungen" im Abschnitt "Literatur"). --Phrood 20:02, 8. Dez 2005 (CET)

Erweiterung

Ich habe mal einen kurzen Abschnitt zur Akustik und HF-Technik eingefügt, der einen Überblick vermitteln soll; Ergänzungen oder Berichtigungen sind willkommen. Die Anwendung in der Seismologie zähle ich nicht zum Raytracing, da hierbei offenbar keine Schnittpunkttests durchgeführt werden. --Phrood 09:10, 29. Dez 2005 (CET)

Particle Trace

Ich hätte da eine Frage, und zwar: Ist das Particle Tracing gleich dem Path Tracing oder etwas ganz anderes? --Vraneon 19:42, 3. Nov. 2007 (CET)

Ist was anderes. Beim Particle Tracing werden AFAIK "Partikel" von den Lichtquellen ausgesendet und dann in einer Art Textur gespeichert, um Kaustiken und dergleichen zu simulieren. Photon Mapping ist wieder etwas anderes, da die Photonen nicht in einer Textur, sondern in einer unabhängigen Datenstruktur gespeichert werden. Path Tracing arbeitet konzeptuell mit Strahlen und immer vom Augpunkt aus. --Phrood 14:38, 4. Nov. 2007 (CET)

Danke! Das heißt es fehlt ein Artikel über das Particle Tracing? Denn ich konnte auch in der englischen Wikipedia keinen Artikel darüber finden. --Vraneon 14:46, 4. Nov. 2007 (CET)

Ja, im Moment gibt es noch keinen Artikel. Das ist aber auch nicht verwunderlich, da PArticle Tracing nur selten verwendet wurde. Ich habe mal ein Paper und eine Webseite zum Thema gesehen, kann mich allerdings nicht mehr erinnern, wo. --Phrood 15:35, 4. Nov. 2007 (CET)

Willst lieber du,- irgendwann einmal - einen Artikel über das Particle Tracing verfassen, da du dich so gut mit Tracing und Ähnlichem auskennst? --Vraneon 16:25, 4. Nov. 2007 (CET)

Habe ich z.Z nicht vor. --Phrood 18:34, 4. Nov. 2007 (CET)

Pseudocode

Im Pseudocode wird der Funktion Farbe_am_Schnittpunkt nur der einfallende Sichstrahl und der Schnittpunkt übergeben. Zur Berechnung der Helligkeit des Farbwertes ist allerdings noch die Normale der Fläche erforderlich. Sie wird benötigt, um den Reflexionswinkel des Lichts zu berechnen. Ohne diesen, kann nur die Farbe des Materials ohne Berücksichtigung der Lichtquelle ermittelt werden. Lonewalker 13. Jan 2008 11:15 (CEST)

Ich bin davon ausgegangen, dass die Variable Schnittpunkt von einem Verbundtyp ist, dessen Einträge alle nötigen Informationen enthalten. Hier im Beispiel wird nur auf .Gewinner und .Distanz zugegriffen, man kann sich auch vorstellen, dass Einträge wie .Position oder .Normale vorhanden sind. --Phrood 11:27, 13. Jan. 2008 (CET)

Ich möchte mich nur für diesen wunderbaren Artikel bedanken, der es mir als Nicht-Mathematiker und Informatik-Laie ermöglicht, in die Thematik einzusteigen. [Toni Grappa]

Danke für das Lob :-) --Phrood 23:05, 9. Mär. 2008 (CET)