"Raytracing in Spielen" von Daniel Pohl

[Coda]

OpenGL ist auch um einiges flexibler als D3D und somit für die Raytracing Experimente bestens geeignet.
OpenGL ist nicht flexibler als D3D und wird von denen auch nicht verwendet. Es ist ein reiner Software-Renderer.

[Gast]

Rein rhetorisch gefragt, warum wurde deiner meinung nach ein OpenGL Titel genommen?

[tombman]

Na ganz toll. 24 Cpu Kerne und gerade mal 30fps auf 1280x720.
Ein aktuelles Sys mit einer CPU+ GPU schafft wahrscheinlich das 10fache an fps und kostet 1/10.

Also wären wir bei Faktor 100. Und Faktor 100 will Intel bis wann aufholen? 2012?

[Coda]

Rein rhetorisch gefragt, warum wurde deiner meinung nach ein OpenGL Titel genommen?
Weil er sich vorher schon mit id Software Spielen beschäftigt hat und es eine große Community gibt die sich mit dem Rendern von Quake-Levels beschäftigt. Es ist sehr einfach an Infos bis Quake 4 zu kommen wie man die Daten laden muss. Bei Quake Wars dürfte es ähnlich sein.

Die Unreal-Dateiformate sind um einiges komplexer z.B. Dort gibt's bisher nur einen Versuch den ich kenne. Quake verwendet ja auch ein simples ZIP-Format für die Packages.

Bei Crysis kommt man zwar an die Leveldaten ran, weil die Packages auch ZIP sind, aber ohne Dokumentation wird's da auch sehr schwer. Zudem hat die Engine ein Lichtsystem das man nicht mal so eben neu implementiert.

[Gast]

Es ist sehr einfach an Infos bis Quake 4 zu kommen wie man die Daten laden muss. Bei Quake Wars dürfte es ähnlich sein.

Warum ist das nur so...
Kleiner tipp, fängt mit O and und hört mit L auf.

[Coda]

Das hat mit OpenGL NICHTS zu tun. Du kannst jegliches Levelformat in Direct3D oder OpenGL laden. JEDES.

Hör auf Bullshit zu verzapfen.

[betasilie]

Woher hat er eigentlich den Code von Quake 4 und Quake Wars? Haben die eine Lizenz von id?
Klar haben die eine Lizenz. Zum einen wird es nicht am Geld scheitern bei intel, zum anderen wird id wahrscheinlich ein eigenes Interesse haben, wenn eine Firma wie Intel an Echtzeitraytracern arbeitet mit deren Engine. Auch wenn Raytracing noch nicht greifbar nahe ist, werden Studios wie id sich natürlich auf den Tag vorbereiten, an dem zumindest Raytracing zum Teil zum Einsatz kommt in Spielen und da kann es nicht schaden die eigene Technologie als Plattform zur Verfügung zu stellen.

[Nasenbaer]

Na ganz toll. 24 Cpu Kerne und gerade mal 30fps auf 1280x720.
Ein aktuelles Sys mit einer CPU+ GPU schafft wahrscheinlich das 10fache an fps und kostet 1/10.

Also wären wir bei Faktor 100. Und Faktor 100 will Intel bis wann aufholen? 2012?
Bei den Geschwindigkeitsangaben kam ich auch ins grübeln. Aber man muss ja auch sehen, dass das ein Forschungsprojekt ist und man nicht das konkrete Ziel hat bald Raytracing einzusetzen - jedenfalls nicht mit der heute üblichen CPU+GPU Hardware sondern wohl eher mit ihrem Larabee-Zeugs.

[betasilie]

Warum ist das nur so...
Kleiner tipp, fängt mit O and und hört mit L auf.
Verstehst Du nicht, dass OpenGL eine Rasterizer API ist? Verstehst Du nicht, dass die keine asterizer API brauchen? Sprich D3D und OpenGL sind durch Intels Softwarerendering ersetzt worden.

[Ric]

Verstehst Du nicht, dass OpenGL eine Rasterizer API ist? Verstehst Du nicht, dass keine GPU-API vorhanden ist? Sprich D3D und OpenGL sind durch Intels Softwarerendering ersetzt worden.


Ich glaube der Kollege Gast zieht einen unzulässigen Schluss von "benutze OpenGL" zum "bekomme vernünftige Dokumentation".

[betasilie]

Ich glaube der Kollege Gast zieht einen unzulässigen Schluss von "benutze OpenGL" zum "bekomme vernünftige Dokumentation".
Coda hat aber doch schon erklärt, wo die Einfacheit der Quake-Engine liegt und das die API nichts damit zu tun hat, weil sie ersetzt wird von Intel. Und auch so sollte einem doch klar sein, dass man keine Rasterizer API benutzt zum raytracen. ;)

[Gast]

Das hat mit OpenGL NICHTS zu tun. Du kannst jegliches Levelformat in Direct3D oder OpenGL laden. JEDES.

Hör auf Bullshit zu verzapfen.
Flipp doch nicht gleich aus, nur weil jemand nicht deiner Meinung ist.
Als ob es nur um das Levelformat gehen würde, tut es aber nicht.

[Coda]

Als ob es nur um das Levelformat gehen würde, tut es aber nicht.
Soso. Dann erklär mal technisch um was "es geht" anstatt hier nur Grütze von dir zu geben. "OpenGL ist flexibler" ist ein Nullargument. Und noch dazu ein komplett falsches.

Wie ein Spiel seine Leveldaten speichert hat 0,0 damit zu tun was für eine API zum rendern verwendet wird. Gar nichts.

[deekey777]

Klar haben die eine Lizenz. Zum einen wird es nicht am Geld scheitern bei intel, zum anderen wird id wahrscheinlich ein eigenes Interesse haben, wenn eine Firma wie Intel an Echtzeitraytracern arbeitet mit deren Engine. Auch wenn Raytracing noch nicht greifbar nahe ist, werden Studios wie id sich natürlich auf den Tag vorbereiten, an dem zumindest Raytracing zum Teil zum Einsatz kommt in Spielen und da kann es nicht schaden die eigene Technologie als Plattform zur Verfügung zu stellen.

Nur nutzt id tech6 gerade kein Raytracing, sondern Voxelzeug, etwas Ray-Casting, Rasterization, Polygone...
http://s08.idav.ucdavis.edu/olick-current-and-next-generation-parallelism-in-games.pdf
Sprich: Sie wollen kein Ray-Tracing.

Warum aber immerwieder Crysis erwähne: Das Spiel besteht nicht nur aus Licht und Schatten und paar Spiegelungen. Ob jetzt die Szene physikalisch korrekt ausgeleuchtet ist, ist mir als Spieler egal (spiele aktuell STALKER SC: SSAO ist an, aber auch ohne dieses scheint das Spiel richtig ausgeleuchtet zu sein). Es kommt heute in einem Spiel wie Crysis auf realistische Oberfflächen an (siehe Ice-Level). Das sollen die RT-Pros zuerst zeigen, denn die Darstellung realtistischer Oberflächen ist unabhängig davon, ob man RT oder Rasterization nutzt, die Problematik ist die gleiche.

[Coda]

Crysis hat eine auch physikalisch recht realistische Ausleuchtung durch das Atmosphärenmodell. Was ihnen noch fehlt ist das indirekte Licht, was sie durch Ambient Occlussion vortäuschen.

So viel gefaked wird da also gar nicht. Im Gegenteil, nichts ist im Moment näher dran an der Realität was das angeht.

[Nasenbaer]

Was ihnen noch fehlt ist das indirekte Licht, was sie durch Ambient Occlussion vortäuschen.
Und genau das lässt sich mit Raytracing auch nicht leichter lösen. Darum verstehe ich auch nicht warum man jetzt mit Zwang Raytracing nutzen will. Vielleicht ein wenig für Reflektionen und Refraktionen aber sonst kann man IMO auch nicht viel mehr mit Whitted Raytracing anfangen.

[betasilie]

Nur nutzt id tech6 gerade kein Raytracing, sondern Voxelzeug, etwas Ray-Casting, Rasterization, Polygone...
http://s08.idav.ucdavis.edu/olick-current-and-next-generation-parallelism-in-games.pdf
Sprich: Sie wollen kein Ray-Tracing.
Ich meinte auch eher langfristig - also 5-10 Jahre. Oder meinst Du es wird niemals Raytracing in Spielen geben, wenn auch nur Hybrid?

[Coda]

Also reines Raytracing auf Polygongeometrie halte ich für sinnfrei. Auf Voxel ist es schon wieder was anderes.

[aths]

So viel gefaked wird da also gar nicht. Im Gegenteil, nichts ist im Moment näher dran an der Realität was das angeht.Deutsch: gefakt. Mit immer komplexeren Modellen und Welten könnte es mal günstiger kommen, die Effekte näherungsweise zu berechnen anstatt gut zu faken.
Also reines Raytracing auf Polygongeometrie halte ich für sinnfrei. Auf Voxel ist es schon wieder was anderes.Wenn die Rechenleistung bald da ist, wäre die Engine aus einem Guss und man erspart sich Hybridansätze.

Ich bin im Innersten Raytracing-Anhänger, da man beim Rastern den Overdraw hat. Pro Pixel die Farbe zu bestimmen halte ich für "intelligenter" als vom Dreieck zum Pixel zu kommen.

[Coda]

Deutsch: gefakt. Mit immer komplexeren Modellen und Welten könnte es mal günstiger kommen, die Effekte näherungsweise zu berechnen anstatt gut zu faken.
Nein kein Fake. Sie verwenden physikalische Formeln dafür.

Wenn die Rechenleistung bald da ist, wäre die Engine aus einem Guss und man erspart sich Hybridansätze.
Die Rechenleistung wird nie "da" sein, weil Rasterisierung immer schneller sein wird für den "First Hit". Zudem hat man bei Raytracing stets das Problem der dynamischen Geometrie.

[deekey777]

Also reines Raytracing auf Polygongeometrie halte ich für sinnfrei. Auf Voxel ist es schon wieder was anderes.
Wie willst du dann solche Diagramme (http://www.computerbase.de/artikel/software/2007/bericht_raytracing_spielen/3/) verkaufen?

beta, selbst wenn die Rechenleistung von Heim-PCs 20-30 TFLOPs erreichen, werden sich die eigentlichen Problemzonen nicht ändern: Es sind realiätsnahe Oberflächen und weniger perfekte Spiegelungen.
Schaue dir die Human-Head-Demo von Nvidia an oder Crysis' Ice-Level (ja, schonwieder Crysis). Solche Sachen wie Subsurface-Scattering, realistisches Fehl, realistischer Rost, Holz, nasse Oberflächen usw. sind für den Spieler deutlich interessanter.

[Coda]

Wie willst du dann solche Diagramme (http://www.computerbase.de/artikel/software/2007/bericht_raytracing_spielen/3/) verkaufen?
Meinst du das Linear- vs. Log-Diagramm? Das ist praktisch aus vielerlei Gründen so nicht haltbar.

[deekey777]

Meinst du das Linear- vs. Log-Diagramm? Das ist praktisch aus vielerlei Gründen so nicht haltbar.
Aber es hat sich im Kopf festgebrannt.

In einer TV-Show zu KillZone 2 erwähnte irgendjemand, dass sie "Ray-Tracing" für die Darstellung von Einschusslöchern nutzen, damit diese nicht so flach wirken: Jetzt denken die "Kleinen", KillZone 2 nutzt Ray-Tracing und zwar volles Programm.

[Krishty]

Crysis hat eine auch physikalisch recht realistische Ausleuchtung durch das Atmosphärenmodell. Was ihnen noch fehlt ist das indirekte Licht, was sie durch Ambient Occlussion vortäuschen.Was genau meinst du? Den Himmel oder die Aerial Perspective? Beides ist imho eher „physikalisch orientiert“ als „physikalisch recht realistisch“ und eine etwa gleichwertige Optik bekommt man auch mit Skyboxes und exponentiellem Nebel hin.

Gruß, Ky

[Coda]

Was genau meinst du? Den Himmel oder die Aerial Perspective? Beides ist imho eher „physikalisch orientiert“ als „physikalisch recht realistisch“ und eine etwa gleichwertige Optik bekommt man auch mit Skyboxes und exponentiellem Nebel hin.
http://ati.amd.com/developer/siggraph06/Wenzel-Real-time_Atmospheric_Effects_in_Games.pdf
Distribute computation over several frames
– Each update takes several seconds to compute
Das bekommst du ganz sicher nicht so einfach mit einer Skybox und exponentiellem Nebel hin. Und schon gar nicht dynamisch.

In einer TV-Show zu KillZone 2 erwähnte irgendjemand, dass sie "Ray-Tracing" für die Darstellung von Einschusslöchern nutzen, damit diese nicht so flach wirken: Jetzt denken die "Kleinen", KillZone 2 nutzt Ray-Tracing und zwar volles Programm.
Natürlich. Deshalb stinkt es mir ja immer so.

[Krishty]

http://ati.amd.com/developer/siggraph06/Wenzel-Real-time_Atmospheric_Effects_in_Games.pdf

Das bekommst du ganz sicher nicht so einfach mit einer Skybox und exponentiellem Nebel hin. Und schon gar nicht dynamisch.Danke für den Link, die Paper sind immer wieder interessant.

Die mehreren Sekunden Berechnungszeit beziehen sich auf den Szenenhintergrund (das, was sonst die Skybox/-dome ist). Exakt wie bei einer abfotografierten Skybox wird dort angenommen, dass der Himmel unendlich weit weg und der Beobachter immer auf Nullhöhe ist. Damit fällt schonmal ein Großteil der Dynamik weg.

Worauf ich hinaus möchte ist, dass man nun statt der Rechnerei auch einfach 12, 24 oder noch mehr von einem klaren Himmel abfotografierte Skyboxes als Hintergrund hätte benutzen können (z.B. mit Blending, wie S.T.A.L.K.E.R. es macht). Vom Standpunkt des Realismus her – und darum geht es hier ja, soweit ich das mitbekommen habe – wären solche Fotos immer realistischer als das, was mir der Algorithmus ausspuckt (zumal solche Berechnungen, wenn man fast fotorealistische Ergebnisse erzielen möchte, eher Stunden dauern als Sekunden).

Nur weil man jetzt etwas auf Physik stützt, das man vorher abfotografiert hat, heißt das nicht unbedingt dass das Spiel damit besser, realistischer oder physikalisch korrekter ausgeleuchtet wird.

Würde man nun die Himmelsfarbe direkt zur Beleuchtung nutzen (z.B. indem man in einer Cubemap nachschlägt, welches Himmelslicht eine Oberfläche mit einer bestimmten Orientierung erreicht) und das nicht mehr annähern, wäre das schon ein großer Schritt. Das ist allerdings so eng mit Global Illumination verwoben, dass das ohne viel Fake nicht realisierbar wäre (vielleicht arbeitet Crysis abgesehen von Ambient Occlusion schon in dieser Richtung, da kennst du dich besser aus), und damit wären wir wieder dabei, dass ich dir mit dem indirekten Licht voll zustimme. Mit dem Atmosphärenmodell hat das aber nichts zu tun, eher damit, wie man dessen Ergebnise weiterverwendet.

[Nasenbaer]

Wobei sicher auch noch einiges an Optimierungspotential im ihrer Raytracing-Engine steckt. Ich weiß nicht wie clever die das machen aber man kann ja auch LightMaps nehmen für statische Geometrie um für diese die Schattenberechnung in nen Preprozess auszulagern.
Oder bspw. ein LOD-Modell für Reflektionen: Wenn das spiegelnde Object weit entfernt ist, was man ja leicht über die Ray-Länge ermittelt, kann man die Rekursionstiefe verginern oder sogar auf CubeMaps zurückschalten.
Das gibt es sicher noch weitere Ideen, die man da umsetzen könnte.

[Coda]

Die mehreren Sekunden Berechnungszeit beziehen sich auf den Szenenhintergrund (das, was sonst die Skybox/-dome ist).
Ist mir bewusst.

Exakt wie bei einer abfotografierten Skybox wird dort angenommen, dass der Himmel unendlich weit weg und der Beobachter immer auf Nullhöhe ist. Damit fällt schonmal ein Großteil der Dynamik weg.
Dürfte für Spiele aber kaum von Belang sein, oder? In Tälern verwendet Crysis dafür dann Fog-Volumes.

Worauf ich hinaus möchte ist, dass man nun statt der Rechnerei auch einfach 12, 24 oder noch mehr von einem klaren Himmel abfotografierte Skyboxes als Hintergrund hätte benutzen können (z.B. mit Blending, wie S.T.A.L.K.E.R. es macht).
Ich denke nicht. Der Aufwand den Crytek treibt dürfte um einiges größer sein und beeinflusst eben nicht nur die Skybox:
http://www.mental-asylum.de/files2/crysistimeofday.png

Vom Standpunkt des Realismus her – und darum geht es hier ja, soweit ich das mitbekommen habe – wären solche Fotos immer realistischer als das, was mir der Algorithmus ausspuckt (zumal solche Berechnungen, wenn man fast fotorealistische Ergebnisse erzielen möchte, eher Stunden dauern als Sekunden).
Für die restliche Szenenaufleuchtung ist das kaum der Fall. Vor allem weil die Fotos eher nicht HDR sind.

Würde man nun die Himmelsfarbe direkt zur Beleuchtung nutzen (z.B. indem man in einer Cubemap nachschlägt, welches Himmelslicht eine Oberfläche mit einer bestimmten Orientierung erreicht) und das nicht mehr annähern, wäre das schon ein großer Schritt.
AFAIK tut Crysis das

Das sieht man auch ganz deutlich im Editor wenn man die Time of Day ändert. Es wird zuerst zwar schon das Licht geändert, aber erst nachdem der Sykdome neu berechnet wurde stimmt es dann komplett wieder.

[Krishty]

Dürfte für Spiele aber kaum von Belang sein, oder? In Tälern verwendet Crysis dafür dann Fog-Volumes.Wenn diese Dynamik nicht von Belang ist, ist sie auch kein Gegenargument. Und auch für Täler verwendet Crysis (richtigerweise) ebenfalls die Himmelsfarbe (siehe „Combining Sky Light and Fog“), also hätte eine Skybox auch darauf positiven Einfluss.

Ich denke nicht. Der Aufwand den Crytek treibt dürfte um einiges größer sein und beeinflusst eben nicht nur die Skybox:
http://www.mental-asylum.de/files2/crysistimeofday.pngWenn man solche Sachen wie die Sonnenfarbe von Hand eingeben muss, ist der Schritt in Richtungen physikalischen Realismus Null. Die Sonnenfarbe müsste man aus den Formeln ableiten, mit denen man die Atmosphäre rendert – letzten Endes müsste man alles, von der Farbe des Himmels bei Nacht bis zur Nebeldichte aus Gegebenheiten wie Tageszeit, Luftfeuchtigkeit, etc ableiten. Da halte ich mich aber zurück, weil ich mit dem Editor nicht gearbeitet habe.

Für die restliche Szenenaufleuchtung ist das kaum der Fall. Vor allem weil die Fotos eher nicht HDR sind.Leider hat sich die Skybox in den letzten Jahren nicht in dem Maße weiterentwickelt wie es ihr möglich gewesen wäre. Dass die meisten Entwickler immernoch lieber mit ihrer Digicam JPEGs schießen als präzise Arbeiten durchzuführen heißt nicht, dass das Konzept nicht aufgeht.

[pest]

Die Sonnenfarbe müsste man aus den Formeln ableiten, mit denen man die Atmosphäre rendert

hast du die Formeln (in dem Paper) auch nur ansatzweise verstanden?

[Krishty]

hast du die Formeln (in dem Paper) auch nur ansatzweise verstanden?Ja. Die Farbe der Sonne ist sogar einfacher zu bestimmen, als du denkst – wenn man, wie in Crysis’ Modell, von Nullhöhe ausgeht ist es nurnoch ein Klacks.

Der Punkt wird eher sein, dass es für die Level-Artists einfacher ist, die Sonnenfarbe abends auf Rot umzustellen als die Konzentration von Partikeln bestimmter Größen neu einzugeben (und schneller zu berechnen ist es auch), wenn sie einen stimmungsvollen Sonnenuntergang entwerfen möchten. Aber der Realismus geht dann eben flöten.

[pest]

wenn man, wie in Crysis’ Modell, von Nullhöhe ausgeht ist es nurnoch ein Klacks.


na dann? schreib's auf

[Coda]

Soweit ich weiß halten sie sich bei Crysis sehr an Photovorlagen, insofern ist es eben doch wieder realistisch.

Solange das Bild stimmt ist es ja egal wie es berechnet wird.

[Krishty]

@pest: Soll ich lachen? Wenn du die Eigenschaften der Atmosphäre kennst, kannst du auch sagen was mit Licht passiert, das sie durchquert. Basta. Und keine Angst, ich bin kein Troll.

[pest]

@pest: Soll ich lachen? Wenn du die Eigenschaften der Atmosphäre kennst, kannst du auch sagen was mit Licht passiert, das sie durchquert. Basta.

Druck, Luftfeuchte (höhenabhängig)...sehr interessant...da muss ich wohl nen anderes Paper angeschaut haben, und selbst wenn du das vernachlässigst darfst du noch ein paar Kurvenintegrale berechnen. Da ist die "Fotovariante" wohl weit weniger aufwendig...bzw...wenn du schreibst "es ist ein Klacks" ... dann verstehe ich das so. Ich wäre nicht so anmaßend, selbst wenn ich wüßte wovon ich rede.

[Krishty]

Bitte …http://en.wikipedia.org/wiki/Rayleigh_scattering#Small_size_parameter_approximation
Die dritte Formel von oben ist wichtig, sie ist die Streuung eines Moleküls über alle Raumrichtungen integriert (also, wie stark das Sonnenlicht an einem einzelnen Molekül schwächer wird). Dort setzt du jeweils die Wellenlängen für rotes, grünes und blaues Licht ein. Die anderen Parameter wie Polarisationsfaktoren der Luft etc. musst du bei Wikipedia oder aus anderen Papers zusammensuchen, die habe ich gerade nicht zur Hand.

Die optische Dichte der Atmosphäre in Richtung des Horizonts beträgt 308 km bei Standardluftdruck (Quelle: „On Skylight and Aerial Perspective“, A.J. Preetham, Siggraph 2003). Damit (und mit der Anzahl der Moleküle pro Kubikmeter Luft) multiplizierst du die Faktoren für RGB, berechnest e^-[1 - Die Faktoren] und hast die Farbe der Sonne, wenn sie am Horizont steht. Für andere Sonnenstände kannst du die optischen Dichten besagtem Paper entnehmen, über Formeln oder Brute-Force annähern oder deine besagten Kurvenintegrale lösen. Da wir von Nullhöhe ausgehen, stehen diese aber von Anfang an fest und müssen normalerweise nicht mehr berechnet werden.

Die Farbe gilt zwar nur für die Streuung an der Luft, für alle anderen Partikel (Mie-Streuung) funktioniert es aber analog. Da du schon ein paar Paper gelesen hast, weißt du das aber sicher.

Das ist durchaus ohne große Probleme implementierbar. Dass „Klacks“ in diesem Forum nicht „in zwei Schritten auf dem Papier lösbar“ bedeutet, dürfte klar sein. Dass die Fotovariante weniger aufwendig ist ist mir auch klar, aber wenn du das Foto nicht unter identischen atmosphärischen Bedingungen aufgenommen hast kannst du nicht behaupten, es wäre das Ergebnis eines physikalisch korrekten Modells. Und das war ja der springende Punkt.

Du kannst einen Thread für Sky-Rendering aufmachen oder dich per PM an mich wenden, falls es da Gesprächsbedarf besteht. Mein Hauptanliegen war aber ursprünglich ein anderes, also belasten wir diesen Thread nicht damit.

Wenn ein Maler ein Gemälde malt und es fotorealistisch aussieht, erkenne ich das an und habe nichts auszusetzen. Wenn er dann aber sagt, die Farben, die er offensichtlich frei Schnauze ausgewählt hat, stünden auf einem physikalischen Fundament, das er für das Bild aufgestellt und aufgelöst hat, ist das schlicht falsch. Punkt.

Wenn man die Sonnenfarbe in Crysis frei Schnauze bestimmt und sie so hinbekommt, dass es gut aussieht (und Crysis sieht nunmal gut aus), erkenne ich das an. Aber physikalisch korrekt wird es erst, wenn man es über die Eigenschaften der Atmosphäre herleitet, genau wie es die Natur eben auch tut.

Wenn man die Farbe des Himmels über Formeln berechnet, die vereinfacht wurden und auf Input basieren, den ein Künstler eingegeben hat, dann ist das Endergebnis für mich physikalisch nicht so korrekt als wenn man die Leuchtdichte einer vergleichbaren echten Atmosphäre abfotografiert und als Textur nutzt.

Perfekt wäre es, wenn die komplette Atmosphäre über die physikalischen Eigenschaften hergeleitet würde, ohne Vereinfachungen und ohne willkürlich gewählten Input. Aber das ist nicht möglich.

Mit der künstlerischen Qualität hat die physikalische Richtigkeit nichts zu tun. Alles geklärt? Ich wollte echt nicht, dass das so hoch kocht … sorry dafür.

[pest]

der Spoiler hätte mir als erste Antwort gereicht, obwohl ich da an manchen Stellen gerne nochmal nachhaken würde...

btw. mir hätte gereicht du hättest geschrieben "es ist ein Klacks, ein rel. korrektes Sonnenfarbenmodell aufzustellen" wie man das mit den bestehenden Modellen verbindet und es effizient bzw. in Echtzeit berechnet ist kein Klacks.
Oder weitergesponnen. Das Sonnenmodell ist ja wiederum von der Korrektheit der anderen Modelle abhängig (z.B. die Fogsimulation), also warum dann nicht andersherum?
Das gibts allerdings schon, glaub ich, als Transport des Strahlenflusses oder Photon Mapping, wo wir dann wieder bei den Kurvenintegralen sind...

[Krishty]

Die Echtzeitberechnung IST ein Klacks und effizient. Ich kann dir in einer Milisekunde ein Lookup mit der Farbe für jede 1/1024el Horizonthöhe generieren - solange wir auf Nullhöhe bleiben.
Das Sonnenmodell ist ja wiederum von der Korrektheit der anderen Modelle abhängig (z.B. die Fogsimulation), also warum dann nicht andersherum?
Das gibts allerdings schon, glaub ich, als Transport des Strahlenflusses oder Photon Mapping, wo wir dann wieder bei den Kurvenintegralen sind...Das Sonnenmodell ist streng genommen sogar das Fog-Modell: Die Sonne verhält sich wie ein weißer Körper, der hinter der Atmosphäre platziert und dann genauso abgeschwächt und vom einstreuenden Licht überlagert wird wie alles andere (Berge, Wolken) auch. Dass man von einem vereinigten Modell absieht, hat vor allem zwei Gründe:

- Da die Sonne recht hell und zudem meist die einzige Lichtquelle ist, kann man den Einstreuungs-Term bei ihr komplett weglassen. Entsprechend kann man für den restlichen Himmel den Abschwächungs-Term ignorieren, weil das dahinterliegende Universum eh schwarz ist.

- Man braucht für die meisten Licht- und Schatteneffekte eine genau definierte, punktförmige Lichtquelle, die eben auch eine bestimmte Farbe haben muss.

Wenn man, wie du schon sagtest, eine perfekt exakte Form von Global Illumination implementieren könnte, könnte man das alles im Fog - oder besser, der Atmosphären-Formel - vereinigen. Weil die Sonne mit ihren 0,54° Durchmesser aber so winzig klein ist, dass sie durch die Raster der meisten Algormithmen fiele, wäre sie nicht extra definiert (vielleicht abgesehen vom Photon Mapping, wo sie ja die Quelle aller Photonen wäre), liegt das noch in weiter Ferne.

Aber dafür müssen wir zuerst die Einschränkungen von endloser Entfernung und Nullhöhe aufgeben, womit wir das Thema Cryis verlassen.

[Gast]

Wenn man die Sonnenfarbe in Crysis frei Schnauze bestimmt und sie so hinbekommt, dass es gut aussieht (und Crysis sieht nunmal gut aus), erkenne ich das an. Aber physikalisch korrekt wird es erst, wenn man es über die Eigenschaften der Atmosphäre herleitet, genau wie es die Natur eben auch tut.
In Crysis Editor bestimmt man die eingangsparameter mit denen dann die Atmosphaere errechnet wird.
Sagst du, dass das nicht der erde enspricht was man sieht, dann hast du recht.
Sagst du, dass das physikalisch inkorrekt ist, hast du leider unrecht.

Die berechnungen sind auch entsprechend aufwendig, wenn du die sonnenposition radikal im Editor aenderst, dauert es bis der Himmel auf die neue Atmosphaere "umschaltet".

[Gast]

In Crysis Editor bestimmt man die eingangsparameter mit denen dann die Atmosphaere errechnet wird.
Sagst du, dass das nicht der erde enspricht was man sieht, dann hast du recht.
Sagst du, dass das physikalisch inkorrekt ist, hast du leider unrecht.

Die berechnungen sind auch entsprechend aufwendig, wenn du die sonnenposition radikal im Editor aenderst, dauert es bis der Himmel auf die neue Atmosphaere "umschaltet".
Naja, ob man das wirklich physikalisch korrekt hinstellen sollte, müsstest du dir denk ich nochmal überlegen.

Es wird nach mathematischen Berechnungen gehen, klar. Aber das hat nix mit irgendwelcher Physik zu tun lieber "anderer" Gast;)

Wie du schon sagst, wird es dem der Erde kein bisschen nahe kommen was die Berechnungen angeht, da hier die Dichte der verschiedenen Punkte wie die diversen Gase, Sauerstoffgehalt, Stickstoffgehalt etc. im umlauf sind, nicht miteinberechnet werden "können". Nicht in dem Maße.
Zudem fehlt ganz klar dass das Licht der Sonne sich nicht nur durch die Ozon schicht bricht, bzw was davon noch übrig ist:D und dann noch durch die unendlich vielen kleinen Partikel die durch die Luft wirbeln.
Wolken habe ich jetzt mal außen vor gelassen, weil ich denke das eine Diskussion in diese Richtung auch hoffentlich für die letzten Crysis verfechter klar ist.

Ohne Frage, bomben Engine, sehr gute Grafik, wenn auch ganz klar Geschmacksfrage wie immer;)
Aber man brauch nicht unbedingt Crytek auf das Niveau eines Gottes heben....soweit sind die 3 Türken auch nicht:)

MFG Carsten

[Coda]

Es ging mir nur darum, dass sie ganz sicher nicht einfach mal so kurz die Crysis Engine was das angeht nachbauen würden.

Da ist Quake Wars ein ganz anderes Kaliber.

Crysis hat auf jeden Fall bisher das "genauste" und aufwändigste Lichtmodell.

[Gast]

Das stimmt.

Ich bin mittlerweile auch auf Killzone 2 gespannt. Von dem gezeigten Material kann man leider nicht wirklich viel erkennen, die papers lesen sich aber sehr interessant.

Bin gespannt wie die Performance sein wird.

[Chris Lux]

Ich bin mittlerweile auch auf Killzone 2 gespannt. Von dem gezeigten Material kann man leider nicht wirklich viel erkennen, die papers lesen sich aber sehr interessant.
Links? (Bin grad zu faul zu suchen)

[Gast]

http://www.gametrailers.com/player/34201.html

in diesem video wird irgendwann am anfang was von raytracing erwähnt.
aber in welchem umfang es genutzt wird etc. wird leider nicht weiter drauf eingegangen.

[deekey777]

http://www.gametrailers.com/player/34201.html

in diesem video wird irgendwann am anfang was von raytracing erwähnt.
aber in welchem umfang es genutzt wird etc. wird leider nicht weiter drauf eingegangen.
In KZ2 wird gar kein Raytracing benutzt.

[Gast]

raytracing wird nicht nur für grafik genutzt...

[deekey777]

raytracing wird nicht nur für grafik genutzt...
Nur nutzt KZ2 weiterhin kein Raytracing.

[dust]

Quake Wars Gets Ray Traced (PDF)
http://www.intelsoftwaregraphics.com/?lid=2224&siteid=32

[mekakic]

D3D11 bringt dann evtl. noch programmierbare Render-Frontends die nach Bedingungen Drawcalls rendern können, dann ist auch das Occlusion-Culling-Problem endgültig vom Tisch bei Rasterisierung.Bringt es das?

Hier steht (http://en.wikipedia.org/wiki/Transformers_%28film%29#Effects):
Bay, who has directed numerous car commercials, understood ray tracing was the key to making the robots look real; the CG models would look realistic based on how much of the environment was reflecting on their bodies.

Ist das Quatsch oder womit wurde Transformers gerendert? Oder wird da auch so ein hybrid Ding verwendet: Rasterizing bis zum "First hit" und Raytracing danach?

[Coda]

Bringt es das?
Nope, leider nicht. Aber wozu gibt es Larrabee ;)

Ist das Quatsch oder womit wurde Transformers gerendert? Oder wird da auch so ein hybrid Ding verwendet: Rasterizing bis zum "First hit" und Raytracing danach?
Transformers ist in der Tat Raytracing, wegen den vielen Spiegelungen.

[_DrillSarge]I[]

Quake Wars Gets Ray Traced (PDF)
http://www.intelsoftwaregraphics.com/?lid=2224&siteid=32
wer mal das video davon gesehen hat: lol.
toll, ich baue überall irgendwelche perfekten kugeln und reflexionen ein, aber der rest: pfui.
die dynamischen *hust* objekte sehen aus :rolleyes: und bewegen sich wie auf schienen. :|

[Krishty]

Ohja, ist ja tatsächlich lächerlich … die Kamera ist immer möglichst hastig in Bewegung, damit einem bloß nicht auffällt, dass sich außer zwei Objekten nichts bewegt – nicht einmal das Wasser haben sie animiert bekommen, aber Hauptsache das Kraftfeld wirft Schatten -.-

Hier (http://video.golem.de/games/1598/quake-wars-raytraced.html) ist das Video, von dem wir reden (hoffe ich). Mein Tipp: Einfach mal den Ton ausstellen.

Ein perfektes Beispiel dafür, was für Welten zwischen Einzelbildern und Videos liegen können …

[roidal]

Sollte man den Schatten des Kraftfeldes nicht auch mit Rasterisierung hinbekommen?

[Krishty]

Normalerweise schon, nur denke ich, dass es sich in diesem Fall um eine prozedurale Textur handelt, da wird das schon schwieriger … Color-Bleeding wäre mir an der Stelle übrigens 100× wichtiger als Schatten, aber das ist nur mein Senf.

… ist euch aufgefallen, dass in dem Video kein einziges Portal durchschritten wird? Da wird immer nur drauf zugeflogen, aber kurz vorher entweder gestoppt oder geschnitten … warum?

Und das Wasser am Ende muss ja eine überwältigende Brechzahl haben …

… aber genug meiner Rants, könnte mich irgendein Experte ablösen? :D

[Coda]

Normalerweise schon, nur denke ich, dass es sich in diesem Fall um eine prozedurale Textur handelt, da wird das schon schwieriger …
Nö. Allerdings sind "transparente" Schatten in der Tat gar nicht so einfach bei Rasterisierung. Mit normalem Shadow-Mapping geht das nicht.

… ist euch aufgefallen, dass in dem Video kein einziges Portal durchschritten wird? Da wird immer nur drauf zugeflogen, aber kurz vorher entweder gestoppt oder geschnitten … warum?
Das einzubauen wäre wirklich trivial. Das ist nur eine Verschiebung der Kamera.

Und das Wasser am Ende muss ja eine überwältigende Brechzahl haben …
Kann man ja beliebig einstellen. Man will halt auch das man was sieht ;)

[Arcanoxer]

Quake Wars Raytraced mit 3D-Spezialeffekten (http://www.golem.de/0906/68021.html)

Komplexer Effekt mit nur einer Zeile Code

Intels Entwicklung einer Raytracing-Engine für das Spiel "Enemy Territory: Quake Wars" macht Fortschritte. Neben mehreren hundert Spielfiguren kann Programmierer Daniel Pohl nun auch typische Spezialeffekte von Spielen darstellen, die sehr einfach umzusetzen sein sollen.

[deekey777]

Sie sollten endlich Klartext reden und ein Spiel wie Crysis auf Very High mit Raytracing zeigen.
Nur fehlt ihnen die dafür benötigte Rechenleistung. Ok, die Rechenleistung haben sie, nicht aber der normale Nutzer. Bis sie mit ihrem Projekt soweit sind, werden aktuelle Techniken viel weiter sein.

[_DrillSarge]I[]

Quake Wars Raytraced mit 3D-Spezialeffekten (http://www.golem.de/0906/68021.html)
siehe mein kommentar von oben :rolleyes:
bis auf die typischen "raytracing-demoeffekte" sieht das in allen belangen mieser aus als das original. auch die models und deren bewegung sind geradezu peinlich schlecht. man sieht eben, dass das ganze noch nicht wirklich praktikabel ist.

[roidal]

Die Effekte waren ja sooooo einfach einzubauen damit sie dafür ja über ein Jahr gebraucht haben...

[Ganon]

Naja, die Effekte einzubauen ist einfach. Nur sie in Echtzeit darzustellen ist halt etwas schwieriger ;)

[Nasenbaer]

Naja, die Effekte einzubauen ist einfach. Nur sie in Echtzeit darzustellen ist halt etwas schwieriger ;)
Vielleicht mussten sie auch noch auf den passenden Cluster warten, damit es angemessen schnell läuft. ^^

[Gast]

Quake Wars Raytraced mit 3D-Spezialeffekten (http://www.golem.de/0906/68021.html)
Bewegte Charactere...
Ich will Skinning sehen. Weder sich bewegende statische Geometrie noch Key Frame Animation sind wirklich dynamische Geometrie.

So langsam sollte ihm das selbst peinlich werden...

[DR.ZEISSLER]

ich find's auch doof...ist doch nur mittel zum zweck, ein wenig publicity und dat wars.
stink langweilig und keineswegs überzeugend was es da zu sehen gibt.

ich denke die kollegen von dem anderen raytracer werden da überzeugender einschlagen.

[Gast]

Sie machen es nur falsch.

Oft ist es so, dass neue tech auf etwas ganz eingeschraenkten presentiert wird, auf dem es aber super funktioniert.
mit der ersten quake engine haette man auch kein farcry machen koennen.
mit der "elite-engine" vermutlich nichtmal ein wolfenstein-3d. mit der "myst-engine" kein adventure mit figuren und vielen dialogen usw.

aber dennoch waren diese spiele/engines herausragend, weil man sie in einem anwendungsgebiet presentierte, in dem die 'macken' garnicht zu sehen sind.

hier weiss man eindeutig, dass das worst-case szenario ein vorhandene spiel fuer rasteriser graphik ist, dass auch noch von grosser dynamic lebt, wie z.b. ein multiplayer shooter (gerade MP spiele werden oft mit sehr schlechten einstellungen gespielt, damit man irsinnige framerate hat und daraufhin wurden sie auch gebaut).

Man muss halt nicht nur know-how haben, sondern auch faehig sein es zu verkaufen. -> fail.

[roidal]

http://winfuture.de/news,48303.html

und hier noch was:

http://arstechnica.com/hardware/news/2009/07/800-tflop-real-time-ray-tracing-gpu-unveiled-not-for-gamers.ars

ich hab zwar NULL ahnung wie die es auf 800TFlops schaffen...aber...tja...

[deekey777]

Kreatives Rechnen?
http://techon.nikkeibp.co.jp/article/HONSHI/20090629/172373/
The Toyota Motor rendering system, unlike conventional ray tracing systems, splits visible light into 35 wavebands, and calculates optical properties such as reflection and refraction for objects individually for each waveband. To execute this intense processing at HD resolution and in realtime demanded supercomputer-class performance: 800TFLOPS (Note 2).

Ich verstehe das so: Um die Leistung dieser speziellen Cores zu erreichen, bräuchte man einen Rechner, der für diese spezielle Anwendung 800 TFLOPS liefert/liefern kann.

[roidal]

Kreatives Rechnen?
http://techon.nikkeibp.co.jp/article/HONSHI/20090629/172373/


Ich verstehe das so: Um die Leistung dieser speziellen Cores zu erreichen, bräuchte man einen Rechner, der für diese spezielle Anwendung 800 TFLOPS liefert/liefern kann.

Tja, einen Post weiter oben haste den Link zu einer Karte welche das schaffen soll.

[deekey777]

Tja, einen Post weiter oben haste den Link zu einer Karte welche das schaffen soll.
Wir haben doch beide Links zum selben Stück Hardware gepostet, oder?
Du hast dich gefragt, wie sie auf 800 TFLOPs kommen, und ich fand eine Antwort, oder? Oder reden wir gerade aneinander vorbei? ;(

[roidal]

Wir haben doch beide Links zum selben Stück Hardware gepostet, oder?
Du hast dich gefragt, wie sie auf 800 TFLOPs kommen, und ich fand eine Antwort, oder? Oder reden wir gerade aneinander vorbei? ;(
lol, sorry, hab den link total übersehen

[mekakic]

Intels Raytracing-Projekt: Der Stand der Dinge (http://www.computerbase.de/news/software/spiele/2009/august/intels_raytracing-projekt_der_stand_dinge/) bei Computerbase.

BTW: Geht es nur mir so - ich kenne mich nicht mal so gut da aus, aber wenn man sich die ganzen Computerbase-User-Kommentare durchliest, stellen sich mir ja schon teilweise die Nackenhaare bei dem ganzen Blödsinn auf. Da bräucht man ja bis zur Rente wenn man das alles richtigstellen wollte.

[Nasenbaer]

Intels Raytracing-Projekt: Der Stand der Dinge (http://www.computerbase.de/news/software/spiele/2009/august/intels_raytracing-projekt_der_stand_dinge/) bei Computerbase.

BTW: Geht es nur mir so - ich kenne mich nicht mal so gut da aus, aber wenn man sich die ganzen Computerbase-User-Kommentare durchliest, stellen sich mir ja schon teilweise die Nackenhaare bei dem ganzen Blödsinn auf. Da bräucht man ja bis zur Rente wenn man das alles richtigstellen wollte.
Am besten sind die Kommentare, die sich über die neuen Screenshots freuen. Man sieht mal wieder nur Refraktion/Reflektion - angepriesen als Mörderfeature. Das Wasser in Crysis sieht IMO besser aus - läuft zwar auch nicht so schnell wie mans gern hätte aber 16 Core braucht man gewiss nicht. :)

[Gast]

John Carmack gibt ihm recht.

"Ray-tracing in games is another technology Carmack expects to see hit in the future. While it might not be the standard in the next generation of consoles even, Carmack did suggest it would be the future, a position he has gradually been coming around to in recent months, after familiarizing himself with the last 20 years of literature on the topic."

http://www.gamespot.com/events/quakecon2010/story.html?sid=6273388

[Iruwen]

Carmack war auch von Stencil Shadows begeistert, der soll seinen Ferrari polieren und erstmal wieder ein gutes Spiel rausbringen.

[deekey777]

John Carmack gibt ihm recht.

"Ray-tracing in games is another technology Carmack expects to see hit in the future. While it might not be the standard in the next generation of consoles even, Carmack did suggest it would be the future, a position he has gradually been coming around to in recent months, after familiarizing himself with the last 20 years of literature on the topic."

http://www.gamespot.com/events/quakecon2010/story.html?sid=6273388
Wo gibt er ihm Recht?

[mapel110]

Rasterization Method of Rendering Will Live On for Another Decade - Nvidia.
http://www.xbitlabs.com/news/video/display/20100903130512_Rasterization_Method_of_Rendering_Will_Live_On_for_Another_Decade _Nvidia.html

"Our group has definitely done research in [fixed-function ray tracing hardware] area to explore the 'speed of light', but my sense at this time is that we would rather spend those transistors on improvements that benefit other irregular algorithms as well," said David Luebke, director of graphics research at Nvidia, during a public conversation earlier this week.

"Forward rasterization is a very energy-efficient way to solve single-center-of-projection problems (like pinhole cameras and point light shadow maps) which continue to be important problems and sub-problems in rendering. So I think these will stick around for at least another ten years," stressed the director of graphics research at Nvidia.

[roidal]

Nun gibts schon etwas bessere Bilder, diesmal berechnet von 4 "Knights-Ferry" Karten (ehemals Larrabee).
http://www.golem.de/1009/77900.html

[Coda]

>800W und Grafik wie vor 5 Jahren, während Crytek schon Global Illumination auf einer Xbox 360 laufen lässt. Das sie sich nicht selber dumm dabei vorkommen.

[roidal]

>800W und Grafik wie vor 5 Jahren, während Crytek schon Global Illumination auf einer Xbox 360 laufen lässt. Das sie sich nicht selber dumm dabei vorkommen.
Nachdem sie es bis jetzt noch nicht geschafft haben nen ordentlichen Chip fürs Rasterisieren zu bauen bleibt ihnen gar nichts anderes übrig als weiterhin an Raytracing festzuhalten. ;D

[Chris Lux]

und alles so schön dynamisch...

ich bin bald geplatzt vor lachen, als es in dem golem artikel um die nebel- und partikeleffekte ging.

wir lachen hier eigentlich immer genüsslich wenn daniel pohl wieder mal was von sich gibt.

[MadManniMan]

>800W und Grafik wie vor 5 Jahren, während Crytek schon Global Illumination auf einer Xbox 360 laufen lässt. Das sie sich nicht selber dumm dabei vorkommen.

Und täusch ich mich oder kann man die FPS nicht ernst nehmen? Achte mal drauf, wie es ruckelt und zuckelt, obschon der Counter im 40er Bereich ist ...

[Coda]

Könnte auch vom Streaming kommen, oder die Animationen sind einfach schlecht.

Das bekloppte daran ist mal wieder, dass sie mit 1 Mio. Polygonen bei dem Kronleuchter angeben, die dann Flimmern wie Dreck, weil die Geometrieauflösung viel zu hoch ist.

Rasterisierung mit Tesselation würde besser aussehen und wesentlich schneller sein. Als ob man sieht, dass die Refraction des Glas mit Raytracing berechnet ist.

[Gasti]

Die Feuer- und Raucheffekte sind einfach wegweisend :ugly:

[Tesseract]

wie lange hält sich raytracing jetzt eigentlich noch als buzzword, von dem alle meinen es sei der heilige gral des rendering?

moderne rasterisierung ist auf performance-limitierter hardware für normale alltagsanwendungen die wesentlich elegantere lösung.

[Shink]

wie lange hält sich raytracing jetzt eigentlich noch als buzzword, von dem alle meinen es sei der heilige gral des rendering?
Hmm... solange man bei Filmen Raytracing einsetzt?

[Nasenbaer]

wie lange hält sich raytracing jetzt eigentlich noch als buzzword, von dem alle meinen es sei der heilige gral des rendering?

moderne rasterisierung ist auf performance-limitierter hardware für normale alltagsanwendungen die wesentlich elegantere lösung.
Naja Carmack hatte sich vor kurzem doch auch sehr entzückt über Raytracing geäußert. Ihm gefiel was er sich zum Thema durchgelesen hat.

An sich finde ich Raytracing auch nach wie vor die elegantere Lösung aus Algorithmiksicht. Wenn man sich allein die Verrenkungen bei Rasterizern ansieht um halbwegs schöne Schatten hinzubekommen, dann ist das Samplen einer Lichtquellen beim Raytracing (für weiche Schatten) wesentlich intuitiver und leichter umzusetzen.
Naja dafür ist es halt immer noch nicht wirklich echtzeitfähig, wenn man graphisch mit ner Rasterizerengine mithalten will. Sobald Herr Pohl von Intel den Deep Thought geschenkt bekommt sollte das Problem aber auch vom Tisch sein. ;D

EDIT:
@Shink
Das billige Whitted Raytracing mit dem der Typ immer hausieren geht, ist sich nicht State-of-the-Art in Hollywood. ;-)

[Tesseract]

Hmm... solange man bei Filmen Raytracing einsetzt?wird afaik für die meisten szenen schon seit ewigkeiten nichtmehr gemacht weil man selbst hier nicht unbegrenzt rechenleistung zur verfügung hat und das will was heißen.

An sich finde ich Raytracing auch nach wie vor die elegantere Lösung aus Algorithmiksicht. Wenn man sich allein die Verrenkungen bei Rasterizern ansieht um halbwegs schöne Schatten hinzubekommen, dann ist das Samplen einer Lichtquellen beim Raytracing (für weiche Schatten) wesentlich intuitiver und leichter umzusetzen.

ich glaub du hast eine etwas falsche vorstellung von raytracing. bei normalem raytracing hast du knallharte schatten und (vor allem bedingt durch die endliche rekursionstiefe) aliasingartefakte, dass dir schlecht wird. damit raytracing ansehnlich wird musst du entweder mit vielen kleinen quirks anrücken oder mit massiv supersampling drüberwalzen.
und damit es auch nur ansatzweise berechenbar wird muss sowieso ein ganzer haufen optimierungen her wie z.B. bounding spheres und raumteilungsverfahren und dann ist es mit der einfachheit ganz schnell wieder vorbei.
und für eine wirklich brauchbare beleuchting brauchst du dann sowieso radiosity-verfahren oder ähnliches.

raytracing ist nur dann elegant, wenn du unendlich rechenpower hast, sprich: mit auflösung und rekursionstiefe gegen unendlich gehen kannst - und selbst dann ist es nicht perfekt.

[deekey777]

Ich kann mich auch irren, aber in "Cars" wurde Raytracing gerade für harte Schatten eingesetzt.

Und der gute John Carmack hat bezüglich RTs auch gesagt, dass es noch lange dauert, bis wir RT, wie es hier propagiert wird, sehen werden.

[Bucklew]

wie lange hält sich raytracing jetzt eigentlich noch als buzzword, von dem alle meinen es sei der heilige gral des rendering?
Realistisch wird es wohl (wenn überhaupt) auf eine Mischung aus Raytracing und Rasterising in Zukunft hinauslaufen. Automobiler nutzen schon viel Raytracing, nicht nur um neue Designs zu testen, sondern auch um z.B. im Vorfeld die Reflektionen des Fahrzeuginneren in der Fronscheibe zu testen usw.

Das Intel jetzt schon solche kurden Szenarien nutzen muss, damit nicht jeder sofort denkt was für ein Quatsch sagt ja alles ;)

edit: Versteh ich das richtig? Vier (!) Server mit Larrabee-Beschleuniger? Also kann man davon ausgehen, dass jeder Server so 3-4 Larrabee-Karten enthält, sonst würde man sich die Arbeit das ganze Zeug zu synchronisieren ja sicherlich nicht antun?!

[Nasenbaer]

ich glaub du hast eine etwas falsche vorstellung von raytracing. bei normalem raytracing hast du knallharte schatten und (vor allem bedingt durch die endliche rekursionstiefe) aliasingartefakte, dass dir schlecht wird. damit raytracing ansehnlich wird musst du entweder mit vielen kleinen quirks anrücken oder mit massiv supersampling drüberwalzen.
und damit es auch nur ansatzweise berechenbar wird muss sowieso ein ganzer haufen optimierungen her wie z.B. bounding spheres und raumteilungsverfahren und dann ist es mit der einfachheit ganz schnell wieder vorbei.
und für eine wirklich brauchbare beleuchting brauchst du dann sowieso radiosity-verfahren oder ähnliches.

raytracing ist nur dann elegant, wenn du unendlich rechenpower hast, sprich: mit auflösung und rekursionstiefe gegen unendlich gehen kannst - und selbst dann ist es nicht perfekt.
Raumunterteilung hast du auch bei Rasterizern - da wird auch gegens Viewing-Frutrum geculled. Und für weichere Schatten muss man Punktlichter einer zu Kugellichtern aufblasen *gg* damit man mehr Samples und damit weichere Schatten hat. Dazu spawnt du einfach ein paar Strahlen, die dann die Oberfläche dieser Kugel leicht samplen. Für bessere Qualit braucht man natürlich mehr. Das gleiche Prinzip sorgt auch für diffusere Reflexionen. Supersampling ist auch sehr einfach zu implementieren.

Um das nochmal deutlich zu machen. Ich wollte nur klar machen, dass die Algorithmen wesentlich leichter verständlich nicht, weil einfach besser motivierbar ist warum man was macht. Das Verfahren kommt dem physikalischen Prozess wesentlich näher als Tasterisierung, wenngleich das Licht natürlich eigentlich von Lichtquellen ausgeht und nicht aus ner Kamera kommt. :)
Das Nachteil ist natürlich, dass, insbsondere für Effekte, die nicht so lächerlich sind wie bei Pohls Präsis, wesentlich mehr Rechenleistung notwendig ist und schon interaktives Arbeiten (~ 10fps) fern jeder Realität ist - ich sag ja Deep Thought wird gebraucht. *gg*

[Tesseract]

Raumunterteilung hast du auch bei Rasterizern - da wird auch gegens Viewing-Frutrum geculled.
was hat culling mit raumteilung zutun? ich meine das unterteilen des raums in unterräume, wobei du jeweils den strahl nur mit den primitiven des unterraum schneidest, den er durchwandert.

Und für weichere Schatten muss man Punktlichter einer zu Kugellichtern aufblasen *gg* damit man mehr Samples und damit weichere Schatten hat. Dazu spawnt du einfach ein paar Strahlen, die dann die Oberfläche dieser Kugel leicht samplen. Für bessere Qualit braucht man natürlich mehr. Das gleiche Prinzip sorgt auch für diffusere Reflexionen. Supersampling ist auch sehr einfach zu implementieren.
das löst aber nicht das problem, dass selbst primitives raytracing mit einfachen schattenfühlern unpraktikabel rechenaufwändig ist. genau das ist das problem an dem ganzen. ;)

Ich wollte nur klar machen, dass die Algorithmen wesentlich leichter verständlich nicht, weil einfach besser motivierbar ist warum man was macht. Das Verfahren kommt dem physikalischen Prozess wesentlich näher als Tasterisierung, wenngleich das Licht natürlich eigentlich von Lichtquellen ausgeht und nicht aus ner Kamera kommt. :)
das bestreitet ja auch keiner. aber nur weil ein algorithmus einfacher verständlich ist heißt das nicht, dass der die sinnvollere lösung ist.
es würde auch (hoffenlich) keiner selectionsort zum sortieren einsetzen weil er "einfacher" ist.

[Chris Lux]

wird afaik für die meisten szenen schon seit ewigkeiten nichtmehr gemacht weil man selbst hier nicht unbegrenzt rechenleistung zur verfügung hat und das will was heißen.
gerade bei sony geht man von rasterisierung (welcher klassicherweise benutzt wird) zu reinem ray tracing (sunny with a chance for meatballs, war der erste).

Und der gute John Carmack hat bezüglich RTs auch gesagt, dass es noch lange dauert, bis wir RT, wie es hier propagiert wird, sehen werden.
lest mal seinen twitter feed. der gute spielt gerade mit einem OpenCL ray tracer.

[Bucklew]

lest mal seinen twitter feed. der gute spielt gerade mit einem OpenCL ray tracer.
was noch lange nicht heißt, dass dieser bq- und performancemäßig an einen rasteriser herankommt ;)

[Fragman]

raytracing in filmen, ja, allerdings ist das neue buzzword "importance sampling" seit einigen jahren. ;)
allerdings muss man hier immer wieder betonen das man faked wo es nur geht ueber envmaps, fast glossy interpolation und entfernungslimits fuers tracen.

pixar setzt aktuell ja kaum auf raytracing weil sie durch die point clouds andere ansaetze haben die aehnliche ergebnisse bringen und die bei deren szenenkomplexitaet bei weitem nicht so auf die renderzeit durchschlagen. selbst fuer glossys nutzen sie fast immer pointclouds.


die neuen beispiele sehen alles andere als gut aus. und man sieht schon an den bildern wie das alles flimmert. dazu kommt noch die ambient/spotlight beleuchtung die man in keinem spiel sehen will. wenn das so weitergeht sehen wir in 5-7 jahren screens in der quali von heutigen aaa titeln. nur werden wir dann wieder darueber diskutieren wie schwach die screens sind. die technik gibt aktuell noch nichts her fuer realtime.

weiss auch nicht wie sich das aendern soll. es fehlt der punkt wo man mit rasterizer nicht mehr weiterkommt und raytracing braucht weil man die rasterizerchips nicht mehr produzieren kann die man braeuchte oder die szenenkomplexitaet bei games incl dem shading so ansteigt das raytracing bei gleicher quali schneller ist.

[Coda]

Hmm... solange man bei Filmen Raytracing einsetzt?
Das tut man nur in Ausnahmefällen. Das meiste ist Micropolygon-Rendering (REYES).

Viel besser geeignet um schnell Motion Blur, schönes Displacement Mapping und Depth-of-Field zu berechnen.

[Fragman]

Das tut man nur in Ausnahmefällen. Das meiste ist Micropolygon-Rendering (REYES).

Viel besser geeignet um schnell Motion Blur, schönes Displacement Mapping und Depth-of-Field zu berechnen.

bis aufs displacement kann das arnold (der renderer den auch sony einsetzt) auch ohne das die renderzeit steigt. dieser reyes vorteil ist dahin. das disp problem bleibt aber aktuell noch (was aber schon ein extrem starkes feature ist bump statt disp nutzen zu koennen). mal schaun wies technisch weitergeht in den naechsten jahren.

[Coda]

bis aufs displacement kann das arnold (der renderer den auch sony einsetzt) auch ohne das die renderzeit steigt.
Bestimmt nicht. Für Moblur und Depth of Field braucht man immer mehr Samples.

Außer man Pfuscht grob - und das tut Reyes an der Stelle nicht.

[Tesseract]

wenn das so weitergeht sehen wir in 5-7 jahren screens in der quali von heutigen aaa titeln. nur werden wir dann wieder darueber diskutieren wie schwach die screens sind. die technik gibt aktuell noch nichts her fuer realtime.

wobei raytracing momentan sogar noch den vorteil der seit jahren relativ konstanten auflösungen hat. würden endlich screens mit ergonomischen auflösungen produziert werden (~300dpi auf >20") sähe es mit raytracing noch viel düsterer aus.

[Fragman]

Bestimmt nicht. Für Moblur und Depth of Field braucht man immer mehr Samples.

Außer man Pfuscht grob - und das tut Reyes an der Stelle nicht.

das motion blur und der dof sind sauber. siehe monster house, 2012, oder eben meatballs. andere user bestaetigen genau das, motion blur und dof haben kaum einfluss auf die renderzeit, liegt an der art des sampling was arnold nutzt. neben dem schnellen gi und glossys ist das ja ein grosses feature vom renderer.

[Coda]

das motion blur und der dof sind sauber.
Dann steigt auch die Renderzeit. Das ist unmöglich was du erzählst.

liegt an der art des sampling was arnold nutzt.
Evtl. macht das Ding ja auch Micropoly-Shading. Das wäre durchaus auch mit einem Raytracer kombinierbar.

Ich finde aber keinerlei Informationen zu dem Ding.

wobei raytracing momentan sogar noch den vorteil der seit jahren relativ konstanten auflösungen hat. würden endlich screens mit ergonomischen auflösungen produziert werden (~300dpi auf >20") sähe es mit raytracing noch viel düsterer aus.
Versteh ich nicht. Beide Verfahren skalieren doch ~ linear mit der Auflösung.

[Fragman]

Dann steigt auch die Renderzeit. Das ist unmöglich was du erzählst.


Evtl. macht das Ding ja auch Micropoly-Shading. Das wäre durchaus auch mit einem Raytracer kombinierbar.

Ich finde aber keinerlei Informationen zu dem Ding.


ist ein pathtracer, ne unterart, ich such mal infos.

[Tesseract]

Versteh ich nicht. Beide Verfahren skalieren doch ~ linear mit der Auflösung.
bei rasterisierung bedeutet doppelte auflösung doch nicht doppelter rechenaufwand wenn die polygonanzahl gleich bleibt.

[Nasenbaer]

was hat culling mit raumteilung zutun? ich meine das unterteilen des raums in unterräume, wobei du jeweils den strahl nur mit den primitiven des unterraum schneidest, den er durchwandert.

Naja ich würde, wenn ich ein Objekt gegen das View-Frustrum culle schon auf deren Bounding-Volume(wie auch immer geartet) zurückgreifen oder die Szene in handliche Stücke teilen und dann diese Zelle/Halbräume whatever gegens Frutrum testen.


das löst aber nicht das problem, dass selbst primitives raytracing mit einfachen schattenfühlern unpraktikabel rechenaufwändig ist. genau das ist das problem an dem ganzen. ;)


das bestreitet ja auch keiner. aber nur weil ein algorithmus einfacher verständlich ist heißt das nicht, dass der die sinnvollere lösung ist.
es würde auch (hoffenlich) keiner selectionsort zum sortieren einsetzen weil er "einfacher" ist.
Habe ich jemals etwas anderes behauptet? Natürlich ist das alles langsam. Aber ich sags gerne nochmal, mir ging es darum, dass Raytracing aus Algorithmiksicht eleganter umsetzbar ist. Die Komplexität, also vorallem die Laufzeit, ist ein anderes Thema und über das wir uns wohl alle auf einig sind.
Also nen Raytracer kann fast jeder zusammenbasteln, nen qualitativ gleichwertigen S/W-Rasterizer zu schreiben ist meiner Meinung nach aufwendiger.

bei rasterisierung bedeutet doppelte auflösung doch nicht doppelter rechenaufwand wenn die polygonanzahl gleich bleibt.
Habe ich jetzt nen Knoten im Hirn?! Supersampling halbiert nahezu die Framerate, da sich die Auflösung verdoppelt, also verhält es sich doch linear.

[Exxtreme]

Habe ich jetzt nen Knoten im Hirn?! Supersampling halbiert nahezu die Framerate, da sich die Auflösung verdoppelt, also verhält es sich doch linear.
Die Füllrate ist ein Aspekt unter vielen. Du kannst eine Halbierung der Framerate auch mit Geometrielast erzeugen.

[Tesseract]

Supersampling halbiert nahezu die Framerate, da sich die Auflösung verdoppelt, also verhält es sich doch linear.
das hängt von der anzahl der polygone ab. je größer diese werden (bezogen auf den pixelraster) umso annähernd linearer steigt die last mit der auflösung. wenn die polygone allerdings klein sind, teilweise deutlich kleiner als der pixelraster, sollte der rasterzier auf jedenfall deutlich effizienter skalieren als linear.

und mit supersampling ist das nur mit vorsicht zu vergleichen.

[Fragman]

hier sind ein paar infos zu finden:

http://www.larrygritz.com/docs/HPG2009-Gritz-Keynote-clean.pdf

und hier gibts auch noch ein paar infos was rendering angeht:

http://renderwonk.com/publications/s2010-shading-course/martinez/s2010_course_notes.pdf

auf cgtalk kann man sich auch noch infos zusammensuchen, aber solange der renderer noch in beta ist wird man da nicht soviel erfahren koennen ausser den basics.

[deekey777]

Könnte auch vom Streaming kommen, oder die Animationen sind einfach schlecht.

Das bekloppte daran ist mal wieder, dass sie mit 1 Mio. Polygonen bei dem Kronleuchter angeben, die dann Flimmern wie Dreck, weil die Geometrieauflösung viel zu hoch ist.

Da war doch was...
http://www.computerbase.de/artikel/grafikkarten/2007/bericht-raytracing-in-spielen/3/
(das schöne XY-System)
Wie soll man denn den Vorteil von Raytracing sonst zeigen?

Übrigens:
So bestehen beispielsweise der Kronleuchter und das Auto in den gezeigten Szenen aus je über einer Million Polygone, mehr als in den meisten Spieleszenen mit Rastergrafik
Erinnert mich irgendwie an die Äußerungen über die Anzahl der Roboteraugen in KZ2. X-D

[Chris Lux]

Da war doch was...
http://www.computerbase.de/artikel/grafikkarten/2007/bericht-raytracing-in-spielen/3/
(das schöne XY-System)
Wie soll man denn den Vorteil von Raytracing sonst zeigen?

nur das diese graphik grober unfug ist. rasterizer (bzw. rendering software/engines) nutzen auch space partitioning strukturen fuers culling und dann ist deren aufwand auch nicht mehr linear.

[Nasenbaer]

das hängt von der anzahl der polygone ab. je größer diese werden (bezogen auf den pixelraster) umso annähernd linearer steigt die last mit der auflösung. wenn die polygone allerdings klein sind, teilweise deutlich kleiner als der pixelraster, sollte der rasterzier auf jedenfall deutlich effizienter skalieren als linear.
Könntest du das mal genauer ausführen, irgendwie verstehe ich nicht warum. :/

[Gast]

nur das diese graphik grober unfug ist. rasterizer (bzw. rendering software/engines) nutzen auch space partitioning strukturen fuers culling und dann ist deren aufwand auch nicht mehr linear.

im worst case halt eben doch. angenommen dein komplettes level liegt in deinem viewfrustum. dann kannst du nix cullen beim rasterizer. jedes weitere polygon, das innerhalb hinzugefügt wird geht linear mit rein. beim raytracing hingegen logarithmisch.

aber da komm ich dann zum mixedrenderern. was soll das im gamebereich bringen? ich hol mir doch sobald ich raytracing einsetze eh das -einzig große- berechnungsproblem der beschleunigungsstruktur mit rein. sobald ich die pro frame habe, kann ich auch gleich ganz auf raytracing setzen. für den part der gerastert werden kann, sind die kosten des raytracings dann vernachlässigbar, oder?

[Coda]

bei rasterisierung bedeutet doppelte auflösung doch nicht doppelter rechenaufwand wenn die polygonanzahl gleich bleibt.
Naja, die Geometriearbeit bleibt die gleiche, aber die ist normalerweise eher "vernachlässigbar".

ist ein pathtracer, ne unterart, ich such mal infos.
Ein Pathtracer löst das Problem nicht und in den Slides finde ich auch keine gute Erklärung.

im worst case halt eben doch. angenommen dein komplettes level liegt in deinem viewfrustum. dann kannst du nix cullen beim rasterizer. jedes weitere polygon, das innerhalb hinzugefügt wird geht linear mit rein. beim raytracing hingegen logarithmisch.
Dafür hat man LOD. Das man eh braucht.

[Gast]

Dafür hat man LOD. Das man eh braucht.
das ändert aber nichts an der komplexität. ob raytracer jedoch jemals einen vorteil daraus ziehen werden, dass sie im worst case überlegen sind, steht natürlich auf einem anderen blatt.
die aussage von Chris Lux kann man jedoch nicht so stehn lassen.

[Chris Lux]

die aussage von Chris Lux kann man jedoch nicht so stehn lassen.
was ist daran falsch? auch wenn alles im viewing frustum liegt hat man x-fach verdeckungen.... und eben LOD. mit dieser folie hat man mich schon im studium zum lachen/weinen gebracht, weil es einfach unsinn ist.

[deekey777]

Wenn man schon eh Ratracing nutzt, warum dann immernoch Polygone und nicht was anderes?

[Chris Lux]

weil ein strahl-dreieck schnitt billiger ist als die evaluation einer parametrischen oberfläche. und weil das modellieren mit subdivision surfaces intuitiver ist.

[Gast]

was ist daran falsch? auch wenn alles im viewing frustum liegt hat man x-fach verdeckungen.... und eben LOD. mit dieser folie hat man mich schon im studium zum lachen/weinen gebracht, weil es einfach unsinn ist.
nein es ist kein unsinn, denk nochmal drüber nach. algorithmische komplexität wird immer nach dem worst-case bestimmt und da stimmt die folie. ob das realitätsfremd is oder nicht spielt da keine rolle.

[del_4901]

nein es ist kein unsinn, denk nochmal drüber nach. algorithmische komplexität wird immer nach dem worst-case bestimmt und da stimmt die folie. ob das realitätsfremd is oder nicht spielt da keine rolle.
Was ist denn das fuer ein Schwachsinn... Seit wann wird bitteschoen der worst case genommen? Man nimmt natuerlich den average case! Sonst haette Quicksort ja die gleiche Komplexitaet wie Bubblesort (im worst case). Aber zurueck zum rendering: Durch early Z und predicated rendering haben rasterizer heutzutage sehr wenig overdraw.

[Fragman]

Ein Pathtracer löst das Problem nicht und in den Slides finde ich auch keine gute Erklärung.


wie das im technischen detail geloest ist behaellt fajardo verstaendlicherweise fuer sich. mehr infos wirds sicher bei release geben. aktuell gibt er nicht viele infos raus, will natuerlich den code und die tech dahinter schuetzen.
ein paar infos gibts hier noch, aber wie gesagt, details ala siggrpah tech paper gibts aktuell noch nicht, da closed beta.

http://tog.acm.org/resources/RTNews/html/rtnv23n1.html#art3

[Gast]

Lachhaft ist auch die Latenz, seht mal wie lange es braucht wenn er eine Taste drückt bis sich auch am Bild etwas verändert, und die Server sollen mit GBit angeschlossen sein und direkt dahinter stehen?

Wie soll das dann mit weniger guten Verbindungen funktionieren? (Oder glaubt Intel jeder stellt sich jetzt seinen eigenen Server in den Keller um auf annehmbare Lags zu kommen?)

[Tesseract]

Könntest du das mal genauer ausführen, irgendwie verstehe ich nicht warum. :/
weil es relativ ineffizient ist ein polygon zu rasterisieren, dass nur wenige pixel abdeckt. (oder gar nur subpixel)
außerdem besteht dann ein viel größerer prozentsatz des bildes aus polygonkanten, was für viele optimierungen (z.B. beim multisampling) nicht gerade günstig ist.
der unterschied ist zwar nicht all zu groß, aber vorhanden.

Wie soll das dann mit weniger guten Verbindungen funktionieren?
garnicht. die ganze idee ist ein luftschloss. es ist bei heutiger infrastruktur oft nichtmal möglich ein paar tausend leute (MMO-server) zuverlässig mit positions- und anderen steuerdaten zu versorgen.
ich frag mich bis heute wem dieser schwachsinn eingefallen ist. diejenigen werden damit so hart auf die fresse fallen...

[Gast]

Was ist denn das fuer ein Schwachsinn... Seit wann wird bitteschoen der worst case genommen? Man nimmt natuerlich den average case! Sonst haette Quicksort ja die gleiche Komplexitaet wie Bubblesort (im worst case). Aber zurueck zum rendering: Durch early Z und predicated rendering haben rasterizer heutzutage sehr wenig overdraw.
kein grund kraftausdrücke zu verwenden. lies dir einfach mal http://de.wikipedia.org/wiki/Komplexit%C3%A4t_%28Informatik%29 durch. wenn man "allgemein" von komplexität eines algorithmus' redet, ist das asymptotische verhalten im worst-case gemeint. und genau darauf beziehen sich die folien und meine aussagen. übrigens mit LOD, early-z usw drückst du nur den faktor "c", kommst aber nicht in eine andere komplexitätsklasse.

[del_4901]

kein grund kraftausdrücke zu verwenden. lies dir einfach mal http://de.wikipedia.org/wiki/Komplexit%C3%A4t_%28Informatik%29 durch. wenn man "allgemein" von komplexität eines algorithmus' redet, ist das asymptotische verhalten im worst-case gemeint. und genau darauf beziehen sich die folien und meine aussagen. übrigens mit LOD, early-z usw drückst du nur den faktor "c", kommst aber nicht in eine andere komplexitätsklasse.
Nun misch mal nicht die Landaunotation mit der Komplexitaetstheorie, nur weil du ein Semster Theoretische Informatik belegt hast. Zumal Raytracing wie auch Rasterisierung in der Komplexitaetsklasse P liegen, was fuer die Praxis total irrelevant ist. Denn damit kann man ueberhaupt keine Aussage darueber treffen was bei vielen Dreiecken schneller oder langsamer ist.

[Tesseract]

übrigens mit LOD, early-z usw drückst du nur den faktor "c", kommst aber nicht in eine andere komplexitätsklasse.
das hängt davon ab was du genau machst. wenn z.B. der rechenaufwand quadratisch mit der objektanzahl steigt, das LOD (oder sichtbarkeit oder was auch immer) die anzahl der zu rendernden objekte jedoch logarithmisch reduziert hast du keinen quadratischen rechenaufwand mehr.

wenn man "allgemein" von komplexität eines algorithmus' redet, ist das asymptotische verhalten im worst-case gemeint.
wenn du von der komplexität eines algorithmus redest musst du dazu sagen unter welchen bedingungen, sonst ist die aussage unvollständig.

[Nasenbaer]

weil es relativ ineffizient ist ein polygon zu rasterisieren, dass nur wenige pixel abdeckt. (oder gar nur subpixel)
außerdem besteht dann ein viel größerer prozentsatz des bildes aus polygonkanten, was für viele optimierungen (z.B. beim multisampling) nicht gerade günstig ist.
der unterschied ist zwar nicht all zu groß, aber vorhanden.
Vorher hattest du noch gesagt, dass die Effizienz eines Rasterizers steigt, wenn die Dreiecke Subpixelgröße haben, jetzt führt das mitmal zu erhöhter Ineffizienz. :confused:

Aber davon mal abgesehen sind solche kleine Dreiecke eh unsinnig. Sinnvollerweise nutzt man LODs und dann kommt es erst gar nicht dazu.

[Tesseract]

Vorher hattest du noch gesagt, dass die Effizienz eines Rasterizers steigt, wenn die Dreiecke Subpixelgröße haben, jetzt führt das mitmal zu erhöhter Ineffizienz. :confused:
das hast du falsch verstanden: weil kleine polygone ineffizient sind, wirkt sich eine höhere auflösung günstig auf die effizienz aus. deswegen skaliert auflösung am rasterizer besser. ich hab damit immer die skalierung von der kleineren auf die größere auflösung gemeint.

[Nasenbaer]

das hast du falsch verstanden: weil kleine polygone ineffizient sind, wirkt sich eine höhere auflösung günstig auf die effizienz aus. deswegen skaliert auflösung am rasterizer besser. ich hab damit immer die skalierung von der kleineren auf die größere auflösung gemeint.
Ahh ja da war ja was - jetzt hats Klick gemacht. Thx :D

[Gast]

Nun misch mal nicht die Landaunotation mit der Komplexitaetstheorie, nur weil du ein Semster Theoretische Informatik belegt hast. Zumal Raytracing wie auch Rasterisierung in der Komplexitaetsklasse P liegen, was fuer die Praxis total irrelevant ist. Denn damit kann man ueberhaupt keine Aussage darueber treffen was bei vielen Dreiecken schneller oder langsamer ist.
WTF? keine ahnung was man da jetzt vermischen kann. das raytracing in P liegt, darum gehts jetzt wohl gar ned! bleib bitte beim thema und werd' ned persönlich. topic ist: bestimmung komplexität von algorithmen.
mich nervt halt echt, wenn du erst kommst mit "schwachsinn" und dann keine fakten bringst oder mit überheblichem getue ablenken willst.


Unter der Komplexität (auch Aufwand oder Kosten) eines Algorithmus versteht man in der Komplexitätstheorie seinen maximalen Ressourcenbedarf ... Die betrachteten Ressourcen sind fast immer die Anzahl der benötigten Rechenschritte (Zeitkomplexität) oder der Speicherbedarf (Platzkomplexität).(= worst case)


wieviel/welche quellen brauchst du noch?
oder gegenangebot: liefer mal ne quelle die deine behauptung stützt.

Was ist denn das fuer ein Schwachsinn... Seit wann wird bitteschoen der worst case genommen? Man nimmt natuerlich den average case! Sonst haette Quicksort ja die gleiche Komplexitaet wie Bubblesort (im worst case).

und komm mir bitte ned mit quicksort...

[Gast]

das hängt davon ab was du genau machst. wenn z.B. der rechenaufwand quadratisch mit der objektanzahl steigt, das LOD (oder sichtbarkeit oder was auch immer) die anzahl der zu rendernden objekte jedoch logarithmisch reduziert hast du keinen quadratischen rechenaufwand mehr.

lasst mal bitte das LOD weg. die polygonzahlen werden steigen. mit oder ohne LOD.


wenn du von der komplexität eines algorithmus redest musst du dazu sagen unter welchen bedingungen, sonst ist die aussage unvollständig.
also. ich weiss, dass man auf viele arten laufzeitbestimmungen machen kann. nichtsdestotrotz, und dass habe ich -denke ich- mit meiner quelle ausreichend dargelegt, bestimmt man die komplexität eines algorithmus gewöhnlich über den worst-case. ok, vllt war das "immer" das falsche wort und wäre besser ein "gewöhnlich" gewesen. vllt war es auch falsch den worst-case überhaupt mit reinzunhemen. der spielt nämlich eigentlich auch keine rolle.
der skalierungsvergleich (o(n) vs o(log n)) bleibt in der theorie immer! da könnt ihr noch so viel techniken bringen, die angeblich das egalisieren. man wird immer ein szenario entwerfen können bei dem der vergleich wieder stimmt. selbst wenn diese szenarien noch so realitätsfremd/selten sind.
und diese aussage
nur das diese graphik grober unfug ist. rasterizer (bzw. rendering software/engines) nutzen auch space partitioning strukturen fuers culling und dann ist deren aufwand auch nicht mehr linear.
stimmt einfach nicht. man kann zwar meist recht gut cullen, bleibt aber dennoch worst-case in o(n). hier ist auch der vergleich zu quicksort recht angebracht, eigentlich o(n*n) aber für die meisten fälle doch eher an o(n*log n) dran.

@Topic:
ihr braucht mich nicht zu überzeugen, dass rasterizer sinnvoller sind als raytracer. ich bin eurer meinung. aber die graphik müsst ihr ihnen lassen. sie stimmt halt einfach.

[del_4901]

Fakten wurden mehr als genug gebracht, du bist nur nie drauf eingegangen...

und komm mir bitte ned mit quicksort...
...ist nach vielen Statistiken der schnellste Algorithmus und wird deswegen so haeufig eingesetzt. (und das obwohl z.B. Merge Sort den besseren worst case hat)
@Topic:
ihr braucht mich nicht zu überzeugen, dass rasterizer sinnvoller sind als raytracer. ich bin eurer meinung. aber die graphik müsst ihr ihnen lassen. sie stimmt halt einfach.
Nur unter konstruierten Bedingungen (kein LOD -> flimmert wie die Hoelle, Rasterizer ohne Space Partitioning; und wenn man im Painters Algorithmus zeichnet). Genauso kann man aber auch den umgekehrten Fall konstruieren: Man koennte ja mal Raytracing ohne Space Partitioning antreten lassen?

[Nasenbaer]

Unter der Komplexität (auch Aufwand oder Kosten) eines Algorithmus versteht man in der Komplexitätstheorie seinen maximalen Ressourcenbedarf ... Die betrachteten Ressourcen sind fast immer die Anzahl der benötigten Rechenschritte (Zeitkomplexität) oder der Speicherbedarf (Platzkomplexität).(= worst case)
wieviel/welche quellen brauchst du noch?
oder gegenangebot: liefer mal ne quelle die deine behauptung stützt.
1. Dass (= worst case) interpretierst du da nur rein. Ich kann Speicherbedarf und Zeitkomplexität auch für den Best und Avg. Case betrachten. Man muss alle 3 Fälle betrachten und zu bewerten wissen sonst bringt dir das alles nichts. Es gibt viele Algorithmen einen miesen Worst case haben aber in den meisten Fällen sehr praktikabel sind. Also erzähl hier nichts vom Pferd.

2. Wikipedia ist sicher keine Quelle für wissenschaftliche Diskussionen. Ich würde jedenfalls nicht in der Diplomarbeit das Wiki als Quelle angeben. ;D

[Gast]

1. Dass (= worst case) interpretierst du da nur rein. Ich kann Speicherbedarf und Zeitkomplexität auch für den Best und Avg. Case betrachten. Man muss alle 3 Fälle betrachten und zu bewerten wissen sonst bringt dir das alles nichts. Es gibt viele Algorithmen einen miesen Worst case haben aber in den meisten Fällen sehr praktikabel sind. Also erzähl hier nichts vom Pferd.

da steht "maximalen Ressourcenbedarf" und "Die betrachteten Ressourcen sind fast immer die Anzahl der benötigten Rechenschritte". wie deutest du das? alles weitere was du da schreibst, haben wir jetzt schon weiter oben mit quicksort durchgekaut, hat ich auch nie was anderes behauptet. von daher: warum die wiederholung?


2. Wikipedia ist sicher keine Quelle für wissenschaftliche Diskussionen. Ich würde jedenfalls nicht in der Diplomarbeit das Wiki als Quelle angeben. ;D

jo sorry ich komm jetzt leider grad schlecht an digitale versionen von theoretischer info ran. mir war aber auch schon fast klar dass das wiki argument jetzt kommt. nichtsdestotrotz denke ich mal, dass so ein thema recht verlässlich auf wiki dokumentiert ist. meinst du nicht?
aber naja andere quelle:

Die Zeitkomplexität S(n) eines Algorithmus ist die Anzahl der Schritte, die der Algorithmus (im schlechtesten Fall) ausführen muss. Man spricht von der Laufzeit des Algorithmus.

Quelle:
http://www.saar.de/~awa/jeffizienz01.htm

aber wahrscheinlich ist das auch nicht wissenschaftlich genug.

[Gast]

Fakten wurden mehr als genug gebracht, du bist nur nie drauf eingegangen...

boah, ich geb auf. hab mir ja mühe gegeben hier. aber das führt jetzt echt zu nix. schad. naja. haut rein, jungs! und viel spass beim qualifizierten raytrace dissen.

[Gasti]

Wenn ich den Wert eines Algos vom Worstcase allein abhängig mache, ist das schlichtweg nicht praktikabel.
Das zu tun und anschließend eine nette Grafik daraus zu machen ist Marketing.

[Gast]

vergesst auch mal den worstcase. überlegt nochmal, warum die grafik auch so stimmt. sprecht mal mit 'nem grafikprofessor darüber. die beweisführung dazu ist auch kein einfaches topic und mir fehlt die zeit dass jetzt alles hier ausführlich darzulegen. vor allem weil dann wieder LOD usw kommt. was mit dem prinzip halt gar nix zu tun hat, weil es trotzdem mit der zeit ABSOLUT immer mehr dreiecke geben wird, die im viewfrustum (also für rasterizer trotz BSP nicht cullbar) liegen.

[Tesseract]

vor allem weil dann wieder LOD usw kommt. was mit dem prinzip halt gar nix zu tun hat, weil es trotzdem mit der zeit ABSOLUT immer mehr dreiecke geben wird, die im viewfrustum (also für rasterizer trotz BSP nicht cullbar) liegen.
es geht nicht darum ob es mehr werden sondern in welcher größenordnung. wenn A quadratisch mit B steigt und B logarithmisch mit C, dann steigt A nicht quadratisch mit C.
falls LOD sich so logarithisch verhält hast du keine mit der ungecullten menge quadratische laufzeit mehr. mehr hab ich nicht gesagt.

[Gast]

Nur unter konstruierten Bedingungen (Rasterizer ohne Space Partitioning; ...).
das ist fuppes. natürlich ist beim rasterizer auch BSP. bleibt trotzdem linear.
einfache rechnung: mein viewfrustum ist 90° in x und y. unendlich in die tiefe.
d.h. ich visualisiere 1/6 von der welt. füge ich jetzt n dreiecke hinzu, kann ich im besten fall 5/6 * n dreiecke dank BSP wegcullen, die nicht im frustum liegen. bleibe also in o(n) mit c=1/6. raytracer bleibt bei o(log n), klar.


wenn man im Painters Algorithmus zeichnet...

es geht hier nur um VSD. early-z, auf das du wieder mal abzielst, reduziert ja nur pixelshader und teilweise z-buffer writes, trotzdem muss ich alle polys reinhauen, oder?


kein LOD -> flimmert wie die Hoelle

ich hoffe es fällt euch langsam selber mal auf :(

[Gast]

es geht nicht darum ob es mehr werden sondern in welcher größenordnung. wenn A quadratisch mit B steigt und B logarithmisch mit C, dann steigt A nicht quadratisch mit C.
falls LOD sich so logarithisch verhält hast du keine mit der ungecullten menge quadratische laufzeit mehr. mehr hab ich nicht gesagt.
jo ich hab auch nix dagegen gesagt. nur dass ihr mal das LOD weglassen sollt, weil die polygonzahlen mit oder ohne steigen (zum x-ten mal jetzt). ob sie jetzt logarithmisch steigen, linear, quadratisch oder weiss der geier wie, spielt für den renderer ned die bohne eine rolle.

[del_4901]

Und wenn man schon den worst case behandelt, dann ist es essentiell das man auch die Haeufigkeit von diesem mit betrachtet. Denn der worst case fuer sich allein ist nur fuer theoretische Informatiker interessant.

das ist fuppes. natürlich ist beim rasterizer auch BSP. bleibt trotzdem linear.
einfache rechnung: mein viewfrustum ist 90° in x und y. unendlich in die tiefe.
d.h. ich visualisiere 1/6 von der welt. füge ich jetzt n dreiecke hinzu, kann ich im besten fall 5/6 * n dreiecke dank BSP wegcullen, die nicht im frustum liegen. bleibe also in o(n) mit c=1/6. raytracer bleibt bei o(log n), klar.
es geht hier nur um VSD. early-z, auf das du wieder mal abzielst, reduziert ja nur pixelshader und teilweise z-buffer writes, trotzdem muss ich alle polys reinhauen, oder?
Nein man muss eben nicht alle Polys reinhauen, zum einen nimmt die Anzahl mit der Entferung ab. Und zum anderen kann man mit predicated rendering auch sehr einfach occlusion culling realisieren. Und zum dritten sind die TecArtists eh dazu angehalten das occlusion culling nochmal (grob) mit der Hand zu machen. Das auf was du dich da beziehst sind alles hoch theoretische Dinge die in der Praxis keine Verwendung finden.

vergesst auch mal den worstcase. überlegt nochmal, warum die grafik auch so stimmt. sprecht mal mit 'nem grafikprofessor darüber. die beweisführung dazu ist auch kein einfaches topic und mir fehlt die zeit dass jetzt alles hier ausführlich darzulegen. vor allem weil dann wieder LOD usw kommt. was mit dem prinzip halt gar nix zu tun hat, weil es trotzdem mit der zeit ABSOLUT immer mehr dreiecke geben wird, die im viewfrustum (also für rasterizer trotz BSP nicht cullbar) liegen. Es gibt nach meiner Erfahrung wirklich wenige gute Grafikprofessoren in Deutschland. Aber nochmal zum Thema: Die Anzahl der Polys wird sich auch immer grob an der Aufloesung orientieren, da man es vermeiden moechte Polys zu haben die kleiner als die Pixel selber sind (aus Effizienzgruenden eigentlich kleiner als ein Pixelquad) da es sonst flimmert. Und solange das so bleibt wird der Break Even nicht erreicht.

[Coda]

das ist fuppes. natürlich ist beim rasterizer auch BSP. bleibt trotzdem linear.
einfache rechnung: mein viewfrustum ist 90° in x und y. unendlich in die tiefe.
d.h. ich visualisiere 1/6 von der welt. füge ich jetzt n dreiecke hinzu, kann ich im besten fall 5/6 * n dreiecke dank BSP wegcullen, die nicht im frustum liegen. bleibe also in o(n) mit c=1/6. raytracer bleibt bei o(log n), klar.
Oh junger Padawan, du musst noch viel lernen ;)

Es gibt da viele Techniken, dass man das nicht tun muss. PVS (http://en.wikipedia.org/wiki/Potentially_visible_set), Portale (http://en.wikipedia.org/wiki/Portal_rendering) oder Occlusion Queries.

Letzteres lässt sich auch in Software machen, indem auf der CPU eine sehr einfache Variante der Szene gerendet wird (ein Frame im Voraus) und daran dann die Nodes cullt. Das macht beispielsweise die Cryengine 3, aber soweit ich weiß auch Frostbite.

[Bietchiebatchie]

nur so nebenbei:

Raytracing ist auch O(n) im worst-case da man immer eine Szene und einen Blickwinkel findet in dem man mindestens einen Strahl mit (fast) allen Dreiecken kreuzen muss.


Wenn ich mich nicht total irre hab ich sogar mal ne Beschreibung gelesen wie man mit Raytracing Probleme lösen kann die NP-complete sind - allerdings war der 'Haken' hierbei dass die Abstände zwischen den einzelnen Objekten exponentiell wachsen dürfen.

[Gast]

leute, falls ihr es nicht merkt. das sind alles techniken um die anzahl der dreiecke im viewfrustum zu reduzieren. das interessiert in dieser debatte nicht. es geht um die anzahl der dreiecke die dargstellt werden NACH allem cullen und LOD usw. dort skaliert renderer o(n) und der raytracer o(log n). ich glaub ihr seid zu praxisorientiert, um das zu verstehen.

[Gast]

nur so nebenbei:
Raytracing ist auch O(n) im worst-case da man immer eine Szene und einen Blickwinkel findet in dem man mindestens einen Strahl mit (fast) allen Dreiecken kreuzen muss.

nein muss man nicht, erzähl keinen blödsinn. dafür ist BSP/KD-tree da.

[Gast]

leute, falls ihr es nicht merkt. das sind alles techniken um die anzahl der dreiecke im viewfrustum zu reduzieren. das interessiert in dieser debatte nicht. es geht um die anzahl der dreiecke die dargstellt werden NACH allem cullen und LOD usw. dort skaliert renderer o(n) und der raytracer o(log n). ich glaub ihr seid zu praxisorientiert, um das zu verstehen.
raytracing ohne culling bedeutet dass du pro ray jedes dreieck testest und dann skalierst du mit o(n).
raytracing wird erst schnell wenn du den ray gegen eine scenenhierarchy cullst.
beim rasterisieren cullt man nunmal andersrum, die scene gegen den z-buffer.

entsprechend ist rasterisieren ziemlich linear mit der anzahl der dreiecke (gewesen, heute ist kaum ein spiel vertex/triangle limitiert).
und entsprechend ist raytracing ziemlich linear mit der anzahl der rays/pixel die gegen die scene gecullt werden.

wenn man auf beiden seiten kein culling betreibt, ist rasterisieren schneller, da ein triangle setup in etwa den zeitaufwand einer triangle-ray intersektion hat, aber jeder test der dann auftaucht, ist beim rasterisieren sehr trivial und schneller als triangle-ray tests.

wenn du wirklich unmengen an polygonen haettest und 99% davon zeichnen kein pixel (und zwar nicht wegen overdraw sondern wegen zero-area), dann hast du eine chance dass ein raytracer gleich schnell ist, jedoch sind die chancen dann extrem gross dass soviel aliasing auftritt, dass man mehr samples pro pixel braucht, womit dann wieder ein rasterizer schneller wird.

[del_4901]

leute, falls ihr es nicht merkt. das sind alles techniken um die anzahl der dreiecke im viewfrustum zu reduzieren. das interessiert in dieser debatte nicht. es geht um die anzahl der dreiecke die dargstellt werden NACH allem cullen und LOD usw. dort skaliert renderer o(n) und der raytracer o(log n). ich glaub ihr seid zu praxisorientiert, um das zu verstehen.
Das was du grade screibst ist selbst fuer einen Theoretiker zu ungenau. Wenn man genau ist, dann ist fuer rasterisierung der Aufwand O(n*m) wobei n Anzahl der Dreiecke und m die durchschnittliche Pixelanzahl pro Dreieck. Fuer den Raytracer sind wir dann bei O(m log n). n bleibt die Anzahl der Dreiecke und m ist die Anzahl der Pixel pro Bild. Wenn die Anzahl (n) der Dreiecke zunimmt, dann geht m fuer den Rasterizer gegen 1 (wir wollen nicht flimmern) waehrend es fuer den Raytracer konstant bleibt. Und solange die Anzahl der Dreiecke nich sehr viel groesser (um genau zu sein um log(Anzahl der Pixel pro Bild) wird, ist Rasterizierung immernoch schneller. Bei Full HD braucht man also einen durchschnittlichen Overdraw von 21, bei einer Dreiecksgroesse von einem Pixel, um den Break Even zu erreichen. Bei einem Pixelquad sind es schon ueber 80. Siehst du nun dein Dilema? Und da ist jetzt noch nicht der hoehere konstante Zeitaufwand fuer die Rayintersection Tests ggue. dem konstanten Aufwand fuers rastern mit reingerechnet.

[Gast]

AlphaTier, dass ist nicht MEIN dilema. das ist das dilema der leute die raytracer verkaufen wollen. es ändert aber nichts an der skalierung mit der anzahl an polygonen. die ganze debatte hier ist entstanden, weil Chris Lux behauptet hat (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8266036&postcount=357) der aufwand wäre für rasterizer nicht mehr linear, wenn man BSP auch da einsetzt.
und ich habe das verneint, sonst nichts.

allgemein scheinen hier viele zu denken die grafik wäre ja ein unfairer vergleich, da sie beim rasterizer ja keine beschleunigungsstuktur eingesetzt haben. das ist aber natürlich nicht der fall. sowohl raytracer als auch rasterizer setzen BSP ein um effizienter zu sein. und trotzdem bleibt es bei der skalierung

[Bietchiebatchie]

nein muss man nicht, erzähl keinen blödsinn. dafür ist BSP/KD-tree da.

Für einen normalen axis-aligned-kd-tree kannst du dir n parallele (gleich große) dreiecke die auf einer Geraden liegen welche nicht orthogonal zu einer Achse ist vorstellen. wenn du nun einen strahl verfolgst der der sehr nahe parallel an den dreiecken vorbeigeht musst du im kd-tree alle dreiecke abarbeiten.

also folgendermaßen in 2d; <| = dreieck:
<|
<|
<|
<|
<|
<|


strahl verfolgen; \ = strahl
<| \
<| \
<| \
<|
<|
<|

logischerweise müssen im kd-tree nun alle Blätter besucht werden.

Für komplizierte Hierarchien entsprechend kompliziertere Gegenbeispiele.

[Gast]

raytracing ohne culling ...
ich rede hier die ganze zeit davon, dass beschleunigungsstrukturen, sowohl beim raytracer als auch beim rasterizer, verwendet werden...

[Neomi]

Was viele von den "Raytracing ist nur O(log n)" Leuten vergessen: der Szenenbaum muß auch erstmal aufgebaut werden. Wenn man eine extrem dynamische Szene hat, in der sich so ziemlich alles bewegt, sogar vollständig pro Frame. Entweder muß man diesen Rechenaufwand auch mit reinnehmen, dann ist man auf einmal bei O(n), weil zur Berechnung des Baums jedes Dreieck angepackt werden muß, je nach Baumart auch mehr. Oder man berücksichtigt den Rechenaufwand nicht, dann darf man aber dessen Ergebnis auch nicht zur Beschönigung der O-Notation verwenden, sondern muß ohne Baum alle Dreiecke testen. Und auch dann ist man wieder bei O(n).

[Chris Lux]

AlphaTier, dass ist nicht MEIN dilema. das ist das dilema der leute die raytracer verkaufen wollen. es ändert aber nichts an der skalierung mit der anzahl an polygonen. die ganze debatte hier ist entstanden, weil Chris Lux behauptet hat (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8266036&postcount=357) der aufwand wäre für rasterizer nicht mehr linear, wenn man BSP auch da einsetzt.
und ich habe das verneint, sonst nichts.
...und ich stehe zu meiner aussage. denken wir doch mal weiter, und nutzen deine argumentation: wir sollen mit einem rasterizer mal angenommen ein 1:1 pixel:triangle verhältnis erreichen. also nutzen wir unsere culling und LOD techniken um auf einem aktuellen full-HD panel ~2mio triangles zu erzeugen. der aufwand ist also O(2mio triangles) = O(1) für einen aktuellen renderer auf basis eines rasterizers. und nun? dein ray tracing ist immer noch O(log n), weil dort jeder strahl durch die ganze szene gehen muss/kann.

sicher nicht ganz die realität, aber deiner argumentation gefolgt.

[Coda]

leute, falls ihr es nicht merkt. das sind alles techniken um die anzahl der dreiecke im viewfrustum zu reduzieren. das interessiert in dieser debatte nicht. es geht um die anzahl der dreiecke die dargstellt werden NACH allem cullen und LOD usw. dort skaliert renderer o(n) und der raytracer o(log n). ich glaub ihr seid zu praxisorientiert, um das zu verstehen.
Ich versteh das schon. Es spielt nur überhaupt keine Rolle, da es hier um Realtime Raytracing für reelle Anwendungen geht.

Das O(log n) kommt ja erst zum tragen, wenn man wirklich wesentlich mehr Dreiecke als Pixel darstellen will. Das ist mit Culling bei einem Rasterizer aber nicht der Fall, außerdem will man es auch überhaupt nicht, weil es flimmern würde.

Was viele von den "Raytracing ist nur O(log n)" Leuten vergessen: der Szenenbaum muß auch erstmal aufgebaut werden. Wenn man eine extrem dynamische Szene hat, in der sich so ziemlich alles bewegt, sogar vollständig pro Frame. Entweder muß man diesen Rechenaufwand auch mit reinnehmen, dann ist man auf einmal bei O(n), weil zur Berechnung des Baums jedes Dreieck angepackt werden muß, je nach Baumart auch mehr. Oder man berücksichtigt den Rechenaufwand nicht, dann darf man aber dessen Ergebnis auch nicht zur Beschönigung der O-Notation verwenden, sondern muß ohne Baum alle Dreiecke testen. Und auch dann ist man wieder bei O(n).
Baum bauen ist mindestens bei O(n log n).

[Gast]

Was viele von den "Raytracing ist nur O(log n)" Leuten vergessen: der Szenenbaum muß auch erstmal aufgebaut werden. Wenn man eine extrem dynamische Szene hat, in der sich so ziemlich alles bewegt, sogar vollständig pro Frame. Entweder muß man diesen Rechenaufwand auch mit reinnehmen, dann ist man auf einmal bei O(n), weil zur Berechnung des Baums jedes Dreieck angepackt werden muß, je nach Baumart auch mehr. Oder man berücksichtigt den Rechenaufwand nicht, dann darf man aber dessen Ergebnis auch nicht zur Beschönigung der O-Notation verwenden, sondern muß ohne Baum alle Dreiecke testen. Und auch dann ist man wieder bei O(n).
He, nicht so viel Zeit in Foren rumhängen, sondern NICE 3 entwickeln!!

[Neomi]

Baum bauen ist mindestens bei O(n log n).

Bei einem vernünftig ausbalancierten gilt das, es geht aber auch mit O(n). Ein fixiertes Grid ist ja letztendlich auch nichts großartig anderes als ein Octree mit fixierter Rekursionstiefe. Wobei in dem Fall die Strahlverfolgung selbst wieder in Richtung O(n) geht.

[KiBa]

ohoh, hier scheint ein Gast aber viel Unsinn zu verzapfen, da muss ich meinen Senf auch noch gleich dazugeben (sorry, wenn es sich wiederholt):

Ohne Beschleunigungsstrukturen haben beide Verfahren O(n), das sollte klar sein.
Selbst mit Bäumen haben beide Verfahren immer noch im Worst-Case O(n), man stelle sich einfach 1000 koplanare Dreiecke vor.
Im Average-Case und unter guter Ausnutzung der Hierarchie (Occlussion-Culling) haben beide Verfahren O(log(n)).
Der Unterschied ist, dass Raytracing pixelgenaues OC macht, es bei Rasterisierung aber meist auf Objektebene gemacht wird. Das verschlechtert den Overdraw zwar etwas gegenüber Raytracing (ca. um Faktor 2-3), der Faktor bleibt aber in realistischen Szenen konstant (bei steigender Dreiecksanzahl). Rasterizing wird damit immer schneller bleiben als Raytracing, solange die Dreiecke nicht wesentlich kleiner als (Sub-)Pixel werden, aber dafür sorgt ja das LOD.

[Geldmann3]

Dieses Bild wurde mit Raytracing gerendert.
http://img259.imageshack.us/img259/8255/alexclass.jpg
Quelle: http://de.wikipedia.org/wiki/Raytracing

Für mich schon sehr beeindruckend, ich würde das Bild für echt halten...

[DR.ZEISSLER]

die frage ist nur, wie lange ein schneller rechner dafür gebraucht hat.

[Nasenbaer]

Für mich schon sehr beeindruckend, ich würde das Bild für echt halten...
Eindeutig unecht. Es fehlt ja schon das Gekrakel auf den Tischen. X-D

Außerdem ist es kein "einfaches" whitted Raytracing wie man es mit den Larrabee-Überresten versucht zu beschleunigen, sondern es wurden für das Bild eindeutig Global-Illumination-Verfahren verwendet und das ist sehr weit außerhalb jeder Echtzeitfähigkeit.

[Henroldus]

Dieses Bild wurde mit Raytracing gerendert.
http://img259.imageshack.us/img259/8255/alexclass.jpg
Quelle: http://de.wikipedia.org/wiki/Raytracing

Für mich schon sehr beeindruckend, ich würde das Bild für echt halten...
ja und? gibts seit Jahrzehnten, ist nur eine Frage der Rechentiefen und wie lange dran gerendert wurde.
Bis sowas in Echtzeit kommt vergehen nochmal 10 Jahre....

[deekey777]

Dieses Bild wurde mit Raytracing gerendert.
http://img259.imageshack.us/img259/8255/alexclass.jpg
Quelle: http://de.wikipedia.org/wiki/Raytracing

Für mich schon sehr beeindruckend, ich würde das Bild für echt halten...
Und was hat das mit dem Thema zu tun?

[Fragman]

die frage ist nur, wie lange ein schneller rechner dafür gebraucht hat.

auf cgtalk den thread raussuchen, dort kann man dann sehen wie lange sowas dauert. und gerade "classroom" zeigt das raytracing in dieser quali noch viele viele jahre weit weg ist vom status realtime. wenn man die szene mal als benchmark her nimmt ist die diskussion an dem beispiel in hinblick auf realtime sogar etwas laecherlich. ;)

[pest]

Wenn man nicht gerade in Echtzeit am Sonnenstand drehen will, kann man sich den Großteil der Rechenzeit sparen indem man statische Lightmaps benutzt die vorher berechnet werden.
Die neueste Version der UE3 zeigt ja eindrucksvoll was damit möglich ist.

[Coda]

Das geht auch mit Sonnenstand drehen, wenn man Spherical-Harmonic-Lightmaps einsetzt :)

[Fragman]

wobei das schon wieder weit weg von dem ist was pohl ja immer zeigen will, reines raytracing. ich verstehe auch nicht weshalb er nicht mal realistisch ist und etwas brauchbares zeigt, hybridengine zb. aber vielleicht will er auch nur die jahre aussitzen und kurz vor dem ruhestand seinen techerfolg "feiern". ;)

[derpinguin]

Dieses Bild wurde mit Raytracing gerendert.
http://img259.imageshack.us/img259/8255/alexclass.jpg
Quelle: http://de.wikipedia.org/wiki/Raytracing

Für mich schon sehr beeindruckend, ich würde das Bild für echt halten...
Tafel sieht unecht aus, Lampen auch, auf den ersten Blick. Und wenn einem das aufgefallen ist, sieht der Rest auch künstlich aus.

[Menace]

Für ein echtes Foto fehlen so manche Unzulänglichkeiten (z.B. geringer Kontrastumfang). Die Ausbeleuchtung ist viel zu gleichmäßig, die Fenster überstrahlen nicht. Das ginge selbst mit einem HDR-Foto kaum.

[Tesseract]

Tafel sieht unecht aus, Lampen auch, auf den ersten Blick. Und wenn einem das aufgefallen ist, sieht der Rest auch künstlich aus.

an dem bild sieht alles unecht aus. auch auf den ersten blick. das fängt bei den vollkommen falschen, harten schatten an, geht bei der vollkommen übertriebenen global illumination weiter und hört bei den bunten farben und der sterilität des ganzen raums auf.

das einzige was den raum halbwegs realistisch erscheinen lässt ist das fast komplette fehlen von aliasingartefakten was wohl auf massives supersampling und hohe rekursionstiefen hindeutet. beides ist fürs echtzeitrenderung der tod.

[deekey777]

Tja, mit einem Larrabee wäre das nicht passiert. X-D

[aths]

an dem bild sieht alles unecht aus. auch auf den ersten blick. das fängt bei den vollkommen falschen, harten schatten an, geht bei der vollkommen übertriebenen global illumination weiter und hört bei den bunten farben und der sterilität des ganzen raums auf.

das einzige was den raum halbwegs realistisch erscheinen lässt ist das fast komplette fehlen von aliasingartefakten was wohl auf massives supersampling und hohe rekursionstiefen hindeutet. beides ist fürs echtzeitrenderung der tod.Da sieht nicht alles unecht aus. Auf den ersten Blick fragt sich der ungeübte Beobachter, ob das wirklich computerberechnet sein kann oder nicht doch ein Foto ist. Wer natürlich etwas mehr CGI-Erfahrung hat, sieht sofort, wie synthetisch das Bild ist.

Aber die Anforderungen an Fotorealismus ändern sich mit der Entwicklung. Zu Zeiten von Gran Turismo fragte man sich ob das wirklich ein Playstation-Spiel ist oder man gerade eine TV-Übertragung sieht. Dabei hat das Game nicht mal gefilterte Texturen, geschweige denn perspektivisch korrigierte. Man hielt es aber für beinahe unmöglich, das in Echtzeit auf einer Konsole zu bringen, also enstand die optische Täuschung von Beinahe-Fotorealismus.

Ein ähnlicher Effekt trifft auf das verlinkte Bild zu. Ich finde es zum Schreien synthetisch, andere wundern sich womöglich ob das nicht doch ein Foto sein könnte.

[Grey]

Experimental Cloud-Based Ray Tracing (auch von Pohl)

http://www.gamasutra.com/view/feature/6322/sponsored_feature_changing_the_.php

[Nasenbaer]

Experimental Cloud-Based Ray Tracing (auch von Pohl)

http://www.gamasutra.com/view/feature/6322/sponsored_feature_changing_the_.php
Wurd auch schon auf Computerbase (http://www.computerbase.de/artikel/grafikkarten/2011/bericht-ray-tracing-4.0) veröffentlicht - zudem auf Deutsch, falls jemand dem Englischen nicht so angetan ist. ^^

Ändert jedenfalls nichts daran, dass seine Engine nach wie vor genauso crappy ist. Früher verglich er sich mit aktuellen AAA-Titeln und heute macht er genau das gleiche und stöpselt nur nen Streaming-Dienst oben drauf. Den Nutzen von Raytracing in diesem Bereich kann er dennoch weiterhin nicht plausibel darlegen. Abgesehen von der Tatsache, dass sich einige Effekte leichter programmieren lassen, gibt es keine wirklichen Vorteile.

[Demirug]

Experimental Cloud-Based Ray Tracing (auch von Pohl)

http://www.gamasutra.com/view/feature/6322/sponsored_feature_changing_the_.php

Wenn ich mit sowas meinem Boss komme fragt er mich was eine Stunde Spielzeit pro Spieler kosten würde und das sieht nicht gut aus. Selbst wenn ich die Knights Ferry Karten noch außen vor lasse kostet die Rechenpower von so einem Rechner in der Cloud mehr als $2 pro Stunde (es wurden 4 verwendet). Die 25 bis 50 Cent für den Datentransfer fallen dann sowieso nicht mehr so sehr ins Gewicht.

[Grey]

Jup. Mehr als eine interessante Untersuchung ist es immer noch nicht.

[Coda]

Hat aber auch nicht viel mit Raytracing zu tun.