Diskussion:Raytracing

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)

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)

Raycasting

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

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)

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)

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)

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)

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)