1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Intels Larrabee als Gefahr für…

Paradigmenwechsel...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Paradigmenwechsel...

    Autor: zurreal 19.06.08 - 13:45

    ... dass wäre auf dem Grafikkartensektor wirklich wünschenswert - im Hinblick auf die Raytracing-Technik.

    Dann wird es mit der "realischen" Spielegrafik endlich Realität - nicht so ein Schrott, wie in der letzten Golem-Meldung von Nvidias neuer Demo für ihr Grafikungetüm.

  2. Rastern bleibt die bessere Wahl kt

    Autor: hmmmdmd 19.06.08 - 13:46

    kjhkhj

  3. Re: Rastern bleibt die bessere Wahl kt

    Autor: zurreal 19.06.08 - 14:02

    hmmmdmd schrieb:
    -------------------------------------------------------
    > kjhkhj

    Du siehst also die Zukunft in Nvidias GTX-280, möglichst noch SLI ? Man sieht doch bereits, dass diese Technik bald am Rande des Machbaren steht. Leistungssteigerung ist nur noch mit exorbitanter Abwärme zu realisieren. Oder täusch' ich mich als Laie?

    Aktueller CPU = 80 Watt, GTX-280 = ca. 200 Watt

  4. Noe. Beides.

    Autor: Wyv 19.06.08 - 14:29

    hmmmdmd schrieb:
    -------------------------------------------------------
    > kjhkhj

    Das eine schliesst das andere nicht aus. Im Gegenteil: Wenn man es intelligent anstellt ergänzen sich beide Ansätze sehr gut und sei es, dass man nur bestimmte Ansätze aus dem RT für die Repräsentierung der Elemente einer Szene verwendet.

  5. Re: Rastern bleibt die bessere Wahl kt

    Autor: Ihrgendwehr 19.06.08 - 14:37

    zurreal schrieb:
    -------------------------------------------------------
    > hmmmdmd schrieb:
    > --------------------------------------------------
    > -----
    > > kjhkhj
    >
    > Du siehst also die Zukunft in Nvidias GTX-280,
    > möglichst noch SLI ? Man sieht doch bereits, dass
    > diese Technik bald am Rande des Machbaren steht.
    > Leistungssteigerung ist nur noch mit exorbitanter
    > Abwärme zu realisieren. Oder täusch' ich mich als
    > Laie?
    >
    > Aktueller CPU = 80 Watt, GTX-280 = ca. 200 Watt
    Ja du täuscht dich (besonders da die CPU + GPUs nur unter extremer Vollast solche Werte erreichen werden)

    Im Übrigen hier ein interessantes Interview (es gibt noch mehr dort verlinkt) über Raytracing + Gaming

    http://www.pcper.com/article.php?aid=546

  6. Re: Rastern bleibt die bessere Wahl kt

    Autor: LisasPapa NL 19.06.08 - 15:28

    hmmmdmd schrieb:
    -------------------------------------------------------
    > kjhkhj


    Nimm Dir mal Povray, erstelle von Hand ein Skript und spiele ein bisschen damit rum.

    Der Vorteil bei Raytracing, die Auflösung spielt plötzlich keine Rolle mehr, da gerendertes in jeder Auflösung gut aussieht. Die ganzen Kniffe, die z.Z. wichtig sind um einigermassen hübsche Bilder hinzubekommen sind plötzlich hinfällig.

    Es werden Dinge möglich, die vorher fast nicht möglich waren, echte Schatten, beliebig viele Spiegelungen, verschiedene Ansichten der gleichen Szenerie bei unterschiedlichsten Beleuchtungen.
    Stelle Dir mal Star Wars vor, wenn es aus Tatooi spielt, 2 Sonnen erzeugen 2 Schatten, oder Sportspiele bei Flutlicht, 4 Schatten, das ist ohne Probleme möglich, ohne Tricks.
    Spiele, die bei fast völliger Dunkelheit spielen, jeder Spieler hat nur eine kleine Taschenlampe. Da zählen Schatten, nichts anderes.

    Noch ist Raytracing der echte CPU Killer, aber das kommt, man braucht nur ein paar mehr CPUs.

    LisasPapa.

  7. Re: Paradigmenwechsel...

    Autor: RT-Trollbär 19.06.08 - 15:42

    zurreal schrieb:
    -------------------------------------------------------
    > ... dass wäre auf dem Grafikkartensektor wirklich
    > wünschenswert - im Hinblick auf die
    > Raytracing-Technik.
    >
    > Dann wird es mit der "realischen" Spielegrafik
    > endlich Realität - nicht so ein Schrott, wie in
    > der letzten Golem-Meldung von Nvidias neuer Demo
    > für ihr Grafikungetüm.


    ja..schön liest es sich, wie schon die letzten 10 Jahre... stellen wir uns vor, dass es in 2-5 Jahren so potente RT-Lösungen, dass man sich vorstellen könnte, damit auf den dann gängigen Full-HD-LCDs flüssig zu spielen... die gesamte Spiele-Industrie muss neu angelernt werden... und bei der heutigen Entwicklungszeit für ein wirtschaftlich rentables und inhaltlich erfolgreiches Spiel...werden die Publishers ein enormes Risiko auf sich nehmen müssen, da sich die Ratte ind den Schwanz beisst:

    Ohne Games, kein breiter Bedarf an den Karten, ohne Karten kein Markt für RT-basierte Spiele... denn heute wird alles von Kapitalisten und nicht von Visionären gelenkt...

    Der 3D-Boom auf dem Massenmarkt hat die Masse nur erreicht, weil die grundlegene Technik der Grafik-Darstellung "poliert" (optisch aufgwertet) wurde, nicht weil plötzlich alle Game-Designer neue Techniken lernen mussten, sie konnten langsam damit anfangen, Patches für bestehende Titel zu programmieren, und ihre neuen Kenntnisse in neue projekte einfließen zu lassen...

    Ein ganze Spielwelt durch RT entstehen zu lassen, ist Welten davon entfernt, von dem was heute dafür notwendig ist...

    ich würde mich auch freuen, noch zu "fitten" Lebzeiten reine RT-Welten zu betreten... aber ich denke dann befinden wir uns schon weit im nächsten Jahrzehnt...gut dann bin ich auch noch fit...

  8. Re: Paradigmenwechsel...

    Autor: kobol 19.06.08 - 20:23

    RT-Trollbär schrieb:

    > Ohne Games, kein breiter Bedarf an den Karten,
    > ohne Karten kein Markt für RT-basierte Spiele...
    > denn heute wird alles von Kapitalisten und nicht
    > von Visionären gelenkt...

    Man kann sicher auch OpenGL-Treiber über Raytrace Grafikarten programieren. Und damit sollte es dann kein so grosses Problem beim Übergang geben.

  9. Re: Paradigmenwechsel...

    Autor: Wolfgang Draxinger 19.06.08 - 23:23

    zurreal schrieb:
    -------------------------------------------------------
    > ... dass wäre auf dem Grafikkartensektor wirklich
    > wünschenswert - im Hinblick auf die
    > Raytracing-Technik.
    >
    > Dann wird es mit der "realischen" Spielegrafik
    > endlich Realität - nicht so ein Schrott, wie in
    > der letzten Golem-Meldung von Nvidias neuer Demo
    > für ihr Grafikungetüm.

    Raytracing hat rein gar nichts mit realistischer Graphik zu tun. Es gibt genau zwei Dinge, in denen Raytracing qualitativ besser ist, wie Rasterizing:

    * Berechnung von Lichtbrechungen
    * Berechnung von Reflexionen

    In allen anderen Dingen kann Raytracing nichts besser, wie Rasterizing.

    Thema Beleuchtung:
    * Mit Raytracing sind nur harte Schatten drin, ausser man berechnet für jeden Sehstrahl ein ganzes Bündel von Lichtstrahlen => Langsam
    * Alle Methoden zur globalen Illumination mit indirekter Beleuchung (Radiosity, Photon Mapping) muss auch für Raytracing in einem vorgeschalteten Schritt berechnet werden.

    Dann hat aber Raytracing einen Riesennachteil: Bevor die Szene gerendert wird, muss erst mal eine recht komplizierte Datenstruktur erstellt werden, damit die eigentliche Berechnung des Bildes nicht dadurch verlangsamt wird, indem man jeden Sehstrahl Brute-Force mit sämtlichen Objekten testet. Der Aufbau dieser Struktur braucht (viel) Zeit.

    Ansonsten gilt: Der Realismus in der Echtzeitgraphik wird durch die Simulation bzw. Approximation physikalischer Vorgänge erreicht und bislang funktioniert das mit Rasterizern genauso gut wie mit Raytracern.

    BTW: Pixar setzt in den meisten Szenen ihrer Filme zum Rendern Rasterizing ein. Nur dort wo es wirklich sinnvoll ist, nämlich dort wo Reflexionen oder Lichtbrechung zu berechnen sind wird dort der Raytracer angeschmissen.

  10. Re: Paradigmenwechsel...

    Autor: me2 20.06.08 - 10:34

    Wolfgang Draxinger schrieb:
    -------------------------------------------------------
    > Thema Beleuchtung:
    > * Mit Raytracing sind nur harte Schatten drin,
    > ausser man berechnet für jeden Sehstrahl ein
    > ganzes Bündel von Lichtstrahlen => Langsam

    Das ist Quatsch! Das selben Problem hast du mit Rasterisierung genauso. Da haben sich nur schon eine ganze Reihe von Fakes etabliert. Da bist du mit dem Raytracer sogar zum Teil besser bedient, wenn du ganze Bündel von kohärenten Strahlen auf einmal verfolgen kannst (Stichwort: Cacheeffizienz), oder sehr gute Monte Carlo Verfahren anwenden kannst.

    Im Gegenszug kann man sogar Argumentieren: Shadow Maps (für Rasterisierer) machen unheimlich viele Berechnungen von denen je nach Szene extrem viele komplette Zeitverschwendung waren, weil sie überhaupt nicht sichtbar sein können. Zudem musst du die ganze Zeit höllisch aufpassen dass du nicht in Qualitätsprobleme reinrennst.

    /me

  11. Re: Paradigmenwechsel...

    Autor: Wolfgang Draxinger 20.06.08 - 11:14

    me2 schrieb:

    > Das ist Quatsch! Das selben Problem hast du mit
    > Rasterisierung genauso. Da haben sich nur schon
    > eine ganze Reihe von Fakes etabliert.

    Beim Raytracing ist es nicht anders. Daraus aber auf einen Vorteil von Raytracing zu schließen zeugt nur davon, dass man nur das Marketinggeschwätz beider Lager kennt. Programmiere mal einen eigenen Raytracer, dann können wir weiterreden.

    > Da bist du mit dem Raytracer sogar zum Teil besser bedient,
    > wenn du ganze Bündel von kohärenten

    Ui, seit wann Lösen Raytracer die Maxwell-Gleichungen? Kohärenz ist eine Eigenschaft von Licht, die man nur bei der Betrachtung als Welle beschreiben kann. Was Du meinst sind nahezu kolineare Lichtstrahlbündel. Das Problem ist nur, dass das nicht unbedingt mehr Cacheeffizient bedeutet: Wenn die Szene nicht vollständig in den Cache passt (tut sie unter Garantie nicht), dann braucht nur einer der Strahlen ein Stück Geometrie, welches an ganz anderer Stelle in der Datenstruktur liegt, tangieren und schon gibt's einen Cache-Miss.

    > Im Gegenszug kann man sogar Argumentieren: Shadow
    > Maps (für Rasterisierer) machen unheimlich viele
    > Berechnungen von denen je nach Szene extrem viele
    > komplette Zeitverschwendung waren, weil sie
    > überhaupt nicht sichtbar sein können.

    Es gibt nicht nur Shadow-Maps. Stencil-Volume-Shadows z.B.

    > Zudem musst
    > du die ganze Zeit höllisch aufpassen dass du nicht
    > in Qualitätsprobleme reinrennst.

    Ich plädiere dafür die Sache pragmatisch zu sehen: Heute ist extrem realitätsnahe Graphik in Echtzeit mit Rasterizern möglich geworden und handelt sich sogar um Allerweltstechnik, die unter fast jedem Schreibtisch steht. Im Vergleich dazu dümpelt Echtzeitraytracing nach wie vor vor sich hin, obwohl daran genauso intensiv geforscht und entwickelt wird. Und trotzdem gibt es das bisher nur in einigen Labors.

  12. Re: Paradigmenwechsel...

    Autor: coder 20.06.08 - 15:10

    @Wolfgang Draxinger

    Also erstmal: einen Raytracer zu schreiben ist trivial, dazu reichen locker Anfängerkenntnisse im programmieren, und ein bisschen Mathe. Den wirklich schnell zu bekommen ist die Kunst.
    Also, wenn Dein Raytracer nicht locker ein paar tausend Dreiecke bei ordentlicher Auflösung mit min. 20 fps auf den Bildschirm bringt, brauchst Du Dir da nichts drauf einzubilden.

    Wenn Du so einen Raytracer programmiert hättest, müssten Dir eigentlich klar sein: wenn das heute schon für einfache Spiele reicht auf Prozessoren die 20 - 50 GFlops leisten, wird das auf Hardware die 1 Teraflop oder mehr Leistung bringt und mit Raytracing im Sinn entwickelt wurde, wirklich interessant.

    Ich verstehe auch überhaupt nicht warum die Leute scheinbar immer nur an AAA-Games denken. Mit nem Budget von zig Millionen kann man natürlich auch per Rasterizing tolle Grafik zaubern. Ich seh den Vorteil von Raytracing eher darin, das man eben nicht soviel Aufwand treiben muss um ein ansprechendes Ergebnis zu erziehlen. Das wird mit Sicherheit dann auch kleineren Entwicklern ermöglichen Spiele zu kreieren, die nicht von 90% der potenziellen Spielern ignoriert werden, weil die Grafik nicht ansprechend genug ist.

    Und viele Deiner Vergleiche hinken unheimlich. Scheinbar nimmst Du für Raytracing nur worst case Szenarios, naive Implementation ohne irgendwelche fakes auf standart Hardware an, wärend bei Rasterizing spezielle (sauteure) Hardware und jeder fake in Ordnung ist.

    Das an Raytracing genauso intensiv geforscht wird wie an Rasterizing mag inzwischen vielleicht sogar sein, nur das Rasterizing nen Vorsprung von mehr als 10 Jahren hat, in denen zig Milliarden dort reingepumpt wurden. Das muss erstmal aufgehohlt werden.

    Natürlich sind beim Raytracing bestimmte Effekte recht performance hungrig, aber die Hardware wird von alleine schneller. Man braucht nur abwarten, und bekommt fast von alleine immer realistischere Grafik, ohne viel Aufwand.
    Beim Rasterizing sind es immer mehr und mehr fakes, die dann wieder nur in bestimmten Situationen gut aussehen, und einen zwingen immer wieder neue Speziallösungen zu finden. Ist das wirklich so erstrebenswert?

    Der komplette Wechsel von rasterizing zu raytracing wird natürlich nicht in wenigen Jahren geschehen, aber irgendwann wird es für die meisten Situationen einfach keinen Sinn mehr machen rasterizing zu nutzen, da Raytracing dann meist schnell genug, flexibler und besser zu skalieren ist. Und ich bezweifle das wir von diesem Punkt mehr als 10 Jahre entfernt sind.

  13. Re: Paradigmenwechsel...

    Autor: me2 20.06.08 - 18:12

    Wolfgang Draxinger schrieb:
    -------------------------------------------------------
    > me2 schrieb:
    >
    > > Das ist Quatsch! Das selben Problem hast du
    > mit
    > Rasterisierung genauso. Da haben sich nur
    > schon
    > eine ganze Reihe von Fakes etabliert.
    >
    > Beim Raytracing ist es nicht anders. Daraus aber
    > auf einen Vorteil von Raytracing zu schließen
    > zeugt nur davon, dass man nur das
    > Marketinggeschwätz beider Lager kennt.
    > Programmiere mal einen eigenen Raytracer, dann
    > können wir weiterreden.

    1. Ich hab nicht gesagt, dass Raytracing in diesem Fall überlegen ist, sondern nur dass du da ganz sicher keinen Vorteil bei Rasterisierung hast.
    2. Ich hab einen eigenen Raytracer von praktisch 0 beginnend schon vor 5 Jahren programmiert. Und auch wenn ich damals keine Beschleunigungsstrukur eingebaut habe, weiß ich sehr gut bescheid was es in dem Bereich alles gibt.
    3. Hab ich erst vor 4 Wochen einen Vortrag über ein Paper gehalten, das ausgedehnte Lichtquellen mit ausgedehnten Lichtquellen vollinteraktiv über gerade noch in Echtzeit hinbekommt. Und ich weißt darüber sehr gut bescheit, was da nöglich ist, und welche Probleme es gibt, wo die Nachteile sind und wie sich das mit Raytracing Verfahren vergleichen lässt. Ich kenn also doch ziemlich gut beide Seiten.

    > > Da bist du mit dem Raytracer sogar zum Teil
    > besser bedient,
    > wenn du ganze Bündel von
    > kohärenten
    >
    > Ui, seit wann Lösen Raytracer die
    > Maxwell-Gleichungen? Kohärenz ist eine Eigenschaft
    > von Licht, die man nur bei der Betrachtung als
    > Welle beschreiben kann. Was Du meinst sind nahezu
    > kolineare Lichtstrahlbündel.
    Blah! Bis zu Wikipedia hast du es wohl nicht mehr geschafft, denn dort wäre es gestanden ...
    "Als Kohärenz (lat. cohaerere „zusammenhängen“, Adjektiv kohärent) bezeichnet man allgemein den nach außen gerichteten Zusammenhang oder Zusammenhalt von etwas."
    Das hat überhaupt nix mit Wellenbetrachtungen zu tun, sondern viel mehr mit gleicher Strahlrichtung und "Abstand" der Strahlen von einander.

    > Das Problem ist nur,
    > dass das nicht unbedingt mehr Cacheeffizient
    > bedeutet: Wenn die Szene nicht vollständig in den
    > Cache passt (tut sie unter Garantie nicht), dann
    > braucht nur einer der Strahlen ein Stück
    > Geometrie, welches an ganz anderer Stelle in der
    > Datenstruktur liegt, tangieren und schon gibt's
    > einen Cache-Miss.

    Nur weil du es dir nicht vorstellen kannst, heißt das nicht, dass es nicht geht. Du machst es genau umgekehrt. Du füllst einen Cache mit den Strahlinformationen und holst dir nur ein Objekt, bzw Dreieck jeweils dazu! Und das interessante ist, du kannst nun mit der Brechstange hergehen und dann alle Strahlen aus dem Bündel gegen dieses eine Objekt testen (paralell auf der GPU), ohne dass du einen weiteren Speicherzugriff hast. Und das interessante ist, obwohl du ziemlich blind und stupide sehr viel mehr Strahlen unnütz gegen das Dreieck testest, die du normal gar nicht machen würdest, bist du im Endeffekt schneller, weil die Strahlen die mit dir mitlaufen, praktisch gratis an die Objektdaten des Bündels kommen. Der Rechenaufwand ist da nämlich nicht so gigantisch im Vergleich dazu was das Speicherinterface frist.

    > > Im Gegenszug kann man sogar Argumentieren:
    > Shadow
    > Maps (für Rasterisierer) machen
    > unheimlich viele
    > Berechnungen von denen je
    > nach Szene extrem viele
    > komplette
    > Zeitverschwendung waren, weil sie
    > überhaupt
    > nicht sichtbar sein können.
    >
    > Es gibt nicht nur Shadow-Maps.
    > Stencil-Volume-Shadows z.B.

    Ja, super! Dir ist schon klar warum Shadow-Volumes kaum benutzt werden? Das Ding skaliert direkt mit der Anzahl der schattenwerfenden Objekte, mit der Anzahl der Lichtquellen, und zusätzlich auch noch mit deiner Bild-Auflösung. Das sind natürlich optimale Bedingungen für größere Auflösungen, feinere Geometrie, und mehr Lichtquellen. Und außerdem siehste jedes Eckchen in deinem Objektumriss im Schatten um so mehr.

    > Ich plädiere dafür die Sache pragmatisch zu sehen:
    > Heute ist extrem realitätsnahe Graphik in Echtzeit
    > mit Rasterizern möglich geworden und handelt sich
    > sogar um Allerweltstechnik, die unter fast jedem
    > Schreibtisch steht. Im Vergleich dazu dümpelt
    > Echtzeitraytracing nach wie vor vor sich hin,
    > obwohl daran genauso intensiv geforscht und
    > entwickelt wird. Und trotzdem gibt es das bisher
    > nur in einigen Labors.

    Natürlich, aber woran liegt das? Erstens, daran, dass du mal volkommen Effekte, die dir gerade nicht so gut ins Konzept passen, wie beispielsweise korrekte Spiegelungungen und Brechungen ausblendest, und dir an den allermeisten Stellen ein "sieht glaubhaft aus" reicht. Zeig mir zum Beispiel ein Autorennspiel, in dem sich die anderen Fahrzeuge korrekt im Lack spiegeln! Ganz einfacher Effekt und auch einfach für Raytracing zum umsetzen. Aber du sprichst von Realismus ...
    Zweitens eben, dass die Rasterisierungsalgorithmen sehr einfach und natürlich vom extremen Geschwindigkeitsvorteil der Massenabfertigung profitieren. Da liesen sich die auf der CPU schnellen RT Algorithmen nicht so gut drauf anpassen (zb. die Baumstrukturen), weil dafür brauchst du meist wahlfreie Schreibzugriffe oder mehr Freiheiten in den Shadern die erst in den letzten Jahren auch erst effizient in die GPU Hardware Einzug erhalten haben.


    Und ich sags auch gerne hier nochmal: Das ganze ist kein "Entweder-Oder". Rasterisierung und Raytracing lassen sich sehr gut auch kombinieren, so dass man von beiden die Vorteile nutzen kann.

    /me

  14. Re: Paradigmenwechsel...

    Autor: Wolfgang Draxinger 20.06.08 - 21:05

    coder schrieb:

    > Also erstmal: einen Raytracer zu schreiben ist
    > trivial, dazu reichen locker Anfängerkenntnisse im
    > programmieren, und ein bisschen Mathe. Den
    > wirklich schnell zu bekommen ist die Kunst.
    > Also, wenn Dein Raytracer nicht locker ein paar
    > tausend Dreiecke bei ordentlicher Auflösung mit
    > min. 20 fps auf den Bildschirm bringt, brauchst Du
    > Dir da nichts drauf einzubilden.

    Also mein Raytracer gehörte damals (auf meinem 486-SXer also ohne FPU) schon zur schnelleren Sorte. Allerdings konnte er keine Dreiecke, bzw. flache Primitive im allgemeinen, weil ich schlichtweg zu faul war diesen Test zu implementieren (flache Primitive haben kein Volumen, das ist Numerisch ziemlich haarig, wenn man nur reine Integerarithmetik zur Verfügung hat).

    > Ich verstehe auch überhaupt nicht warum die Leute
    > scheinbar immer nur an AAA-Games denken. Mit nem
    > Budget von zig Millionen kann man natürlich auch
    > per Rasterizing tolle Grafik zaubern. Ich seh den
    > Vorteil von Raytracing eher darin, das man eben
    > nicht soviel Aufwand treiben muss um ein
    > ansprechendes Ergebnis zu erziehlen.

    Quatsch! Um mit Raytracing realistisch aussehende Graphik zu erhalten muss man genauso viel Aufwand treiben, wie bei Rasterizern. Die Mathematik dahinter (Interaktion von Licht mit Materie) ist in beiden Fällen exakt die selbe, der Unterschied zwischen Raytracing und Rasterizing besteht alleine darin, wie die Parameter für die Berechnung ermittelt werden.

    Phong Shading sieht raytraced genauso künstlich aus wie rasterized.

    > Das wird mit
    > Sicherheit dann auch kleineren Entwicklern
    > ermöglichen Spiele zu kreieren, die nicht von 90%
    > der potenziellen Spielern ignoriert werden, weil
    > die Grafik nicht ansprechend genug ist.

    Gute Graphik hat _nichts_(!) damit zu tun. Es gibt 5 teils sehr gelungene OSS 3D-Engines, mit allen Schikanen. Wenn man deiner Argumentation folgt müsste es doch mittlerweile nur so von kommerziell erfolgreichen Independent-Filmen wimmeln, denn hochqualitative Kameras, Top-CGI-Effekte usw. stehen mittlerweile eigentlich jedermann günstig zur Verfügung.

    Ein gutes Spiel zu entwickeln ist vor allem eins: Kunst. Man braucht kreative Leute, nicht nur Programmierer und Techniker, sondern auch Künstler, die ein gelungenes künstlerisches Konzept entwickeln, Schreiber die eine tolle Story liefern, Musiker die einen guten Soundtrack hinbekommen, 3D-Artists die gute Geometrie abliefern usw. Die Technik macht dabei nur einen winzig kleinen Teil davon aus.

    > Und viele Deiner Vergleiche hinken unheimlich.
    > Scheinbar nimmst Du für Raytracing nur worst case
    > Szenarios, naive Implementation ohne irgendwelche
    > fakes auf standart Hardware an, wärend bei
    > Rasterizing spezielle (sauteure) Hardware und
    > jeder fake in Ordnung ist.

    Speziell? Sauteuer?

    Normalerweise ist es doch umgekehrt: 2005 stellte die Uni Saarland auf der CeBit in Halle 9 ihren Echtzeit-Raytracing-Cluster vor (16 Nodes, jeweils 8 Xeon CPUs). Ich hatte viel Gelegenheit mich mit den Leuten zu unterhalten, hatte ich doch von Jugend forscht aus einen Stand mit meinem Projekt, keine 10m entfernt.

    In diesem Cluster wurde wohl so ziemlich jeder bekannte Trick zur Optimierung verwendet um ein VW-Polo-Modell in Echtzeit zu raytracen. Allerdings mit dem Abstrich, dass die Szene statisch war inkl. der Beleuchtung (Photon Mapping, soz. inverses Raytracing der Photonen). Das Laden und Setup der Szene hat dann auch jedesmal eine schlappe Minute gedauert. Und würde sich die Position nur eines Vertex ändern, müsste das komplette Setup neu berechnet werden.

    > Das an Raytracing genauso intensiv geforscht wird
    > wie an Rasterizing mag inzwischen vielleicht sogar
    > sein, nur das Rasterizing nen Vorsprung von mehr
    > als 10 Jahren hat, in denen zig Milliarden dort
    > reingepumpt wurden. Das muss erstmal aufgehohlt
    > werden.

    Lies doch bitte erst mal das Standardwerk dazu:
    "Computer Graphics - Principles and Practice", anno 1991. Vieles von dem, was erst heute praktisch zum Einsatz kommt wurde schon in diesem Buch beschrieben.

    > Natürlich sind beim Raytracing bestimmte Effekte
    > recht performance hungrig, aber die Hardware wird
    > von alleine schneller. Man braucht nur abwarten,
    > und bekommt fast von alleine immer realistischere
    > Grafik, ohne viel Aufwand.

    Gute Graphik kommt nicht von selbst, da steckt harte Forschung dahinter: Wie interagiert Licht mit Materie (nicht in der Theorie, sondern was für Effekte haben Materialien wie Holz, Marmor, Haut in der Elektrodynamik), wie lassen sich die Vorgänge mathematisch einfach beschreiben. Ohne Kenntnis dieser Vorgänge sieht Raytracing genauso chice aus.

    Raytracing ist für genau eine Sache gut: Um pixelgenau zu bestimmen, welcher Bereich des Szenenraumes mit welchen Umgebungsparametern auf welchem Bildschirmpixel zu liegen kommt. Und im Falle von Sekundärstrahlen kann das eine injektive Superposition sein. Die Qualität der Graphik ergibt sich jedoch aus den Algorithmen die man zur Beschreibung der Lichtinteraktion nutzt. Und für diese Algorithmen spielt es keine Rolle, ob der Parametervektor per Raytracing oder Rasterizing ermittelt wurde.

    > Beim Rasterizing sind es immer mehr und mehr
    > fakes, die dann wieder nur in bestimmten
    > Situationen gut aussehen, und einen zwingen immer
    > wieder neue Speziallösungen zu finden. Ist das
    > wirklich so erstrebenswert?

    Beim Raytracing ist es nicht anders. Weiche Schatten? Area Lights wären viel zu teuer, also macht man einen Monte Carlo und Interpoliert die Chose. Diffuse Global Illumination? Vorgeschobenes Photon Mapping oder Radiosity, beides genauso Fake.

    Der einzige Weg ganz ohne Fakes realistisch aussehende Graphik hinzubekommen bestünde darin, die Maxwell Geleichungen für die Szene numerisch zu lösen. Die Datenmenge die aber dann anfallen würde wäre astronomisch. Überschlagen wir das mal: Wellenlänge von Licht ist Größenordnungsmäßig 10^-9, für moderne Spiele möchte man Ausdehnungen von wenigstens 10^3m in jeder Richtung, um das numerisch lösen zu können muss man in Zeitschritten rechnen in der das Licht höchstens um eine Wellenlänge propagiert, also ~10^-9s/10^8 =~= 10^-17s und man braucht so viele Rechenschritte, dass das Licht auch die Chance hat mindestens 10 mal die Szene komplett von einem Ende an's andere zu durchlaufen. Der Speicherbedarf ist also (10^3)^3/(10^-9)^3 = 10^9 * 10^27 = 10^36 zeitabhängige Gitterpunkte. Pro Gitterpunkt sind E-Feld und Poynting-Vektor zu speichern (das B-Feld und den Wellenvektor kann man daraus berechnen). Das wäre dann jeweils ein 4-Vektor (damit das korrekt ist, _muss_ man relativistisch rechnen), also 8 Elemente und die dann natürlich mit doppelter Genauigkeit, damit sich bei so vielen Rechenschritten der Fehler möglichst klein bleibt, macht also ca. 2*10^37 Bytes Speicherbedarf...

    Nicht zeitabhängig, da von den Szenedaten vorgegeben sind Dielektrizität, Suzeptibilität, Ladungsdichte, Dipolterme und Nichtlinearitätsterme, es reicht, diese mit der Auflösung der Geometrie zu speichern, also sagen wir mal millimetergenau. Macht immer noch (10^3)^3/(10^-3)^3 = (10^6)^3 = 10^18 Gitterpunkte, die aber dynamisch erzeugt werden müssen.

    Um eine Frame berechnen müssen ~ (10*10^3)/(10^8 * 10^-17) = 10^4 / 10^-9 = 10^15 Schritte durchgerechnet werden. Insgesamt müsste also pro Frame eine Datenmenge von ~ 10^15 * 10^37 = 10^52 Bytes durch die Gegend kopiert werden um ein einziges Frame völlig ohne Fakes zu berechnen. Ich will mal den Rechner sehen, der das in annehmbarer Zeit packt. Da hilft selbst das Mooresche Gesetz nicht mehr viel.

  15. Re: Paradigmenwechsel...

    Autor: me2 21.06.08 - 02:17

    Wolfgang Draxinger schrieb:
    -------------------------------------------------------
    > In diesem Cluster wurde wohl so ziemlich jeder
    > bekannte Trick zur Optimierung verwendet um ein
    > VW-Polo-Modell in Echtzeit zu raytracen.
    > Allerdings mit dem Abstrich, dass die Szene
    > statisch war inkl. der Beleuchtung (Photon
    > Mapping, soz. inverses Raytracing der Photonen).
    > Das Laden und Setup der Szene hat dann auch
    > jedesmal eine schlappe Minute gedauert. Und würde
    > sich die Position nur eines Vertex ändern, müsste
    > das komplette Setup neu berechnet werden.

    Was willst du mit dem Beispiel hier aussagen? Das Raytracing arsch lahm ist? Der ganze Aufwand geht hier jedoch fürs Photon Mapping drauf! Und nicht für's eigentliche Raytracen. Wenn du ähnliche Effekte mit rein GPU-basierten Lösung haben willst, dann haste die gleichen statischen Szenen, und wartest du locker in der selben Größenordnung! Denn da darfste die gleichen Vorberechnungsschritte machen und die gleichen Datensätze laden. Das ist fast alles praktisch reine Vorarbeit.
    Und fürs Spiegeln Photonen an runden Flächen brauchst hat einen Raytracingalgorithmus schon im Vorbereitungsschritt. Die Vorberechnung kriegste mit dem Rasterisierer ja so gar nicht gescheit hin.
    Und beim Rendern des Abbildes ist der Raytracer dann eben auch in diesem Fall sinnvoller. Was du eben mit dem Raytracer hinbekommst, sind die schönen runden (und korrekten) Spiegelungen am Auto, die du im Rasterisierer vergeblich suchen wirst.

    Mit dem VW-Polo hast du nur eine Monster Aufgabe gesucht, die auch Monster Hardware braucht.

    > Lies doch bitte erst mal das Standardwerk dazu:
    > "Computer Graphics - Principles and Practice",
    > anno 1991. Vieles von dem, was erst heute
    > praktisch zum Einsatz kommt wurde schon in diesem
    > Buch beschrieben.

    Das Argument vom "coder" hat ja nichts mit den Basis-Algorithmen zu tun. Das Problem ist, dass die Hardware, die rasterisierungsbasierte Algorithmen effizient unterstützt, wirklich schon 10 Jahre länger in großer Auswahl und unter großem Entwicklungsdruck verfügbar ist, wie die Hardware auf der sich vernünftig Raytracing-Algorithmen umsetzen lassen.

    Und wenn du schon den Foley nimmst, da sind die Kapitel, die sich mit der Paralellisierung von Rastergrafik beschäftigen viel ausführlicher und viel konkreter wie die, die sich mit der sich mit Ansätzen von Paralellisierung von Raytracing und Architekturen, die dafür gut geeignet sein könnten, beschäftigt. Warum? Weil's eben ein gutes Stück komplexer ist, und die optimale Kombination Hardware-Architektur+Algorithmus nicht so offensichtlich wie bei Rasterisierern ist.

    > [...] Die Qualität der Graphik
    > ergibt sich jedoch aus den Algorithmen die man zur
    > Beschreibung der Lichtinteraktion nutzt. Und für
    > diese Algorithmen spielt es keine Rolle, ob der
    > Parametervektor per Raytracing oder Rasterizing
    > ermittelt wurde.

    Doch! Visibilität ist ein sehr sehr großes Thema bei Sekundärstrahlen (die nicht gerade zu Punktlichtquellen gehen) und hat einen gigantischen Aufwand und großen Einfluss aufs Ergebnis!

  16. Re: Paradigmenwechsel...

    Autor: Wolfgang Draxinger 21.06.08 - 02:27

    me2 schrieb:

    > kolineare Lichtstrahlbündel.
    > Blah! Bis zu Wikipedia hast du es wohl nicht mehr
    > geschafft, denn dort wäre es gestanden ...
    > "Als Kohärenz (lat. cohaerere
    > „zusammenhängen“, Adjektiv kohärent)
    > bezeichnet man allgemein den nach außen
    > gerichteten Zusammenhang oder Zusammenhalt von
    > etwas."

    Sorry, ich hab das aus Physiker-Sicht gesehen. Kohärenz heißt für uns: Phasenzusammenhängend und zwar im wellentheoretischen Sinne. Wenn wir Strahlen als kohärent bezeichnen, dann dürfen die auch divergent sein, wichtig ist nur, dass über die betrachtete Welle die Phasen differnzierbar gekoppelt sind, sprich keine Sprünge auftreten und die Sache möglichst weit räumlich ausgedehnt ist.

    > Das hat überhaupt nix mit Wellenbetrachtungen zu
    > tun, sondern viel mehr mit gleicher Strahlrichtung
    > und "Abstand" der Strahlen von einander.

    Das wäre dann aber für einen Physiker kolinear im Falle von Vektoren bzw. parallel im Falle von Strahlen.

    > Nur weil du es dir nicht vorstellen kannst, heißt
    > das nicht, dass es nicht geht. Du machst es genau
    > umgekehrt. Du füllst einen Cache mit den
    > Strahlinformationen und holst dir nur ein Objekt,
    > bzw Dreieck jeweils dazu! Und das interessante
    > ist, du kannst nun mit der Brechstange hergehen
    > und dann alle Strahlen aus dem Bündel gegen dieses
    > eine Objekt testen (paralell auf der GPU), ohne
    > dass du einen weiteren Speicherzugriff hast. Und
    > das interessante ist, obwohl du ziemlich blind und
    > stupide sehr viel mehr Strahlen unnütz gegen das
    > Dreieck testest, die du normal gar nicht machen
    > würdest, bist du im Endeffekt schneller, weil die
    > Strahlen die mit dir mitlaufen, praktisch gratis
    > an die Objektdaten des Bündels kommen. Der
    > Rechenaufwand ist da nämlich nicht so gigantisch
    > im Vergleich dazu was das Speicherinterface
    > frist.

    Ok für prallele Strahlen mit nicht zu großem Abstand sehe ich das ja noch ein, aber bei divergenten Strahlen funktioniert das sicher auch nur in einem räumlich eng begrenzten Gebiet effizient.

    > Ja, super! Dir ist schon klar warum Shadow-Volumes
    > kaum benutzt werden? Das Ding skaliert direkt mit
    > der Anzahl der schattenwerfenden Objekte, mit der
    > Anzahl der Lichtquellen, und zusätzlich auch noch
    > mit deiner Bild-Auflösung. Das sind natürlich
    > optimale Bedingungen für größere Auflösungen,
    > feinere Geometrie, und mehr Lichtquellen. Und
    > außerdem siehste jedes Eckchen in deinem
    > Objektumriss im Schatten um so mehr.

    War ja auch nur ein Gegenbeispiel. Andererseits könnte man auch argumentieren, dass Shadow Maps auch nur eine Art von Raytracing sind (jedes Texel der Shadow-Map entspricht einem Lichtstrahl von der Lichtquelle ausgehend.

    Und dann wäre da ja auch noch Deferred Shading.

    > Natürlich, aber woran liegt das? Erstens, daran,
    > dass du mal volkommen Effekte, die dir gerade
    > nicht so gut ins Konzept passen, wie
    > beispielsweise korrekte Spiegelungungen und
    > Brechungen ausblendest, und dir an den
    > allermeisten Stellen ein "sieht glaubhaft aus"
    > reicht.

    Das habe ich so nicht gesagt! Was ich meinte war, dass das Gehirn beim flüchtigen Hinsehen - und gerade bei interaktiver Echtzeitgraphik sieht man nicht so genau hin - all das nicht so genau wahrnimmt.

    > Zeig mir zum Beispiel ein Autorennspiel,
    > in dem sich die anderen Fahrzeuge korrekt im Lack
    > spiegeln! Ganz einfacher Effekt und auch einfach
    > für Raytracing zum umsetzen. Aber du sprichst von
    > Realismus ...

    Das sich ein anderes Auto im Lack spiegelt ist einfach hinzubekommen: Einfach für jedes Auto eine individuelle Cube Map (für den Ursprungspunkt der Cube Map wäre das Ergebnis sogar dem Raytracing identisch) berechnen und verwenden. Um die Reflexion der Reflexion der Reflexion zu erfassen muss man das halt rekursiv durchkauen, wobei man da aber von Schritt zu Schritt die Auflösung erhöht um nicht zu viel Füllrate zu verplempern.

    Der wahre Knackpunkt und wirkliche Vorteil von Raytracing kommt in Fällen zum Vorschein, in denen ein Objekt sich selbst reflektiert, oder die Umgebung durch Mehrfachreflexion abgebildet wird. Der klassische Corner-Reflektor z.B. wäre mit Cube Maps eine wirklich harte Nuss.

    > Zweitens eben, dass die Rasterisierungsalgorithmen
    > sehr einfach und natürlich vom extremen
    > Geschwindigkeitsvorteil der Massenabfertigung
    > profitieren. Da liesen sich die auf der CPU
    > schnellen RT Algorithmen nicht so gut drauf
    > anpassen (zb. die Baumstrukturen), weil dafür
    > brauchst du meist wahlfreie Schreibzugriffe oder
    > mehr Freiheiten in den Shadern die erst in den
    > letzten Jahren auch erst effizient in die GPU
    > Hardware Einzug erhalten haben.

    Ja, aber bei Rasterizern ist das Problem bei wahlfreiem Schreibzugriff insbesondere darin begründet, dass immer wieder Zwischenstops zur Synchronisation der einzelnen Pipelines erfordert. Das war sogar vorher ein Problem, wo man nur lesen konnte: Jeder Texturzugriff musste erst mal von einem Fragment und seinen Nachbarfragmenten ausgeführt werden um an den Gradienten der Texturkoordinate zu kommen und darüber den MipMap-Level zu berechnen. Darum hatten ja die ersten GPUs mit Shader Model 2 die Möglichkeit zu gerade mal 4 Texturindirektionen.

    > Und ich sags auch gerne hier nochmal: Das ganze
    > ist kein "Entweder-Oder". Rasterisierung und
    > Raytracing lassen sich sehr gut auch kombinieren,
    > so dass man von beiden die Vorteile nutzen kann.

    Darauf wird's wohl hinauslaufen, ein Hybrides Modell: Eine Rasterizerstufe um überhaupt erst mal die primären Fragmente zu bestimmen, dann ein darauf aufbauendes Szenesetup. Dann eine approximierende Photon Mapping-Stufe für GI und schließlich von den bereits berechneten Fragmenten ausgehend eine Raytracing-Stufe um lokal Reflexionen und Refraktionen hinzubekommen. In's "Unendliche" tut's dann ja wieder eine Cube Map, wobei man diese mit dem selben Ansatz wie die lokale Szene rendern kann, nur eben für die Umgebung.

    Ich denke aber, wir stimmen darin überein, dass Raytracing alleine nicht die Magic Bullet ist, als die sie von einigen Leuten angepriesen wird.

  17. Re: Paradigmenwechsel...

    Autor: coder 21.06.08 - 09:41

    Wolfgang Draxinger schrieb:
    -------------------------------------------------------
    > Quatsch! Um mit Raytracing realistisch aussehende
    > Graphik zu erhalten muss man genauso viel Aufwand
    > treiben, wie bei Rasterizern. Die Mathematik
    > dahinter (Interaktion von Licht mit Materie) ist
    > in beiden Fällen exakt die selbe, der Unterschied
    > zwischen Raytracing und Rasterizing besteht
    > alleine darin, wie die Parameter für die
    > Berechnung ermittelt werden.
    >
    > Phong Shading sieht raytraced genauso künstlich
    > aus wie rasterized.

    Es hätte 'Quatsch:' nicht 'Quatsch!' heissen müssen. :)
    Was Du da sagst gilt bestenfalls für Primärstrahlen, und selbst bei denen hat man beim Raytracing Vorteile sobald man aufwändigere Effekte wie z.B. Bewegungsunschärfe oder Tiefenschärfe möchte. Dann geht es beim Rasterizing nämlich schon wieder mit fakes los.

    > > Das wird mit
    > Sicherheit dann auch
    > kleineren Entwicklern
    > ermöglichen Spiele zu
    > kreieren, die nicht von 90%
    > der potenziellen
    > Spielern ignoriert werden, weil
    > die Grafik
    > nicht ansprechend genug ist.
    >
    > Gute Graphik hat _nichts_(!) damit zu tun. Es gibt
    > 5 teils sehr gelungene OSS 3D-Engines, mit allen
    > Schikanen. Wenn man deiner Argumentation folgt
    > müsste es doch mittlerweile nur so von kommerziell
    > erfolgreichen Independent-Filmen wimmeln, denn
    > hochqualitative Kameras, Top-CGI-Effekte usw.
    > stehen mittlerweile eigentlich jedermann günstig
    > zur Verfügung.
    >
    > Ein gutes Spiel zu entwickeln ist vor allem eins:
    > Kunst. Man braucht kreative Leute, nicht nur
    > Programmierer und Techniker, sondern auch
    > Künstler, die ein gelungenes künstlerisches
    > Konzept entwickeln, Schreiber die eine tolle Story
    > liefern, Musiker die einen guten Soundtrack
    > hinbekommen, 3D-Artists die gute Geometrie
    > abliefern usw. Die Technik macht dabei nur einen
    > winzig kleinen Teil davon aus.


    Da hast Du mich missverstanden. Wovon ich spreche ist das man sich beim Raytracing weit weniger mit Limitationen rumschlagen muss und eben nicht schon bei so grundlegenden Dingen wie z.B. Schatten Probleme bekommt. Natürlich benötigt man immer noch Künstler, aber die können sich viel mehr auf ihren eigentlich Job konzentrieren, anstatt sich zu überlegen wie man mit der jeweiligen Rasterizing Engine nun diesen oder jenen Effekt faked.

    > Lies doch bitte erst mal das Standardwerk dazu:
    > "Computer Graphics - Principles and Practice",
    > anno 1991. Vieles von dem, was erst heute
    > praktisch zum Einsatz kommt wurde schon in diesem
    > Buch beschrieben.

    Schön, Du hast ein Buch über Raytracing. Ich hab sogar mehrere aus den Achzigern und meinen ersten Raytracer hab ich Ende der Achziger auf nem Amiga geschrieben.
    Tatsächlich ist die Idee Bilder per Raytracing auf dem Computer zu erzeugen sogar älter als die Idee das per Rasterizing zu machen. Ich verstehe nur nicht das Du den Unterschied zwischen ein paar Wissenschaftlern die sich mit der mathematischen Theorie beschäftigen, und Firmen die milliarden investieren um diese effizient in Hardware
    zu implementieren, nicht siehst.

    > Gute Graphik kommt nicht von selbst, da steckt
    > harte Forschung dahinter: Wie interagiert Licht
    > mit Materie (nicht in der Theorie, sondern was für
    > Effekte haben Materialien wie Holz, Marmor, Haut
    > in der Elektrodynamik), wie lassen sich die
    > Vorgänge mathematisch einfach beschreiben. Ohne
    > Kenntnis dieser Vorgänge sieht Raytracing genauso
    > chice aus.

    Ja, nur das ich mit Raytracing im Gegensatz zu Rasterizing wenigstens die Möglichkeit habe all die tollen Theorieen zu implementieren.

    > Beim Raytracing ist es nicht anders. Weiche
    > Schatten? Area Lights wären viel zu teuer, also
    > macht man einen Monte Carlo und Interpoliert die
    > Chose. Diffuse Global Illumination? Vorgeschobenes
    > Photon Mapping oder Radiosity, beides genauso
    > Fake.

    ?
    Natürlich kann man Area Lights undersamplen und dann interpolieren wenn alles andere zu teuer wäre. Nur je mehr Strahlen ich nutze, desto näher komme ich der Realität. Beim Rasterizing gibt es da nur (deutlich schlechtere) fakes. Außerdem fägst Du schon wieder mit naiven Implementationen an. Aber selbst mit so einer naiven Implementation sind gute Area Lights nicht annähernd so weit weg wie Du scheinbar glaubst. Und es gibt ne Menge Möglichkeiten das weiter zu beschleunigen, ohne zusätzliche Fehler einzubauen.

    Radiosity ist seit ner Ewigkeit überhohlt (Vielleicht mal wieder ein neues Buch über Ratracing kaufen?). Und mit Photon Mapping orientiert man sich direkt an dem was in der Realität geschieht. Gleichzeitig sind Photon Mapping und Raytracing so ähnlich, dass man die selben Funktionen/Hardware dafür nutzen kann. Das geht mit nem Rasterizer nicht.

    Vieles von dem was Rasterizing überhaupt erst halbwegs ordentlich aussehen lässt sind mit Raytracing! vorberechnete Texturen und ähnliches. Jetzt kommen wir langsam zu dem Punkt wo solche Berechnugen dynamisch möglich werden, und plötzlich ist das schlecht?


    > Der einzige Weg ganz ohne Fakes realistisch
    > aussehende Graphik hinzubekommen bestünde darin,
    > die Maxwell Geleichungen für die Szene numerisch
    > zu lösen. Die Datenmenge die aber dann anfallen
    > würde wäre astronomisch. Überschlagen wir das mal:
    > Wellenlänge von Licht ist Größenordnungsmäßig
    > 10^-9, für moderne Spiele möchte man Ausdehnungen
    > von wenigstens 10^3m in jeder Richtung, um das
    > numerisch lösen zu können muss man in
    > Zeitschritten rechnen in der das Licht höchstens
    > um eine Wellenlänge propagiert, also ~10^-9s/10^8
    > =~= 10^-17s und man braucht so viele
    > Rechenschritte, dass das Licht auch die Chance hat
    > mindestens 10 mal die Szene komplett von einem
    > Ende an's andere zu durchlaufen. Der
    > Speicherbedarf ist also (10^3)^3/(10^-9)^3 = 10^9
    > * 10^27 = 10^36 zeitabhängige Gitterpunkte. Pro
    > Gitterpunkt sind E-Feld und Poynting-Vektor zu
    > speichern (das B-Feld und den Wellenvektor kann
    > man daraus berechnen). Das wäre dann jeweils ein
    > 4-Vektor (damit das korrekt ist, _muss_ man
    > relativistisch rechnen), also 8 Elemente und die
    > dann natürlich mit doppelter Genauigkeit, damit
    > sich bei so vielen Rechenschritten der Fehler
    > möglichst klein bleibt, macht also ca. 2*10^37
    > Bytes Speicherbedarf...
    >
    > Nicht zeitabhängig, da von den Szenedaten
    > vorgegeben sind Dielektrizität, Suzeptibilität,
    > Ladungsdichte, Dipolterme und
    > Nichtlinearitätsterme, es reicht, diese mit der
    > Auflösung der Geometrie zu speichern, also sagen
    > wir mal millimetergenau. Macht immer noch
    > (10^3)^3/(10^-3)^3 = (10^6)^3 = 10^18
    > Gitterpunkte, die aber dynamisch erzeugt werden
    > müssen.
    >
    > Um eine Frame berechnen müssen ~ (10*10^3)/(10^8 *
    > 10^-17) = 10^4 / 10^-9 = 10^15 Schritte
    > durchgerechnet werden. Insgesamt müsste also pro
    > Frame eine Datenmenge von ~ 10^15 * 10^37 = 10^52
    > Bytes durch die Gegend kopiert werden um ein
    > einziges Frame völlig ohne Fakes zu berechnen. Ich
    > will mal den Rechner sehen, der das in annehmbarer
    > Zeit packt. Da hilft selbst das Mooresche Gesetz
    > nicht mehr viel.
    >

    OMG! Willst Du damit sagen das, weil wir die Realität nicht 100% simulieren können, können wir auch gleich beim schlechtest möglichen System bleiben können? Raytracing ist nicht das Ende des Weges, aber zumindest ein Schritt in die richtige Richtung.


  18. Re: Paradigmenwechsel...

    Autor: coder 21.06.08 - 10:23

    Wolfgang Draxinger schrieb:
    -------------------------------------------------------

    > Das sich ein anderes Auto im Lack spiegelt ist
    > einfach hinzubekommen: Einfach für jedes Auto eine
    > individuelle Cube Map (für den Ursprungspunkt der
    > Cube Map wäre das Ergebnis sogar dem Raytracing
    > identisch) berechnen und verwenden. Um die
    > Reflexion der Reflexion der Reflexion zu erfassen
    > muss man das halt rekursiv durchkauen, wobei man
    > da aber von Schritt zu Schritt die Auflösung
    > erhöht um nicht zu viel Füllrate zu verplempern.

    Nur das es besch*** aussieht, wenn man doch mal genauer hinschaut. Denn sobald sich zwei Autos näher als ein paar meter kommen werden die Verzerrungen durch diesen fake derart stark, dass das nichts! mehr mit der Realität zu tun hat.


    > Darauf wird's wohl hinauslaufen, ein Hybrides
    > Modell: Eine Rasterizerstufe um überhaupt erst mal
    > die primären Fragmente zu bestimmen, dann ein
    > darauf aufbauendes Szenesetup. Dann eine
    > approximierende Photon Mapping-Stufe für GI und
    > schließlich von den bereits berechneten Fragmenten
    > ausgehend eine Raytracing-Stufe um lokal
    > Reflexionen und Refraktionen hinzubekommen. In's
    > "Unendliche" tut's dann ja wieder eine Cube Map,
    > wobei man diese mit dem selben Ansatz wie die
    > lokale Szene rendern kann, nur eben für die
    > Umgebung.
    >
    > Ich denke aber, wir stimmen darin überein, dass
    > Raytracing alleine nicht die Magic Bullet ist, als
    > die sie von einigen Leuten angepriesen wird.
    >

    Hybrides Rendering ist bestenfalls eine (unschöne) Übergangslösung. Der wirklich einzige Vorteil von Rasterizing gegenüber Raytracing ist die Performance für das was beim Raytracing Primärstrahlen währen. Zugegeben, im Moment ist das noch der entscheidende Punkt, aber schon jetzt dominieren eigentlich die Shader und Funktionen für die Rasterizing eigentlich nicht geschaffen ist (Schatten, Cube Mapping...) die Renderzeit bei High-End Grafik.
    Nur da es leider noch keine 'State of the Art' Hardware-Beschleunigung für Raytracing gibt, gibt es momentan keine Alternative zu Rasterizing.
    Versteht mich nicht falsch, es gibt Situationen in denen Rasterizing weit effizienter als Raytracing ist, und immer sein wird. Es macht nur
    irgendwann keinen Sinn mehr beide Verfahren zu nutzen, wenn die Renderzeit von Funktionen dominiert wird, für die das Rasterizing nicht effizient ist.

    (Und bitte jetzt nicht wieder die Performance einer naiven Raytracing Implementation in Software, die sich bemüht eine möglichst korrektes Resultat abzuliefern, mit einem Rasterizing fake auf hochgezüchteter Hardware vergleichen)

  19. Re: Paradigmenwechsel...

    Autor: Wolfgang Draxinger 21.06.08 - 11:36

    coder schrieb:

    > Schön, Du hast ein Buch über Raytracing. Ich hab
    > sogar mehrere aus den Achzigern und meinen ersten
    > Raytracer hab ich Ende der Achziger auf nem Amiga
    > geschrieben.

    Der Foley ist nicht einfach nur ein Buch über Raytracing. Tatsächlich wäre es darüber ein recht bescheidenes Werk. Statt dessen wird in diesem Buch so ziemlich alles beschrieben (in einem mathematischen Sinne), was man sich bis zum Zeitpunkt der Veröffentlichung sich zum Thema Graphik überlegt hat. Und zwar nicht vom Standpunkt der Echtzeitfähigkeit und Performanz aus, sondern von der Theorie aus gesehen.

    > Tatsächlich ist die Idee Bilder per Raytracing auf
    > dem Computer zu erzeugen sogar älter als die Idee
    > das per Rasterizing zu machen.

    Weiß ich doch selber.

    > Ja, nur das ich mit Raytracing im Gegensatz zu
    > Rasterizing wenigstens die Möglichkeit habe all
    > die tollen Theorieen zu implementieren.

    Das kann man, wenn man es clever anstellt auch mit Rasterizern.

    > Radiosity ist seit ner Ewigkeit überhohlt
    > (Vielleicht mal wieder ein neues Buch über
    > Ratracing kaufen?).

    Radiosity ist z.B. eines der Dinge die im Foley nicht direkt angesprochen wurden. Damals war man schon froh, direkte Illumination halbwegs korrekt hinzubekommen.

    > Und mit Photon Mapping
    > orientiert man sich direkt an dem was in der
    > Realität geschieht.

    > Gleichzeitig sind Photon
    > Mapping und Raytracing so ähnlich, dass man die
    > selben Funktionen/Hardware dafür nutzen kann. Das
    > geht mit nem Rasterizer nicht.

    Sag mal, liest Du meine Beiträge eigentlich? Ich schrieb doch klipp und klar, dass Photon Mapping eine Art "umgekehrtes Raytracing von der Lichtquelle ausgehend" ist.

    > Vieles von dem was Rasterizing überhaupt erst
    > halbwegs ordentlich aussehen lässt sind mit
    > Raytracing! vorberechnete Texturen und ähnliches.

    Es mag vielleicht verwundern, aber ich habe festgestellt, dass Texturen weniger zur Qualität beitragen als man vermuten könnte. Ich bastel ja mit einigen Spetzeln an einem Spiel (ich bau die 3D-Engine und alles was dazu gehört --- und ich muss zugeben, dass mein allererster Versuch, eine interaktive 3D-Engine zu bauen ein Echtzeit-Raytracer hätte werden sollen. Damals, auf dem Pentium2 kam die Sache aber nie über 0.5FPS hinaus - ich habe also gewisse Erfahrungen was das Basteln von Raytracern angeht, allerdings altersbedingt erst ab Mitte der 90er, d.h. genauer gesagt ab 1995 als ich noch "nur" einen 486-SX hatte). Und irgendwann so vor 2 Jahren hatte ich mal bei einem Build aus Versehen den Code, der die Texturen (Albedo, Normal, Specular, Aniso/BRDF) aus den Dateien lädt "abgeschossen", so dass nur noch die dynamisch berechneten Texturen (Cube Maps, Illumination Maps (Subsampletes Photon Mapping BTW), Ambient Occlusion Maps (ja ich weiß, AO ist bitterster Fake)) übrig blieben: Teile der geladenen Szene sahen absolut schrottig aus, nämlich das Zeug, wo mit wenigen Polygonen modelliert wurde. Dort aber wo die Geometrie sehr detailiert ausgeführt war/ist sieht es selbst ohne Texturen, einfach nur diffus beleuchtet immer noch sehr gut aus => Ich habe diesen Rendermodus fest in die Engine eingebaut, für ähnliche Zwecke wie bei Valve die Orange-Maps verwendet werden.

    > Jetzt kommen wir langsam zu dem Punkt wo solche
    > Berechnugen dynamisch möglich werden, und
    > plötzlich ist das schlecht?

    Nein, ich wäre der letzte, der sich komplett gegen Raytracing stellt. Ich habe nur etwas gegen Leute, die das Verfahren als Magic Bullet und die ultimative Lösung ansehen.

    > OMG! Willst Du damit sagen das, weil wir die
    > Realität nicht 100% simulieren können, können wir
    > auch gleich beim schlechtest möglichen System
    > bleiben können?

    Nein! Es ging mir darum zu zeigen, dass Raytracing genauso ein Fake ist, wie Rasterizing auch. Nur mit dem Unterschied, dass Raytracing mehr Physik ist (Simulation von Strahlen), während Rasterizing eher Mathematik ist (projektive Abbildung von Geometrie). Fake ist aber beides. Und zumindest im Falle von Primärstrahlen gibt es keinen Unterschied im Ergebnis von Rasterizing und Raytracing. Erst die Sekundär- und Tertiärstrahlen heben Raytracing hervor.

    BTW: In meiner 3D-Engine steckt sogar ein kleiner Raytracer, allerdings rechnet der pro Frame nur so um die 2000 Strahlen (kann man einstellen, klar).

    Das ich eigentlich aus der Raytracing-Ecke komme sieht man auch daran, wie Geometrie in meiner 3D-Engine verwaltet wird: CSG, sprich boolesche Operationen auf einfache Primitive. Eigentlich eine Darstellung wie sie eher Raytracer verwenden.

    Ich kenne halt beide Verfahren und deren Grenzen sehr genau.

    Und wenn jemand behauptet, Raytracing sei die Magic Bullet, die endlich mal auch den kleinen Entwicklern die Chance gibt, Top-Graphik zu zaubern, bleibt mir nichts anderes, als diese Aussage als Mumpitz zu bezeichnen. Top-Graphik hat nichts mit dem Grundverfahren, sondern mit dem kreativen Einsatz der _aktuell_ zur Verfügung stehenden Möglichkeiten zu tun.

  20. Re: Paradigmenwechsel...

    Autor: Wolfgang Draxinger 21.06.08 - 12:49

    Wolfgang Draxinger schrieb:

    > Radiosity ist z.B. eines der Dinge die im Foley
    > nicht direkt angesprochen wurden. Damals war man
    > schon froh, direkte Illumination halbwegs korrekt
    > hinzubekommen.

    Ich korrigiere mich: Es werden genau 10 Seiten darauf aufgewendet.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Sky Deutschland GmbH, Unterföhring bei München
  2. Stadtwerke München GmbH, München
  3. Energie Südbayern GmbH, München
  4. über duerenhoff GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 299,90€
  2. (u. a. Crysis 3 für 4,99€, Battlefield 4 für 4,99€, Titanfall 2 für 4,99€)
  3. (u. a. 3er Pack Lüfter LL120 RGB für 102,90€, Crystal 680X RGB Gehäuse für 249,90€)
  4. (u. a. Switch + Just Dance 2020 für 339,98€, Switch + FIFA 20 für 336,90€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Nitropad im Test: Ein sicherer Laptop, der im Alltag kaum nervt
Nitropad im Test
Ein sicherer Laptop, der im Alltag kaum nervt

Das Nitropad schützt vor Bios-Rootkits oder Evil-Maid-Angriffen. Dazu setzt es auf die freie Firmware Coreboot, die mit einem Nitrokey überprüft wird. Das ist im Alltag erstaunlich einfach, nur Updates werden etwas aufwendiger.
Ein Praxistest von Moritz Tremmel und Sebastian Grüner

  1. Nitropad X230 Nitrokey veröffentlicht abgesicherten Laptop
  2. LVFS Coreboot-Updates sollen nutzerfreundlich werden
  3. Linux-Laptop System 76 verkauft zwei Laptops mit Coreboot

Alphakanal: Gimp verrät Geheimnisse in Bildern
Alphakanal
Gimp verrät Geheimnisse in Bildern

Wer in Gimp in einem Bild mit Transparenz Bildbereiche löscht, der macht sie nur durchsichtig. Dieses wenig intuitive Verhalten kann dazu führen, dass Nutzer ungewollt Geheimnisse preisgeben.


    Geforce Now im Test: Nvidia nutzt einzigartige CPU und GPU
    Geforce Now im Test
    Nvidia nutzt einzigartige CPU und GPU

    Wer mit Nvidias Geforce Now spielt, bekommt laut Performance Overlay eine RTX 2060c oder RTX 2080c, tatsächlich aber werden eine Tesla RTX T10 als Grafikkarte und ein Intel CC150 als Prozessor verwendet. Die Performance ist auf die jeweiligen Spiele abgestimmt, vor allem mit Raytracing.
    Ein Test von Marc Sauter

    1. Cloud Gaming Activision Blizzard zieht Spiele von Geforce Now zurück
    2. Nvidia-Spiele-Streaming Geforce Now kostet 5,49 Euro pro Monat
    3. Geforce Now Nvidias Cloud-Gaming-Dienst kommt noch 2019 für Android

    1. Elenion Technologies: Nokia übernimmt US-Experten für Siliziumphotonik
      Elenion Technologies
      Nokia übernimmt US-Experten für Siliziumphotonik

      Nokia kauft ein New Yorker Unternehmen, das im Bereich Siliziumphotonik aktiv ist. Die Produkte sind für 5G-, Cloud- und Rechenzentrumsnetzwerke einsetzbar, es geht um die tiefere Integration bei der Umwandlung von Licht zu elektrischen Signalen.

    2. Spielestreaming: Google Stadia funktioniert auch mit Smartphones von Samsung
      Spielestreaming
      Google Stadia funktioniert auch mit Smartphones von Samsung

      Der Spielestreamingdienst Stadia von Google unterstützt künftig auch einige Smartphones von Razer und Asus, vor allem aber viele neuere Geräte von Samsung - inklusive der gerade erst vorgestellten Galaxy-S20-Reihe.

    3. EU-Kommission: Zehn Datenräume für die digitale Zukunft Europas
      EU-Kommission
      Zehn Datenräume für die digitale Zukunft Europas

      Die EU-Kommission unter Ursula von der Leyen will mit einer neuen Digitalstrategie europäische Daten besser nutzbar machen. Wie die vollmundigen Ankündigungen konkret umgesetzt werden, ist aber noch offen.


    1. 19:08

    2. 17:21

    3. 16:54

    4. 16:07

    5. 15:43

    6. 15:23

    7. 15:00

    8. 14:45