Neue Technologie ermöglicht beim Raytracing 30-mal höhere Grafikbeschleunigung

[M@TRIX™]

Eine neue interaktive Visualisierungstechnik, das sogenannte Echtzeit-Ray-Tracing, wird jetzt für die Welt der Computerspiele interessant. Informatikern der Universität des Saarlandes ist es erstmals gelungen, diese Technologie auf programmierbaren Grafikkarten, den GPUs, einzusetzen: Interaktives Ray-Tracing ist somit auch auf einem einzelnen Computer möglich.

mehr:
http://www.pcgames.de/?article_id=563062

Hört sich aufjedenfall interessant und vielversprechend an.

[Gast]

Raytracing in Echtzeit ist schon lange möglich (siehe CPU Raytracing), aber das bedeutet noch lange nicht, es ist praxistauglich.

Die Frage wäre, für welche Auflösung die Rohpower ausreichend ist...

[Cubitus]

bei CB gibts einen Artikel darüber
http://www.computerbase.de/artikel/software/2007/bericht_raytracing_spielen/

[tombman]

naja, 11 Millionen Strahlen pro Sek. ist aber nicht viel. Man braucht schon 30 Mille. Strahlen bei 1280x720 in 30fps.
Und Strahlen können sich ja auch vervielfältigen, je nach Oberfläche...

Ich will mal 1 Milliarde Strahlen pro Sekunde- dann würd was weitergehen ;)

Hmm, aber die sind ja auf der Cebit- da bekommt man ja direkt mal Lust hinzufahren und mit denen zu reden ;)

[Gast]

naja, 11 Millionen Strahlen pro Sek. ist aber nicht viel. Man braucht schon 30 Mille. Strahlen bei 1280x720 in 30fps.
Ohne Schatten oder sonstwas.
Dafür hat man dann die ganze Shaderleistung eingesetzt um den festverdrahteten und kleinen Rasterizer zu ersetzen.
log(n) ist natürlich sehr schön, aber die Konstante vornedran bricht Raytracing immer noch das Genick.

[Demirug]

naja, 11 Millionen Strahlen pro Sek. ist aber nicht viel. Man braucht schon 30 Mille. Strahlen bei 1280x720 in 30fps.
Und Strahlen können sich ja auch vervielfältigen, je nach Oberfläche...;)

Es sind nur 23.592.960. Ja, ich weiß das ich im Klugscheißermodus bin. Kommt wohl daher dass ich seit drei Wochen mit 0,00X ms Werten herum jonglieren muss.

[Gast]

Es sind nur 23.592.960. Ja, ich weiß das ich im Klugscheißermodus bin. Kommt wohl daher dass ich seit drei Wochen mit 0,00X ms Werten herum jonglieren muss.
Ich hoffe da arbeitest du genauer.
Es sind immerhin 27.648.000.

[E.T.]

er hat offensichtlich mit xga gerechnet und nocht mit 720p

---

in der news schreiben sie, dass bis zu 50 mio möglich sind, abhängig von der komplexität des bildes, der anzahl polgonen?

[tombman]

er hat offensichtlich mit xga gerechnet und nocht mit 720p

---

in der news schreiben sie, dass bis zu 50 mio möglich sind, abhängig von der komplexität des bildes, der anzahl polgonen?
ALso ich schätze es wird noch laaange dauern bis RT besser aussieht als was man in realtime mit derzeitigen Methoden machen kann...leider.

[Bokill]

... in der news schreiben sie, dass bis zu 50 mio möglich sind, abhängig von der komplexität des bildes, der anzahl polgonen? Du wirst dich wundern ... aber im dortigen Artikel ist die ganze Zeit die Rede von Strahlen.

Poligone und Raytracig haben in dem Zusammenhang nichts mehr miteinander zu tun.

Die Forschungsgruppe hat schon seit wenigen Jahren "Echtzeitrenderer" mit FPGAs gemacht. Das Problem bei Raytracing ist die ständige Bewegungsanpassung an dem Spielverlauf.

Ein Spiel muss im hohen Masse ja "interaktiv" sein, da ist ein hübscher Wasserfall, oder eine Wasseroberfläche für deren Raytraycing kein Problem ... Kommen aber Spielfiguren dazu, die zu allem Unglück noch durch die Spieler bewegt wereden ... tauchen noch ganz andere Probleme auf.

Steht aber auch im Computerbaseartikel drin.

MFG Bobo(2007)

[ScottManDeath]

Polygone und Raytracig haben in dem Zusammenhang nichts mehr miteinander zu tun.


Naja, ganz so stimmt das nicht. Die Komplexitaet von Raytracing steigt linear mit der Anzahl der (primaeren) Strahlen (welche wiederrum von der Aufloesung abhaengt) und logarithmisch mit der Anzahl der Dreiecke in der Szene an.

[derRäuber]

Es hat schon einen sehr gut durchdachten Grund, dass selbst bei Kinoproduktionen für die meisten Szenen Scanline-renderer genutzt werden.

[Gast]

Naja, ganz so stimmt das nicht. Die Komplexitaet von Raytracing steigt linear mit der Anzahl der (primaeren) Strahlen (welche wiederrum von der Aufloesung abhaengt) und logarithmisch mit der Anzahl der Dreiecke in der Szene an.
Nur dass bei Rasterisierung praktisch die Anzahl der Polygone dank LOD auch sinkt und man auf log( n ) für die gesamten Szenenkomplexität kommt. Raytracing könnte hier log(log( n )) rausschlagen. Allerdings müssten sie da von ihrem Standpunkt "Anzahl der Polygone ist praktisch egal; LOD ist unnötig" herunterkommen. Wäre auch für das Geflimmere ganz zuträglich.

[Gouvernator]

Die ganze Bilder die ich gesehen hab waren vom Content her sehr gut, schön aufgelöst und sehr detailiert was ja wohl nix mit raytracing zu tun hat. Aber das Eindruck entsteht es kommt wegen raytracing zustande...

[Coda]

Naja, ganz so stimmt das nicht. Die Komplexitaet von Raytracing steigt linear mit der Anzahl der (primaeren) Strahlen (welche wiederrum von der Aufloesung abhaengt) und logarithmisch mit der Anzahl der Dreiecke in der Szene an.
Mit vernünftigem LOD (Flimmern ahoi, bei den ganzen SaarCOR-Demos) haben Raytracer dadurch aber auch kaum noch einen Vorteil.

Hinzu kommen die Probleme mit dynamischer Geometrie. Vertex- und Geometryshader wie wir sie von Rasterizern kennen sind da so wohl gar nicht machbar (außer man schränkt ein in welchem Bereich sich die Vertices befinden können, was aber auch die Effizenz des verwendeten Szenenbaums wieder verschlechtert).

Ich glaube an Raytracing nur als Zusatz von Rasterizern (also z.B. Berechnung im Pixelshader wenn's nötig ist - geht evtl. sogar schon mit D3D10 recht gut).

[Demirug]

Ich hoffe da arbeitest du genauer.
Es sind immerhin 27.648.000.

Ja ich habe 1024*768 gelesen. Kam wohl daher das ich den ganzen Tag mit dieser Auflöung gerechnet hatte

[Gast]

ALso ich schätze es wird noch laaange dauern bis RT besser aussieht als was man in realtime mit derzeitigen Methoden machen kann...leider.

Wenn es mit dem rasanten Tempo der Hardwareentwicklung so weitergeht wie bisher; 5 Jahre?

[Gmax]

Eine Engine mit real time Global Illumination gibts schon:

http://www.fantasylab.com/newPages/FantasyEngineFeatures.html

[ScottManDeath]

Es hat schon einen sehr gut durchdachten Grund, dass selbst bei Kinoproduktionen für die meisten Szenen Scanline-renderer genutzt werden.

Ja, die Pixar Leute waren vor einer Weile auf dem Campus und haben ein bischen aus dem Naehkaestchen geplaudert. Cars war ihr erster Film bei dem sie nach der Rasterisierung (sie machen aus allem Mikropolygone) Raytracing fuer die Reflektionen der Autos genommen haben, weil es mit Environment mapping shice aussah. Allerdings war der Performance hit durch die secondary Rays fuer Reflektionen und Ambient Occlusion ein Grund dafuer, dass sie es nur recht spaerlich eingesetzt haben. Sie meinten, dass in ueberschaubarer Zukunft Rasterization fuer die "primary Rays" und danach Raytracing fuer ausgewaehlte Spezialeffekte eingesetzt werden wird.

OT: Die Szene mit den vielen Autos in dem Stadium war auch ein poeser Hack, sie haben die Autos in einige Gruppen unterteilt, die durchmischt und alle in einer Gruppe die selbe Animation darstellen lassen. Dabei war nur ein Auto in der Gruppe Geometrie, der Rest waren nur Quader mit spezielen Texturen/Tiefentexturen.

[Coda]

Auch OT: Was sind denn "Mikropolygone"?

[micki]

Auch OT: Was sind denn "Mikropolygone"?
polygone die so klein sind dass sie eventuell kein pixelmittelpunkt schneiden.

schon lustige angaben, das mit den strahlen, also ich hab heute bei 1024*1024 mit ca 40 fps (ohne pixel zu ueberspringen) ein model aus ca 3000 primitiven getraced (es hat ca 50% des screens abgedeckt) und die meiste zeit hat das schading gebraucht.

(ohne sse, ohne mmx, singlecore amd64 bei 2.4GHz... es war nur ein kleiner prototyp)


die angaben da sind also mal wieder total nutzlos.

[tokugawa]

Irgendwie sind die Einschätzungen des Autors bezüglich wie es die Spieleprogrammierung vereinfacht ziemlich für den A***, blauäugig und naiv.

Außerdem gibt's GPU-Raytracing eh schon länger... mir war nur nicht bewußt wie die das auf aktuellen GPUs für Szene-Rendering verwenden (ich kenn's als Methode, um Reflexionen/Refraktionen physikalisch korrekt zu berechnen).

[Coda]

Überhaupt. Was soll das mit der "Neuen Technologie" in der Überschrift? Seit wann gibt's Raytracing jetzt? 100 Jahre? Steinzeit? Kambrium?

[deekey777]

Besser?

Wenn man den CB-Artikel liest (den es schon länger auf Englisch gab), so ist die "Farbe" nicht das einzige Einsatzgebiet des Raytracing: Man könnte auch eine bessere Kollisionsabfrage per Raytracing programmieren (ob Stahl oder Kugel, ist doch egal).

[Coda]

Immer noch Käse, weil im Artikel steht ja "Eine neue interaktive Visualisierungstechnik, das sogenannte Echtzeit-Ray-Tracing, wird jetzt für die Welt der Computerspiele interessant.". Was ist daran neu? Eine Kugel konnte ich in 100x100 wohl auch auf nem 486 in Echtzeit tracen. Aber auch egal.

Was genau ist an der heutigen Kolissionsabfrage denn "schlecht"? Ich kenn mich damit nicht aus, aber wenn Raytracing dafür gut funktioniert wird es eh schon eingesetzt (wenn auch nicht in Hardware).

[tokugawa]

"Raytracing" für Kollisionen wird sowieso schon benutzt. Nennt man halt Raycasting, weil man halt sinnvollerweise die Anzahl der Rays die man schießt, soweit reduziert wie möglich.

Der Artikel ist allerdings hauptsächlich Käse in seiner Analyse was das für die Spieleentwicklung bedeutet. Was die da schreiben stimmt einfach nicht.

[micki]

"Raytracing" für Kollisionen wird sowieso schon benutzt. Nennt man halt Raycasting <-> weil man halt sinnvollerweise die Anzahl der Rays die man schießt, soweit reduziert wie möglich.du nennst es raycasting weil man moeglichst wenig strahlen verwendet? also bisher war die gaengige definition dass bis zum ersten hit es nur raycasting ist und sobald man dann rekursiv weiter den strahl verfolgt, ist es tracing.
oder hast du das damit ausgesagt und ich steh auf dem schlauch?

[micki]

Was genau ist an der heutigen Kolissionsabfrage denn "schlecht"? Ich kenn mich damit nicht aus, aber wenn Raytracing dafür gut funktioniert wird es eh schon eingesetzt (wenn auch nicht in Hardware).es gibt einen wichtigen unterschied, beim raytracen versuchst du (ausser vielleicht bei manchen schatten algos) genau rauszufinden wo der strahl auf was auftrifft, bei kollisionsberechnungen reicht es sehr oft aus nur zu testen ob es ueberhaupt einen treffer gab. z.b. bullet gegen actor, oder sichtlinien tests zwischen actors.
das macht so einiges sehr viel schneller, z.b. werden formeln simpler und das caching effektiver (da man nicht DAS getroffene element suchen muss, sondern irgend eines).

[tokugawa]

<->du nennst es raycasting weil man moeglichst wenig strahlen verwendet? also bisher war die gaengige definition dass bis zum ersten hit es nur raycasting ist und sobald man dann rekursiv weiter den strahl verfolgt, ist es tracing.
oder hast du das damit ausgesagt und ich steh auf dem schlauch?

Ich verwende die Begriffe weniger "getrennt". Ist ja auch kaum ein Unterschied. Aber trotzdem hast du recht dass Raycasting nur eine Strahlverfolgung bis zum ersten Treffer, während "Tracing" ein allgemeinerer Begriff ist (sprich, n = 1...unendlich, sprich auch Raycasting inkludierend).

Aber ich hab genau das damit ausgesagt, da jeder weitere Bounce nach einem Treffer ein weiterer Raycast ist, und man dies ja reduzieren will (und für Collision Detection sowieso eigentlich nur der erste Treffer relevant ist).

[Gast]

Was genau ist an der heutigen Kolissionsabfrage denn "schlecht"? Ich kenn mich damit nicht aus, aber wenn Raytracing dafür gut funktioniert wird es eh schon eingesetzt (wenn auch nicht in Hardware).
Man verspricht sich die Physikgeometrie sparen zu können.
Je nach Genre hat man inzwischen ja mindestens 3 Weltrepräsentationen: Grafik, Physik, NavMesh + weitere für KI oä..
Jedes Einsparpotential ist da von Entwicklern gern gesehen.

Wenn man den CB-Artikel liest (den es schon länger auf Englisch gab), so ist die "Farbe" nicht das einzige Einsatzgebiet des Raytracing: Man könnte auch eine bessere Kollisionsabfrage per Raytracing programmieren (ob Stahl oder Kugel, ist doch egal).
Jede durchschnittliche Engine bietet heutzutage Raycasting auf der Physikgeometrie. Eigentlich auch kein Wunder, weil die Physikengines es auch von Haus aus anbieten und man die Funktionalität nur wrappen muss.

[Leonidas]

Weil wir in unsere diesbezüglichen News
http://www.3dcenter.org/news/2007/woche09.php#2007-02-27
geschrieben hatte, daß Raytracing keine Einspar-Potentiale bei der Content-Erstellung hat, bekamen wir folgende Post von Daniel Pohl (Quake 4 Raytraced):


Liebes 3D-Center-Team,

erfreut habe ich festgestellt, dass es auf Ihren Seiten wieder einmal
ein bischen was zum Thema Raytracing zu lesen gibt. Zum Bereich der
Content Erzeugung möchte ich folgendene Hinweise anmerken:

Sicherlich wird weiterhin unabhängig von der Rendering-Technologie
viel Zeit in Erstellung von Texturen und Modellen aufgewendet werden.

Zeitliche Einsparungen kann es aber beispielsweise beim
Level-Designer geben. Dazu möcht ich kurz aus meiner Diplomarbeit
zitieren. Text und Bild sind hier:
http://www.q4rt.de/visportals.html

Auch wird es bei der Erstellung eines realistisch wirkenden Wassers
nicht mehr nötig sein, dass mehrere Grafikprogrammierer monatelang an
diesem Effekt arbeiten und am Ende doch nur eine Lösung bekommen die
in manchen Situationen zu sichtbaren Problemen führt
(Auflösungsbegrenzung der Reflection Map, fehlende Objekte in der
Spiegelung, unrealistisch wirkende Spiegelung bei der Spiegelung nahe
gelegenen Objekten).

Weitere Zeitersparnis gibt es dadurch, dass bei dem Einsatz von
Effekt X nicht zusätzlich abgeklärt werden muss, ob das Ganze dann
noch mit dem vorher implementierten Effekt Y funktioniert. Durch das
Verfolgen der Strahlen werden alle Effekte automatisch in der
korrekten Reihenfolge abgearbeitet. Beispiel:
http://www.q4rt.de/grafik/multieffect.png
Dort sieht man u.a.:
* Eine orangene Glaskugel, die durchsichtig und spiegelnd ist.
(Reflections & Refractions)
* Eine projektive Lichtquelle mit einer Textur
* Einen orangenen Schatten der Glaskugel
* In der Spiegelung der Glaskugel sieht man alle Effekte inklusive
des orangenen Schattens der Glaskugel...

Dabei wurde manuell keinerlei Reihenfolge der Abarbeitung festgelegt.
Jedes Objekt hat lediglich seine Materialeigenschaften in einem
Shader definiert.

[Gouvernator]

Sieht für mich ein bisschen so aus das Raytracing sich nur für wenige Objekte eignet bzw. immer dasselbe "Kugel in Kugel spiegeln". Ich meine... das kam doch schon vor Jahren ist ihnen inzwischen nix besseres eingefallen??? Wenn nicht, dann bitte lasst es, es macht einfach kein Zweck für ein paar Motorhaubenspiegelungen mehr...
Fällt ja sowieso nicht mehr auf bei heutiger Qualität.

Ich kann ja verstehen das in einigen Jahren ein Bedarf entstehen kann. Aber heutzutage brauchen wir einfach blos gut aufgelöste Texturen, das was man in der Spiegelung heutiger Spiele sieht ist absolut grottenschlecht-(aufgelöst). Einfach erstmal im Ansatz so machen das wenigsten etwas mehr einer Spiegelung sichtbar wird, bevor noch irgendwelche Details durch Raytracing hinzukommen...

[xie]

So ein Quatsch von wegen "nur Kugeln". Mir würden auf Anhieb 6872346 verschiedene Möglichkeiten einfallen wo das nützlich wäre.. wenn ich da nur an ein Rennspiel denke mit korrekten Reflektionen am Auto (sei es nun ein anderes vorbeifahrendes Auto oder die Rot/weißen begrenzungslinien), korrekte Rückspiegel mit vollem Detailgrad ohne Performanceeinbußen, ein leichtes Spiegeln des fahrers durch die Windschutzscheibe etc etc
Klar das man sowas nicht _unbedingt_ braucht, aber so gesehen hätte man auch gleich bei dx7 bleiben können...

[Corny]

Raytraicing wäre sicher für Spielekonsolen interessant!

da diese ja eh eigens dafür entwickelte Hardware verwenden und auch nur für die jeweilige Konsole programmierte Software ausführen müssen, hätte man keine kompatibilitätsprobleme.

Eine Raytraicing-Beschleuniger-Karte im PC hätte ja das Problem das sie alle "alten" Spiele nicht mehr darstellen kann. So ein Problem hätte man bei Konsolen nicht, man ist viel unabhängiger.

[tokugawa]

So ein Quatsch von wegen "nur Kugeln". Mir würden auf Anhieb 6872346 verschiedene Möglichkeiten einfallen wo das nützlich wäre.. wenn ich da nur an ein Rennspiel denke mit korrekten Reflektionen am Auto (sei es nun ein anderes vorbeifahrendes Auto oder die Rot/weißen begrenzungslinien), korrekte Rückspiegel mit vollem Detailgrad ohne Performanceeinbußen, ein leichtes Spiegeln des fahrers durch die Windschutzscheibe etc etc
Klar das man sowas nicht _unbedingt_ braucht, aber so gesehen hätte man auch gleich bei dx7 bleiben können...

Es geht nicht um's brauchen sondern darum dass der Unterschied zu heutigen Techniken marginal ist.

Ich hab das selbst schon gesehen... Raytrace-Effekte im Pixelshader, die eine physikalisch korrektere Reflexion ermöglichen (kommt von einer Universität in Budapest), vor allem wenn man die Anzahl der Iterationen erhöht.

Was ist rausgekommen? Ein paar Pixel Unterschied gegenüber der normalen Render-to-Cubemap-Environment-Map-Methode, die ein Laie gar nicht merkt, bzw. zwischen denen man nicht merkt, welche Methode die "korrekte" ist wenn man nicht grad ein Experte ist.

Mal abgesehen davon dass man den Unterschied sowieso nur in der Reflexion/Refraktion NAHER Objekte sieht, denn für entferntere Objekte in der Reflexion/Refraktion stimmt die Environment-Map-Methode nämlich.



Es ist also eine Frage des Trade-Offs - man wird nicht um Welten bessere/realistischere Bilder bekommen (sondern nur marginal in Grenzsituationen, wie die erwähnten "nahen Objekte"), aber man wird um einiges schlechtere Performance bekommen.

Und dann hör ich wieder die Deppen, die dann jammern dass Spieleprogrammierer so "ineffizient" seien und dass früher alles besser gewesen wäre.

Und die Einsparungen in der Spieleentwicklung von der Mail an 3DCenter sind ein absoluter Witz. Typisch von einem geschrieben der noch nie in der Industrie gearbeitet hat und daher nicht weiß wo die Bottlenecks sind.


Ich identifiziere hier mal die Blödsinnigkeiten die ich direkt sehe:



Sicherlich wird weiterhin unabhängig von der Rendering-Technologie
viel Zeit in Erstellung von Texturen und Modellen aufgewendet werden.


Das ist auch einer der Bottlenecks. Andere parallele Prozesse in der Spieleentwicklung zu verkürzen bringt also nichts für den kritischen Pfad in der Projektplanung (und vom kritischen Pfad hängt die Meilensteinerreichung ab).



Zeitliche Einsparungen kann es aber beispielsweise beim
Level-Designer geben. Dazu möcht ich kurz aus meiner Diplomarbeit
zitieren. Text und Bild sind hier:
http://www.q4rt.de/visportals.html


Das ist ein Blödsinn aus mehreren Gründen:
1) es verwenden nicht alle Spiele Portale (viele kommen sogar ohne aus)
2) es gibt zuverlässige Verfahren, Portale automatisch zu setzen (z.B. der relativ neue "Viewcell"-Algorithmus, der von unsere Computergraphik-Institut der Technischen Universität Wien stammt)
3) es gibt mittlerweile Verfahren, die online und dynamisch die Visibility bestimmen, wodurch Portale obsolet werden - sh. "Coherent Hierarchical Culling".

Es stimmt zwar dass Leveldesign eins der Hotspots/Bottlenecks in der Spieleentwicklung sind - aber Raytracing hilft hier genau Nüsse.



Auch wird es bei der Erstellung eines realistisch wirkenden Wassers
nicht mehr nötig sein, dass mehrere Grafikprogrammierer monatelang an
diesem Effekt arbeiten


Denkfehler: an einem Wassereffekt werden niemals mehrere Grafikprogrammierer arbeiten, und schon gar nicht mehrere Monate. Hier hat ein Junior Programmer vielleicht 1 Woche Zeit, um den Effekt zu implementieren, und das war's.

"Schönes" Wasser ist nicht so aufwändig. Man sehe auch dass ich grad "schön" geschrieben hab. Schön heißt nicht unbedingt realistisch, aber was man will ist schön. Was bringt einem realistisches Wasser wenn es trotzdem künstlerisch-ästhetisch nicht überzeugend ist?



und am Ende doch nur eine Lösung bekommen die
in manchen Situationen zu sichtbaren Problemen führt
(Auflösungsbegrenzung der Reflection Map, fehlende Objekte in der
Spiegelung, unrealistisch wirkende Spiegelung bei der Spiegelung nahe
gelegenen Objekten).


Hier trifft auch das zu was ich in den Zeilen zuvor geschrieben habe: Raytracing ist deswegen keine Ersparnis, weil das Ziel niemals "Realismus" per se ist, sondern Stimmigkeit mit dem Spielkonzept, und ein ästhetisch-künstlerisch zusammenpassendes Gesamtkonzept. Von daher würde man selbst mit einem Raytracing-Verfahrung die meiste Zeit nicht mit der Technologie, sondern mit dem Tweaken der Optik verbringen.



Weitere Zeitersparnis gibt es dadurch, dass bei dem Einsatz von
Effekt X nicht zusätzlich abgeklärt werden muss, ob das Ganze dann
noch mit dem vorher implementierten Effekt Y funktioniert. Durch das
Verfolgen der Strahlen werden alle Effekte automatisch in der
korrekten Reihenfolge abgearbeitet. Beispiel:


Das ist der einzige Punkt, wo ich dem Schreiber recht gebe.

Es ist in der Tat ein wenig ein Krampf, verschiedene Effekte unter einen Hut zu bringen. Wenn das konsistent auf einmal geht, schön.

Nur: mit Raytracing lassen sich eben nicht alle Effekte machen, die man will. Hatching und Charcoal-Rendering (bzw. non-photorealistic rendering generell) geht sicher leichter mit Rasterisierung. Letztendlich halte ich deswegen Rasterisierung für flexibler - man hat tatsächlich mehr Kontroller darüber, wie das Endergebnis aussehen soll. Und wenn das nicht realistisch sein SOLL, dann soll's halt so sein.

Man muß sich von der Idee trennen dass "Realismus" das Nonplusultra ist. Realismus kriegt man nämlich nicht mal mit Raytracing, denn Realismus - oder das bessere Wort dafür "Authentizität" oder "Plausibilität" - erhält man durch komplett andere Bereiche der Spieleentwicklung: Art Direction, Character Design, Storywriting, Game Design, Level Design.

"Realismus" in der Form "Authentizität" und "Plausibilität" ist eine künstlerische und keine technische Disziplin. Man kann noch so technisch realistische Grafik produzieren, letztendlich hängt es von den Künstlern und Game Designern ab, ob dies auch als realistisch wahrgenommen wird vom Zielpublikum.



http://www.q4rt.de/grafik/multieffect.png
Dort sieht man u.a.:
* Eine orangene Glaskugel, die durchsichtig und spiegelnd ist.
(Reflections & Refractions)
* Eine projektive Lichtquelle mit einer Textur
* Einen orangenen Schatten der Glaskugel
* In der Spiegelung der Glaskugel sieht man alle Effekte inklusive
des orangenen Schattens der Glaskugel...

Dabei wurde manuell keinerlei Reihenfolge der Abarbeitung festgelegt.
Jedes Objekt hat lediglich seine Materialeigenschaften in einem
Shader definiert.


Wie gesagt, hat man da allerdings dafür das enge Korsett des Realismus'. Man ist weniger flexibel wenn man wirklich verrückte Effekte haben will, die keine Entsprechung in der physikalischen Realität haben.

[Coda]

Thx tokugawa. Wollte grad schon was schreiben...

Der Typ lebt in seiner idellen Raytracing-Welt und will gar nicht einsehen, dass ein Rasterizer auch Vorteile haben könnte.

[Gast]

Thx tokugawa. Wollte grad schon was schreiben...

Der Typ lebt in seiner idellen Raytracing-Welt und will gar nicht einsehen, dass ein Rasterizer auch Vorteile haben könnte.

Ihr vergesst alle einen entscheidenden Fakt. Bei Rasterizern steigt die benötigte Performance mit der Anzahl der Objekte bzw. deren Detailgrad exponentiell. Bei Raytracing skaliert sie eher linear. Ab einem gewissen Punkt benötigt Raytracing daher weniger Power als Rasterizing.

[Demirug]

Bei Rasterizern steigt die benötigte Performance mit der Anzahl der Objekte bzw. deren Detailgrad exponentiell.

Wer erzählt den sowas?

[Gast]

Ihr vergesst alle einen entscheidenden Fakt. Bei Rasterizern steigt die benötigte Performance mit der Anzahl der Objekte bzw. deren Detailgrad exponentiell. Bei Raytracing skaliert sie eher linear. Ab einem gewissen Punkt benötigt Raytracing daher weniger Power als Rasterizing.
Erstens mal ist es Blödsinn. Bei einem Rasterizer ist es O(n) bei einem Rasterizer O(log n) wenn man einen Scenetree hat.

Aber: Du brauchst auch bei einem Raytracer LOD, sonst bekommst du übles Geo-Flimmern. D.h. viel mehr Geometrie als wir momentan in Spielen sehen wird's eh nicht mehr geben (vielleicht noch das zehnfache). Und da sehe ich nun wirklich keinen Vorteil für Raytracer.

[Expandable]

Das ist ein Blödsinn aus mehreren Gründen:
1) es verwenden nicht alle Spiele Portale (viele kommen sogar ohne aus)
2) es gibt zuverlässige Verfahren, Portale automatisch zu setzen (z.B. der relativ neue "Viewcell"-Algorithmus, der von unsere Computergraphik-Institut der Technischen Universität Wien stammt)
3) es gibt mittlerweile Verfahren, die online und dynamisch die Visibility bestimmen, wodurch Portale obsolet werden - sh. "Coherent Hierarchical Culling".


Dazu fällt mir auch noch ein: Ein Raytracer muss doch immer herausfinden, mit welchem Dreieck sich der Strahl als erstes schneiden wird. Dazu muss er ja schlimmstenfalls alle Dreiecke untersuchen. Portals sind doch eine gute Möglichkeit, von vornherein eine große Menge sowieso nicht sichtbarer Dreiecke auszuschließen, oder? Oder arbeitet der Raytracingalgorithmus irgendwie anders?

[Spasstiger]

Ihr vergesst alle einen entscheidenden Fakt. Bei Rasterizern steigt die benötigte Performance mit der Anzahl der Objekte bzw. deren Detailgrad exponentiell. Bei Raytracing skaliert sie eher linear. Ab einem gewissen Punkt benötigt Raytracing daher weniger Power als Rasterizing.
http://pics.computerbase.de/1/6/7/9/0/27_m.png
Du meinst linear bei Rasterizern und logarithmisch bei Raytracern.
Das Verhältnis zueinander ist natürlich durch exponentiell zu beschreiben.

P.S.: Eigentlich ist hier ein Fehler im Diagramm. log(x) ist 0 für x=1. Den Schnittpunkt (0/0) gibt es also gar nicht. Genaugenommen haben x und log(x) überhaupt keinen Schnittpunkt im Reellen.
Die Funktionen müssten eigentlich a*log(x+1) und b*x lauten, damit der Verlauf so aussehen kann wie im Schaubild (mit a/b>1, a>0, b>0).

[del_4901]

Dazu fällt mir auch noch ein: Ein Raytracer muss doch immer herausfinden, mit welchem Dreieck sich der Strahl als erstes schneiden wird. Dazu muss er ja schlimmstenfalls alle Dreiecke untersuchen. Portals sind doch eine gute Möglichkeit, von vornherein eine große Menge sowieso nicht sichtbarer Dreiecke auszuschließen, oder? Oder arbeitet der Raytracingalgorithmus irgendwie anders?

Octree, KD-Tree, BSP-Tree sind deine Kanidaten.

[Gast]

vom bildschirm pixel wird ein strahl in die welt geschossen. der trifft nunmal nur auf 1 poly als erstes..

[del_4901]

vom bildschirm pixel wird ein strahl in die welt geschossen. der trifft nunmal nur auf 1 poly als erstes..
..welches? Scherzkeks, das klingt alles so einfach. Denkst du ein Rasterizer "rastert" nicht auch genau ein Poly pro Pixel. (Wenn jetzt Coda Haare spalten will wegen AA etc. so soll er das tun ^^)

Denkt doch bitte mal nach bevor ihr solche Komentare abgebt!

[xie]

Was ist rausgekommen? Ein paar Pixel Unterschied gegenüber der normalen Render-to-Cubemap-Environment-Map-Methode, die ein Laie gar nicht merkt, bzw. zwischen denen man nicht merkt, welche Methode die "korrekte" ist wenn man nicht grad ein Experte ist.

Werden bei der Methode auch andere Fahrzeuge und eher nebensächliche objekte gespiegelt oder nur grob die Strecke? Würde da ab ner bestimmten Menge Autos nicht wieder Raytracing einen Geschwindigkeitsvorteil bieten, statt für jedes Auto eine Cubemap zu rendern? (Angenommen es würde schnelle RT-Hardware geben)
Das Problem ist doch auch das bei Rückspiegeln alle Dreiecke neu ins 2D-Koordinatensystem verformt werden müssten (weshalb im Rückspiegel die meisten Details fehlen), während beim RT auch geknickte Seitenspiegel für (so gut wie) keinen Verlust an Performance sorgen sollten, oder sehe ich da was Falsch? Regen wäre dann doch auch total easy, tropfen an der scheibe lenken die Strahlen ein bisschen ab, die Strecke spiegelt <- sowieso kein Problem.
Meine große Hoffnung war auch das durch Raytracing wieder konstante frameraten in Spielen kommen, so wie bei guten alten 2D Spielen. *schwelg*

[tokugawa]

Werden bei der Methode auch andere Fahrzeuge und eher nebensächliche objekte gespiegelt oder nur grob die Strecke? Würde da ab ner bestimmten Menge Autos nicht wieder Raytracing einen Geschwindigkeitsvorteil bieten, statt für jedes Auto eine Cubemap zu rendern? (Angenommen es würde schnelle RT-Hardware geben)


Das ist skalierbar. Wie man will - bzw. wie es nötig ist. Raytracing ist hier viel zu "brute force".


Das Problem ist doch auch das bei Rückspiegeln alle Dreiecke neu ins 2D-Koordinatensystem verformt werden müssten (weshalb im Rückspiegel die meisten Details fehlen),


Ich glaub dir fehlt ein fundamentales Verständnis der Rendering Pipeline. Transformieren ins 2D-Screenspace mußt du sowieso immer. Bei Rückspiegeln einfach mit einer anderen Matrix. Aufwand ist derselbe.

Details - alles skalierbar, wie man will.


während beim RT auch geknickte Seitenspiegel für (so gut wie) keinen Verlust an Performance sorgen sollten, oder sehe ich da was Falsch?


Ja, komplexere "Formen" sind unter Raytracing "einfacher" im Prinzip.

Aber für sowas gibt's Raytracing-Shader in aktuellen Rendertechniken, die Raytracing lokal verwenden. Und selbst mit normalen, nicht-geraytracten Environment-Map-Techniken kann ich dir versprechen: du wirst keinen Unterschied merken, bzw. nicht wissen welche Variante "realistischer" ist.

Und wie gesagt, je entfernter die Objekte im Spiegel, desto weniger Unterschiede gibt es. Man könnte es so sagen dass nur an Objekten direkt AM spiegelnden Objekt einen Unterschied in der Reflexion gibt. Und da auch nur wenn dieses "nahe Objekt" ein Schachbrettmuster hat - da täte man den Unterschied sehen - aber "falsch" täte es mit "traditionellen" (eigentlich ein falsches Wort da in der aktuellen Echtzeitgrafikforschung gerade bei solchen Effekten unglaubliche Fortschritte gemacht werden) für den Laien nicht aussehen.


Regen wäre dann doch auch total easy, tropfen an der scheibe lenken die Strahlen ein bisschen ab, die Strecke spiegelt <- sowieso kein Problem.
Meine große Hoffnung war auch das durch Raytracing wieder konstante frameraten in Spielen kommen, so wie bei guten alten 2D Spielen. *schwelg*

So konstant wird's durch Raytracing trotzdem nicht. Je mehr Ray-Bounces man erlaubt, desto unvorhersehbarer wird's.

Raytracing ist abhängig von der Geometriekomplexität wie Rasterisierung, aber hier ist der springende Punkt: Auch bei Rasterisierung ist man in der Regel nicht geometrielimitiert, sondern Fillratelimitiert.

Jetzt überlege man sich mal wie das bei Raytracing ist, also wie Raytracing mit der Auflösung skaliert etwa.

Eigentlich hat Raytracing insgesamt eine höhere Streuung an Geschwindigkeiten. Gibt ja alles von ein paar Minuten pro Bild bis ein paar Tage.





Zusammenfassend meine Analyse:

Ich glaube viele erwarten sich von Raytracing einen höheren Realismus in Spielen (oder wo auch immer).

Nur vergessen diese Leute, dass wenn irgendwas heute "nicht realistisch" wirkt, dies nicht an der Technologie liegt, sondern eher an diversen Content/Art-Aspekten. Etwa Animation.

Natürlich wäre Raytracing mathematisch gesehen korrekter. Aber mathematischer Realismus deckt sich eben nicht zwingend mit "wahrgenommenem Realismus".

Ob etwas von den Nutzern als "realistisch" wahrgenommen wird liegt an vielen Aspekten. Derzeitiges "Rendern" ist schon realistisch genug dass Raytracing kaum Unterschiede bringen würde. Es ist eher in der Zeit am "Realismus" in anderen Aspekten zu schrauben: Art/Animation und Game Design.

Wenn man denn tatsächlich Realismus (bzw. ein "Realismusgefühl") will.

[Gast]

Die Funktionen müssten eigentlich a*log(x+1) und b*x lauten, damit der Verlauf so aussehen kann wie im Schaubild (mit a/b>1, a>0, b>0).

nicht ganz, die kurve müsste a*log(x)-1 lauten.

[Spasstiger]

nicht ganz, die kurve müsste a*log(x)-1 lauten.
Deine Funktion geht aber nicht durch den Punkt (0/0).

[ScottManDeath]

Fickrig wirds dann auch bei Raytracing wenn man z.B. Soft shadows haben will. Hard shadows sind ein alter Hut, die will keiner mehr haben ...

Dann zieh ich mir lieber adaptiv einige dutzend Samples aus der Shadowmap anstelle von 20000+ Strahlen pro Pixel damit beim (Monte Carlo) Raytracing das Rauschen halbwegs verschwindet und die Schatten smooth werden.

Whitted Style Raytracing bring nur marginale Vorteile gegenueber Rasterization. Und globale Beleuchtung mittels Monte Carlo Raytracing ist einfach nur pervers rechenaufwaendig, dass man lieber einen Rasterizer pimpt, z.b. mit Spherical Harmonics oder dem was Fantasylabs macht.

[Gast]

Kann man diese Techniken nicht kombinieren?

[Gast]

Deine Funktion geht aber nicht durch den Punkt (0/0).

Macht sie im Diagramm ja auch nicht...

[Gast]

Macht sie im Diagramm ja auch nicht...


stimmt, wenn ich es mir so ansehe könnte log(x) sogar stimmen, die achsen sind ja nicht beschriftet.

[Spasstiger]

Macht sie im Diagramm ja auch nicht...
Ok, verdammt. Wenn man reinzoomt, sieht man, dass die Kurve wohl doch nicht x=0 erreicht und somit log(x) in der Funktion möglich ist. Das Diagramm ist mit der Kurvenbeschriftung x und log(x) natürlich trotzdem falsch (weil diese beiden Funktionen keinen Schnittpunkt im Reellen haben).

[ScottManDeath]

Ok, verdammt. Wenn man reinzoomt, sieht man, dass die Kurve wohl doch nicht x=0 erreicht und somit log(x) in der Funktion möglich ist. Das Diagramm ist mit der Kurvenbeschriftung x und log(x) natürlich trotzdem falsch (weil diese beiden Funktionen keinen Schnittpunkt im Reellen haben).

Naja, die O(g( n)) = f( n) Notation fuer die Komplexitaet sagt nur dass 0 <= f( n) <= c g( n) fuer eine gewisse Konstante c und alle n >= n0. D.h. es interessiert nicht ob sich log x mit x kreuzen kann oder nicht, sondern nur dass f( n) nur um einen konstanten Faktor c unterschiedlich zu g( n) ist, fuer ein (moeglicherweise grosses) n >= n0.

[Gast]

Ok, verdammt. Wenn man reinzoomt, sieht man, dass die Kurve wohl doch nicht x=0 erreicht und somit log(x) in der Funktion möglich ist.

log(x) kann nicht sein, da log(x) zwischen 0 und 1 negativ ist, der graph aber überall positiv ist.

das ganze kann höchstens log(x)+d sein, damit wäre auch wieder ein schnittpunkt möglich.

[Spasstiger]

log(x) kann nicht sein, da log(x) zwischen 0 und 1 negativ ist, der graph aber überall positiv ist.
Die log-Kurve erreicht die Stelle x=1 ja gar nicht unbedingt.

[Gast]

Die log-Kurve erreicht die Stelle x=1 ja gar nicht unbedingt.

der nullpunkt ist im grafen aber eindeutig eingezeichnet und die kurve von log(x) beginnt im positiven, obwohl sie zwischen 0 und 1 negativ sein müsste und bei 1 die x-achse schneidet.

[Spasstiger]

der nullpunkt ist im grafen aber eindeutig eingezeichnet und die kurve von log(x) beginnt im positiven, obwohl sie zwischen 0 und 1 negativ sein müsste und bei 1 die x-achse schneidet.
Es gibt zwar die Achse x=0 im Schaubild, trotzdem beginnt die log-Kurve dort nicht, sondern einen Pixel rechts davon. Und es kann ja sein, dass dieser eine Pixel größer als 1 ist.

[mickii]

Denkfehler: an einem Wassereffekt werden niemals mehrere Grafikprogrammierer arbeiten, und schon gar nicht mehrere Monate. Hier hat ein Junior Programmer vielleicht 1 Woche Zeit, um den Effekt zu implementieren, und das war'ses ist schon aufwendiger, sonst haetten leute nicht dipl-arbeiten darueber geschrieben und es haetten ein paar spiele mehr ein gut aussehendes wasser.
daran arbeitet ein guter programmierer dann auch mal ein paar wochen, nur der grundlegende-shader ist natuerlich schnell gemacht, aber die integration in eine engine und dafuer zu sorgen das es animiert noch "realistisch" ausschaut ist doch aufwendiger.
aber ich stimmt dir zu dass dieser eine fall auch ein beklopptes beispiel ist, denn das raytracer-wasser wird genauso jemand schreiben muessen wie das derzeitige wasser und obwohl sie eine bumpy-flaeche haben in ihrem wassersample, sieht das alles andere als nach wasser aus und genau da ist der arbeitsaufwand, es so zu coden dass es nicht wie ne bumpy-flaeche mit reflektion, sondern wie wasser ausschaut

ich beziehe mich auf deren bild: http://www.idfun.de/temp/q4rt/screenshots/q4waterCut.jpg

wenn sie statt 50:50 blenden einfach mal fresnel genommen haetten, sehe es sicher zig mal besser aus als das. aber das ist ja eben die arbeit.

[tokugawa]

es ist schon aufwendiger, sonst haetten leute nicht dipl-arbeiten darueber geschrieben und es haetten ein paar spiele mehr ein gut aussehendes wasser.


Wenn du wüsstest über was Leute schon Diplomarbeiten und Dissertationen geschrieben haben :)

Und natürlich: Wasser-Rendering-Verfahren sind an sich schon ein gutes Diplomarbeitsthema - vor allem für den State-of-the-Art-Teil der Diplomarbeit (Übersicht über alle bisherigen Verfahren).

Aber die Spieleindustrie hat den Vorteil auf einen riesigen Fundus Wissen von existierenden Verfahren zurückgreifen zu können: von technischer Seite ist hier nicht sehr viel Aufwand erforderlich.

Dass nicht mehr Spiele "gut aussehendes" Wasser besitzen liegt sicher an anderen Faktoren: auch eine Wasser-Technik muß über Content "gutaussehend" gemacht werden. Die sind nicht sofort schön wenn der Programmierer sie fertigimplementiert hat.


daran arbeitet ein guter programmierer dann auch mal ein paar wochen, nur der grundlegende-shader ist natuerlich schnell gemacht,


1 Woche eines Junior Programmers war etwas überspitzt formuliert, das geb ich zu. Es ist allerdings schon möglich, bzw. sogar sehr wahrscheinlich (ich hab selbst nicht länger gebraucht).

Nichtsdestotrotz würde ein vernünftiger Projektplaner oder Lead Programmer wohl die Zeit dafür trotzdem auf 3 Wochen schätzen (Pufferzeiten und so weiter).


aber die integration in eine engine und dafuer zu sorgen das es animiert noch "realistisch" ausschaut ist doch aufwendiger.


Integration in eine Engine: kommt auf die Engine an.

"dass es animiert noch realistisch ausschaut": ist zu 90% Content-Aufgabe, also nicht im Aufgabenbereich des Programmierers.


aber ich stimmt dir zu dass dieser eine fall auch ein beklopptes beispiel ist, denn das raytracer-wasser wird genauso jemand schreiben muessen wie das derzeitige wasser und obwohl sie eine bumpy-flaeche haben in ihrem wassersample, sieht das alles andere als nach wasser aus und genau da ist der arbeitsaufwand, es so zu coden dass es nicht wie ne bumpy-flaeche mit reflektion, sondern wie wasser ausschaut

ich beziehe mich auf deren bild: http://www.idfun.de/temp/q4rt/screenshots/q4waterCut.jpg

wenn sie statt 50:50 blenden einfach mal fresnel genommen haetten, sehe es sicher zig mal besser aus als das. aber das ist ja eben die arbeit.

Genau darauf wollte ich hinaus: die Technik allein macht noch kein realistisches und schon gar nicht ein "schönes" Wasser.

Und die Technik hilft sicher nicht, den Aufwand bei der Contenterstellung (Tweaken des Wassers und seiner Parameter) zu reduzieren.

[HotSalsa]

Imho gibt es neben dem ganzen Shadergedöns 2 wirklich wichtige Aspekte, welche ein Spiel "echter", realistischer und "lifelike" wirken lassen.

Das sind 1. HQ Texturen in hoher Auflösung, variabler Größe je nach Objekt und in großer Vielfalt, sowie eine stimmige global Illumination mit Schatten.
Bei beiden ist in heutigen Spielen noch viel Luft nach oben.

Verbessert man diese beiden Punkte um einen fiktiven Faktor 5 - 10 und kombiniert das mit den existierenden Techniken ( AA, AF, shader, normal maps etc... ) so wäre das Ergebnis im Vergleich zu heute verblüffend ohne gleich die Raytracingkeule rausholen zu müssen :tongue:

Das würde eine bessere Grafikhardware erfordern. Ok, 5 Gbyte texturmemory auf einer Grafikkarte ist sicherlich irgendwann machbar aber wie könnte man global Illumination und Schatten qualitativ hochwertig per Hardware beschleunigen? Wäre dazu evtl. eine 8 Core CPU zB besser geeignet als eine GPU - oder eine Kombination aus beiden (GPU macht Schatten, 2-4 Cores der CPU nur Illumination) ??

[Roi Danton]

Wenn eine Echtzeit-Darstellung nicht für Spiele gedacht ist, sondern für Anwendungen, die realistische Reflektionen benötigen (z.B. Architektur, Konstruktion, Visualisierung prozesstechnischer Vorgänge (Beschichtungstechnik etc)), dann kann für diese Raytracing durchaus interessant werden.

[ScottManDeath]

Klar, oder z.b. bei großen Datensätzen wie das Boeng Model, welches einige GB benötigt. Das kann man mit einfachem Shading in Echtzeit auf einem kleinen Cluster machen.

[tokugawa]

Wenn eine Echtzeit-Darstellung nicht für Spiele gedacht ist, sondern für Anwendungen, die realistische Reflektionen benötigen (z.B. Architektur, Konstruktion, Visualisierung prozesstechnischer Vorgänge (Beschichtungstechnik etc)), dann kann für diese Raytracing durchaus interessant werden.

Viele der Dinge die du gelistet hast, benötigen allerdings keine realistischen Reflexionen :)

Wo Realismus erforderlich wäre, wäre etwa Medizinische Visualisierung. Aber mir wäre neu dass der menschliche Innenraum irgendwas hätte was reflektiert...

[Gast]

Wo Realismus erforderlich wäre, wäre etwa Medizinische Visualisierung. Aber mir wäre neu dass der menschliche Innenraum irgendwas hätte was reflektiert...


selbst wenn würde es wohl eher stören ;)

[Demirug]

Je näher wir dem Realismus bei der Grafik auf einem Screenshot kommen desto mehr fallen die ganzen Unzulänglichkeiten im bewegten Bild auf.

Frei nach unserem Art Direktor.

[tokugawa]

Je näher wir dem Realismus bei der Grafik auf einem Screenshot kommen desto mehr fallen die ganzen Unzulänglichkeiten im bewegten Bild auf.

Frei nach unserem Art Direktor.

Genau... und auch wie ich schon erwähnt hatte in anderen Bereichen genauso. Man stelle sich ein komplett visuell realistisches Spiel vor.... dann würde noch viel frappanter auffallen, wenn die Spielmechanik und die Spiellogik nicht dazu passend designt werden (z.B. wenn man nicht über ein Geländer springen kann weil der Designer alles dahinter nicht weiter erstellt hat - oder "World Blocker", wo man einfach prinzipiell nicht weiter kann).

Oder auch Character Design und Storywriting: superrealistisch aussehende Charaktere, die sich wie Puppen verhalten und vorgekaute 0815-Sätze wiedergeben zerstören die Illusion von Plausibilität und Authentizität ("Suspension of Disbelief") mehr als weniger realistisch aussehende Charaktere mit guter Story dahinter und guten Dialogen/Persönlichkeiten (also gutem Emotional Design).

Daher ist Realismus sicher nicht abhängig von der technischen Grafikqualität eines einzelnen (Stand-)Bildes, sondern von vielen Faktoren - und keine dieser anderen Faktoren wird von Raytracing auch nur berührt.

Daher sollte man aufhören, in Raytracing den heiligen Gral für Realismus zu sehen.

[Leonidas]

Man sollte aufhören, möglichst realistische Grafik für den heiligen Gral der Spiele zu halten.

IMO sollte es mehr in Richtung bessere Engines gehen - nicht bzgl. der Grafik, sondern der eigentlichen Spiel-Mechanik. Einfaches wie dummes Beispiel: IM FM beklagt sich der Vereinpräsi, wenn ich 50 Mill. Miese bei den Transferkosten habe - daß ich noch 100M Plus bei den Gehältern habe, wird gar nicht eingerechnet. DAS ist das Unrealismus, der mich an die Decke gehen läßt - ob der Michael Ballack im Spiel besondere realitätsgetreu abgebildet wird, ist echt zweitrangig.

[Armaq]

Ich könnte mir eine absolut bahnbrechende Technologie vorstellen.
Raytracing mit eingebautem Kollisions und Physikfilter. Sprich, der Strahl ist nicht nur Darstellung sondern auch der Ton, Wand etc. D.h. alles aus einem.

[tokugawa]

Ich könnte mir eine absolut bahnbrechende Technologie vorstellen.
Raytracing mit eingebautem Kollisions und Physikfilter. Sprich, der Strahl ist nicht nur Darstellung sondern auch der Ton, Wand etc. D.h. alles aus einem.

Dann entwickel die Idee und reich die bei einer renommierten wissenschaftlichen Konferenz wie etwa der Eurographics oder der SIGGRAPH ein :D

[Armaq]

Ich studiere Wirtschaftsrecht... Ich hab keine Ahnung von der Technik dahinter!
Frag mich wenn es um die Patente geht. ;)

[Monger]

Je näher wir dem Realismus bei der Grafik auf einem Screenshot kommen desto mehr fallen die ganzen Unzulänglichkeiten im bewegten Bild auf.

Frei nach unserem Art Direktor.

Interessantes Statement.

Ich persönlich glaube, dass Reflexionen ohnehin überbewertet sind. Wenn ich mich hier in der realen Welt ein wenig umschaue, sehe ich - wenn überhaupt - nur sehr wenig Reflexionen, und davon die meisten sehr diffus. Ob die paar hellen Flecken auf den Bad-Fliesen jetzt daher stammen, dass man da jetzt schnell mal ein paar generische Flecken drauf geklebt hat, oder weil man alle Sekundärstrahlen bis zum letzten fliegenfurz-bedingten Farbwert ausgerechnet hat, sieht man imho kaum. Dafür ist der Mensch nicht ausgelegt.
Für einen Menschen ist ein weisses Ei grundsätzlich weiß - auch wenn es grün ausgeleuchtet wird. Was wir aber relativ gut wahrnehmen, sind Unterschiede die sich in der Bewegung zeigen, wenn also z.B. mal ein Lichtfleck einen Moment später verschwunden ist. Und wir können uns gut Formen und Strukturen merken. Was mir an meinem Schreibtisch hier am stärksten auffällt, sind die diversen Flecken und Kratzer, die sich jahrelang darin gebildet haben.

Ich persönlich glaube deshalb, dass die Bedeutung von Beleuchtungseffekten in Zukunft gar nicht so dramatisch sein wird. Es ist schön, wenn man dynamisches Licht hat, aber ich denke, dass sich im Bereich der Geometrie (z.B. Displacement Mapping) und der Texturierung (z.B. Subsurface Scattering, künstliches Verwittern von Oberflächen) noch eine Menge tun wird, und dort auch der größte Gewinn an Bildqualität zu holen ist.

Zumindest nach meinem begrenzten Verständnis nach ist Raytracing eine Sackgasse. Das was man damit eigentlich erreichen will - nämlich reduzierten Arbeitsaufwand durch ein einheitliches Beleuchtungsmodell - scheint mir unrealistisch.

[Aquaschaf]

IFür einen Menschen ist ein weisses Ei grundsätzlich weiß - auch wenn es grün ausgeleuchtet wird.

Das ist kein so gutes Beispiel :) Ist ein Ei weiß obwohl die Lichtverhältnisse es grün erscheinen lassen würden, dann sieht das falsch aus. Wenn es um Beleuchtung geht machen auch subtile Dinge einen Unterschied. Auch wenn die meisten Leute nicht mit dem Finger darauf zeigen können warum etwas real wirkt oder nicht - das wird durchaus wahrgenommen. Bei Reflektion und Refraktion lässt man sich meiner Erfahrung nach aber gut täuschen.

[del_4901]

jo, das mit dem Weiß ist ein sehr schlechtes Beispiel, denn echtes Weiß ist für uns Grau/Braun (schmutziges Weiß). Da muss erst ein fetzen Blau rein damit es Weiß wirkt. Wenn du das Ei mit Grünen Licht bestrahlst wird es warscheinlich bräunlich wirken.

[urpils]

Interessantes Statement.

Ich persönlich glaube, dass Reflexionen ohnehin überbewertet sind. Wenn ich mich hier in der realen Welt ein wenig umschaue, sehe ich - wenn überhaupt - nur sehr wenig Reflexionen, und davon die meisten sehr diffus.

und genau dort liegt ja die Schwierigkeit... du siehst all die Reflexionen und diffusen Beleuchtungen um dich herum nicht bewusst.. du siehst sie einfach und denkst gar nicht über die Komplexität des Zustandekommens dieser Komposition nach.

menschliche Haut ist ein gutes Beispiel... mit einer einfach Textur auf einem Polygon ist es nicht getan, um Haut realistisch wirken zu lassen.. in Wirklichkeit müssen schwach durchscheinende Adern, das Licht, was bis in bestimmte Bereiche der Haut eindringt, die verschiedenen Belichtungsverhältnisse, Struktur,... zusammenkommen, um die Haut so aussehen zu lassen, wie sie eben aussieht. Und da unser Auge NUR Licht verarbeitet (also unser Sehen auf Licht beschränkt ist) finde ich es logisch, das Hauptaugenmerk bei Grafikberechnung auf die möglichst realistische Beleuchtung zu richtigen.
Es gibt ja nicht nur "reflektiert" oder "reflektiert nicht". Auch Wasser reflektiert nicht einfach nur Licht ;)

also so einfach ist das alles nciht..

[Monger]

menschliche Haut ist ein gutes Beispiel... mit einer einfach Textur auf einem Polygon ist es nicht getan, um Haut realistisch wirken zu lassen.. in Wirklichkeit müssen schwach durchscheinende Adern, das Licht, was bis in bestimmte Bereiche der Haut eindringt, die verschiedenen Belichtungsverhältnisse, Struktur,... zusammenkommen, um die Haut so aussehen zu lassen, wie sie eben aussieht.

Klar. Die Frage ist nur: muss das unbedingt "On-the-fly" berechnet werden?

Ist die Umgebung wirklich so entscheidend, dass man alle denkbaren Reflexionen in einem Raum hinzurechnen muss, um eben z.B. Haut vernünftig beleuchten zu können?

Die Stärke von Raytracing ist, dass alles was für die Beleuchtung relevant sein könnte, tatsächlich auch berücksichtigt wird. Ich frage mich nur, ob das Sinn macht, oder ob das in der Realität nicht eine so exotische Anforderung ist, dass man es lieber als Ausnahme hinnimmt, statt es zur Regel zu erklären. Rechenkraft ist auf dem PC nunmal knapp, und es gibt auch andere Dinge wofür man sie gut gebrauchen kann.

[Chris Lux]

das problem, welches ich sehe ist, dass wenn reflektionen vorhanden sind, welche realistisch sein sollen, sehen wir sehr schnell, wenn gefakted wird. den grund dafür sehe ich darin, dass wir es dann mit der realität, an welche wir uns unser ganzes leben gewöhnt haben und welche wir nicht in frage stellen, vergleichen aber immer der letzte zweifel bleibt. man könnte fotos machen von bestimmten beleuchtungssitutationen (besonders reflektionen), welche jeder für unrealistisch hält, diese jedoch live erlebt keinerlei zweifel oder aufmerksamkeit bekommen.

ein mensch ist sehr gut in der lage reflektionen zu erkennen, aber nicht zu erkennen woher diese genau kommen. das problem ist aber, wie angesprochen unsere unterbewusste erwartungshaltung und erfahrung.

was ich sagen will ist, dass wenn wir anfangen über real zu reden muss es so hyperreal wie nur möglich sein (ich spreche nicht nur von spielen). weil wenn an einer ecke gefaked wird fällt das extrem auf, weil sich einfach etwas nicht so verhält, wie unsere erfahrung es erwartet. ich quote da immer gern das uncanny valley [1], weil es das problem sehr gut verdeutlicht.

[1] http://en.wikipedia.org/wiki/Uncanny_valley

[Gast]

und genau dort liegt ja die Schwierigkeit... du siehst all die Reflexionen und diffusen Beleuchtungen um dich herum nicht bewusst.. du siehst sie einfach und denkst gar nicht über die Komplexität des Zustandekommens dieser Komposition nachIch denke wenn sie auf einmal da sind, wo sie jahrzehntelang in den Spielen fehlten, dann bemerkt man es schon. Die Möglichkeiten bestehen jetzt und die Jungs versuchen das in den Spielen auch zu zeigen und hervorzuheben. Das freut am Anfang, aber langsam sollte man zusehen brauchbare RL-Pendants zu finden. Irgendwannmla wird es eben zu öde.
ÜBer ein leichtes kurzes "Aufblitzen" solche Effekte freut man sich trotzdem. Das läßt sich mit entsprechendem Leveldesign gelegentlich zeigen. Und gut ist. Wie Monger aber schon sagte und ich kleinwenig anders ausdrucke, wird momentan extrem oft Leistung einfach mit unnötigem catch-eye-bullshit verballert.

[tokugawa]

Und da unser Auge NUR Licht verarbeitet (also unser Sehen auf Licht beschränkt ist) finde ich es logisch, das Hauptaugenmerk bei Grafikberechnung auf die möglichst realistische Beleuchtung zu richtigen.


Genau hier liegt der Denkfehler.

Klar, physisch mechanisch technisch gesehen ist das Auge ein Lichtsensor.

Aber diese Bilder werden im Gehirn verarbeitet. "Realismus" ist eine Funktion des Gehirns. Dieses Gehirn ist in der Lage, mathematisch gesehen unrealistischen Bildern Realismus zuzubilligen. Dieses Gehirn ist in der Lage, mathematisch gesehen realistische Bildern als "unrealistisch" zu klassifizieren (Beispiel dafür sind Fotos - realistischer geht's nicht - von irgendwelchen Dingen die ein bestimmter Mensch noch nie zuvor gesehen hat. Polarlichter oder sowas. Das würde dieser Mensch dann als "unrealistisch" bezeichnen weil er es einfach nicht kennt).


Was ich damit sagen will: Man darf die Wahrnehmungspsychologie des Menschen nicht vergessen.

Nur weil etwas technisch gesehen "realistisch berechnet" wird, heißt das nicht das dies auch als "realistisch" wahrgenommen wird.

Vor allem weiß man ja bei Computergrafiken vor allem in Spielen, dass diese computergeneriert sind. Da schaltet das Hirn dann - egal wie realistisch das Bild ist - auf "das ist CG!".

Daher sollte man sich von der Idee lösen dass Raytracing mehr "Realismus" bringt. Vor allem nicht da dies nur eine partielle Lösung ist. Dadurch dass das Gehirn sehr viel mehr als das "pure Bild" verarbeitet - Bewegung, sowie "Kontextinformation" wie etwa Hintergrundgeschichte des Gegenübers, Mimik, Gestik, Situation - kann man allein durch visuellen Realismus kein Realismusgefühl erzeugen.


das problem, welches ich sehe ist, dass wenn reflektionen vorhanden sind, welche realistisch sein sollen, sehen wir sehr schnell, wenn gefakted wird. den grund dafür sehe ich darin, dass wir es dann mit der realität, an welche wir uns unser ganzes leben gewöhnt haben und welche wir nicht in frage stellen, vergleichen aber immer der letzte zweifel bleibt. man könnte fotos machen von bestimmten beleuchtungssitutationen (besonders reflektionen), welche jeder für unrealistisch hält, diese jedoch live erlebt keinerlei zweifel oder aufmerksamkeit bekommen.


Genau dem widerspreche ich. Gerade Reflexionen lassen sich wunderbar fälschen (wird in jedem "realistischem" Gemälde gemacht und keiner merkt's).

Ich teste dich:

Eine der beiden folgenden Reflexionen ist physikalisch korrekt mittels Raytrace-Shader berechnet (also "realistisch"). Die andere durch "gefakte" Reflexion mittels Cubemap-Environmentmapping.

Die Frage jetzt: welche der beiden Varianten ist welche?

http://www.cg.tuwien.ac.at/~chiu/gtp/refraction_off.png

http://www.cg.tuwien.ac.at/~chiu/gtp/refraction_on.png



Ich denke wenn sie auf einmal da sind, wo sie jahrzehntelang in den Spielen fehlten, dann bemerkt man es schon. Die Möglichkeiten bestehen jetzt und die Jungs versuchen das in den Spielen auch zu zeigen und hervorzuheben. Das freut am Anfang, aber langsam sollte man zusehen brauchbare RL-Pendants zu finden. Irgendwannmla wird es eben zu öde.


Mit dem reinen "Standbild-Realismus" sind wir heute schon so weit, dass eine Verbesserung in der Art wie ihr es euch von Raytracing erhofft ein viel zu kleiner Sprung ist, als dass es Grafiklaien wirklich merken würden. Diese würden dann wieder mal auf die Performance und die Fähigkeiten der Programmierer schimpfen, aber nicht merken dass der Realismus, der mittlerweile nur mehr marginal erhöht wird - auch durch Raytracing - eben mehr kostet.


ÜBer ein leichtes kurzes "Aufblitzen" solche Effekte freut man sich trotzdem. Das läßt sich mit entsprechendem Leveldesign gelegentlich zeigen. Und gut ist. Wie Monger aber schon sagte und ich kleinwenig anders ausdrucke, wird momentan extrem oft Leistung einfach mit unnötigem catch-eye-bullshit verballert.

Dieser Catch-eye-bullshit (wenn du z.B. HDR meinst) gehört allerdings genauso zu "Realismus". Man kann sich nicht von Raytracing erhoffen dass einem die Sonne aus dem Arsch scheint, und dann meinen dass HDR nur "catch-eye-bullshit" wäre.

Eher würde Raytracing wohl auch unter Catch-Eye-Bullshit fallen.

Und irgendwie sind's ja die billigen und künstlerisch gut eingesetzten Effekte, die schön und stimmig sind. Ich halte nichts von der technokratischen Einsetzung von Effekten nur um der Effekte willen.

Deswegen bin ich auch sehr dafür vieles in die Kontrolle der Artists zu geben. Alles automatisch zu berechnen vom Computer macht keine "schöne Grafik". "Artist-controlled" ist der Weg - auch zu "realistischeren" (oder "realistischer wahrgenommenen") Grafiken.

[(del)]

Tokugawa, der Gast war ich. Und ich löse mich von dem Raytracing gehype gerne. Wie gesagt bin ich eher der Meinung von Monger. Und der Hoffnung, Intel findet bald ein sinnvollere Idee wie man uns die Quadcores andrehen könnte...

Schöne Bilder :) Ich denke aber richtig gut faken kann man erst, wenn man sich das Ergebnis des Raytrace-Shader ansieht. So gesehen erscheint mir eine Weiterentwicklung BEIDER Methoden schon wichtig. Wirklich schön wäre es aber, wenn man 2x einen Lauf um die Kugel sehen könnte. Standbilder 'verleugnen' oft einiges. Der erste ist Cubemap? (kopfkratz)

[Gast]

Ich teste dich:

Eine der beiden folgenden Reflexionen ist physikalisch korrekt mittels Raytrace-Shader berechnet (also "realistisch"). Die andere durch "gefakte" Reflexion mittels Cubemap-Environmentmapping.

Die Frage jetzt: welche der beiden Varianten ist welche?

http://www.cg.tuwien.ac.at/~chiu/gtp/refraction_off.png

http://www.cg.tuwien.ac.at/~chiu/gtp/refraction_on.png



ich würd mal sagen das 2. sieht realistischer aus, aber nur wenn man die bilder direkt übereinanderlegt.

btw: bin übrigens ein anderer gast.

[Armaq]

Tippe mal Nr.2, kann aber nicht sagen warum.

[Gast]

Tippe mal Nr.2, kann aber nicht sagen warum.

weil man beim ersten den vollständigen gelben kreis, also auch das was hinter der kugel liegt in der kugel spiegeln sieht, was meiner meinung aus dieser position nicht sein kann.

aber wahrscheinlich ist garkeines der bilder durch raytracing entstanden, zumindest das starke aliasing in der spiegelung deutet in beiden fällen auf eine zu gering aufgelöste cubemap hin.

[PrefoX]

raytracing spiegelungen müssen kein AA haben..

[Chris Lux]

Ich teste dich:

Eine der beiden folgenden Reflexionen ist physikalisch korrekt mittels Raytrace-Shader berechnet (also "realistisch"). Die andere durch "gefakte" Reflexion mittels Cubemap-Environmentmapping.

Die Frage jetzt: welche der beiden Varianten ist welche?

http://www.cg.tuwien.ac.at/~chiu/gtp/refraction_off.png
http://www.cg.tuwien.ac.at/~chiu/gtp/refraction_on.png
hehe ;)
ok, jetzt schauen wir das mal in einem nicht so extrem trivialen fall an wie einer kugel, sondern mal was 'realistischeres', konkaveres ;), nimm ein auto bspw. dort kann man sofort sagen, ob es korrekte reflektionen oder nicht sind.

ich komm (wie zuletzt sehr oft) auf die source engine zu sprechen, dort werden alle (ausser wasser) reflektionen über approximierte cupemaps gemacht und in bewegung fällt _sofort_ auf, dass diese reflektionen nicht gut sind. dazu zähle ich, dass sie sich teilweise mit dem auge mitbewegen und nur für einen standpunkt in einem raum korrekt sind. klar könnte man das jedes frame neu generieren, doch dann muss man es für jedes objekt (oder teilobjekt machen) und das geht tierisch auf die performance.

ich sage nicht, dass raytracing der große wurf ist, gefaked werden muss dann auch um die performance zu erreichen.


Mit dem reinen "Standbild-Realismus" sind wir heute schon so weit, dass eine Verbesserung in der Art wie ihr es euch von Raytracing erhofft ein viel zu kleiner Sprung ist, als dass es Grafiklaien wirklich merken würden.
wir reden hier aber nicht von standbildern.

Dieser Catch-eye-bullshit (wenn du z.B. HDR meinst) gehört allerdings genauso zu "Realismus". Man kann sich nicht von Raytracing erhoffen dass einem die Sonne aus dem Arsch scheint, und dann meinen dass HDR nur "catch-eye-bullshit" wäre.
die meisten (gamer) verstehen under hdr nur diesen bloom-blödsinn. richtiges hdr ist auch meiner meinung nach ein großer schritt zu photo-realismus in der computergraphik (achtung underschied realismus und photorealismus).


Deswegen bin ich auch sehr dafür vieles in die Kontrolle der Artists zu geben. Alles automatisch zu berechnen vom Computer macht keine "schöne Grafik". "Artist-controlled" ist der Weg - auch zu "realistischeren" (oder "realistischer wahrgenommenen") Grafiken.
full ack. virtuelle realität braucht einen architekten...


edit: bild 2 ist vom raytracer ;)

[Monger]

Ich teste dich:

Eine der beiden folgenden Reflexionen ist physikalisch korrekt mittels Raytrace-Shader berechnet (also "realistisch"). Die andere durch "gefakte" Reflexion mittels Cubemap-Environmentmapping.

Die Frage jetzt: welche der beiden Varianten ist welche?

http://www.cg.tuwien.ac.at/~chiu/gtp/refraction_off.png

http://www.cg.tuwien.ac.at/~chiu/gtp/refraction_on.png


Den einzigen nennenswerten Unterschied den ich sehe, sind in der Kugel diese Panele (oder was immer das auch sein soll) rechts in der Wand. Jetzt müsste man natürlich wissen, wie die wirklich aussehen sollten... Ich tippe aber auf 1) auf Cubemap, und 2) auf Raytracing.

[tombman]

Ich würde mich ned wundern wenn sogar das erste das geraytracete ist...

[Chris Lux]

es ist ganz einfach, schaut euch die reflektionen der dunklen stellen unten auf der kugel an. bei der cupemap technik geht man davon aus, dass alle reflektionen unendlich weit entfernte quellen hat. so gibt ein verzerrungen bei lokalen (nahen) reflektionen.

(ich hoffe ich mach mich hier grad nicht zu idioten ;))

[Gast]

raytracing spiegelungen müssen kein AA haben..


stimmt, aber das aliasing ist stärker als im restlichen bild, und die unschärfe deutet auf einen texturfilter hin, wobei mir gerade aufgefallen ist dass das ganze bild einen unschärfefilter hat, also vielleicht doch tracing?

[Kinman]

Ich würde sagen das zweite ist Raytracing, da man bei den Cubemaps sicherlich die Panele "sauberer" darstellt. Beim zweiten sind jedoch die schwarzen Flecken, dich ich für die ge-ra<tracte (scheiß wort, sry) Schrift halte -> Unterabtastung

mfg Kinman

[Gast]

Ich tippe auf keins von den beiden. Eins wird wohl über Distance Impostors laufen. Ich schätze das dürfte das 2. sein.
Bei konkaven Objekten fällt aber die Cubemap direkt auf, da keine Selfreflection vorhanden ist.

[mickii]

hehe ;)
ok, jetzt schauen wir das mal in einem nicht so extrem trivialen fall an wie einer kugel, sondern mal was 'realistischeres', konkaveres ;), nimm ein auto bspw. dort kann man sofort sagen, ob es korrekte reflektionen oder nicht sind.
nur wenn du davor stehst und versuchst es beim anstarren rauszufinden ob es echt ist oder nicht, sobald es nur ein effekt von vielen ist und man sich nicht drauf konzentriert, ist es kaum zu merken, sogar bei spielen wie GT4 wuerde es geraytraced kaum besser aussehen.


ich komm (wie zuletzt sehr oft) auf die source engine zu sprechen, dort werden alle (ausser wasser) reflektionen über approximierte cupemaps gemacht und in bewegung fällt _sofort_ auf, dass diese reflektionen nicht gut sind. dazu zähle ich, dass sie sich teilweise mit dem auge mitbewegen und nur für einen standpunkt in einem raum korrekt sind. klar könnte man das jedes frame neu generieren, doch dann muss man es für jedes objekt (oder teilobjekt machen) und das geht tierisch auf die performance.das ist beim raytracen nicht anders, jedes ray das bei reflektion abgeschickt wird zieht linear die performance runter (ist als ob man virtuell den screen vergroessern wuerde).

[tokugawa]

Schöne Bilder :) Ich denke aber richtig gut faken kann man erst, wenn man sich das Ergebnis des Raytrace-Shader ansieht.

Eins der beiden Bilder verwendet einen Raytrace-Shader.

weil man beim ersten den vollständigen gelben kreis, also auch das was hinter der kugel liegt in der kugel spiegeln sieht, was meiner meinung aus dieser position nicht sein kann.


Bingo. Der Unterschied einer normalen Environment-Mapping-Reflexion und einer Geraytracten Reflexion liegt nur in den nahen Objekten.


aber wahrscheinlich ist garkeines der bilder durch raytracing entstanden, zumindest das starke aliasing in der spiegelung deutet in beiden fällen auf eine zu gering aufgelöste cubemap hin.

Doch, das zweite Bild verwendet einen Raytrace-Shader, also raytracing im Shader, innerhalb von traditionellem Rendering (die Methoden kann man ja kombinieren).

Das Aliasing kommt von der geringen Auflösung.

Nochmals zur Klärung: hier sind die Bilder selbst (auch nicht das was reflektiert wird) nicht durch Raytracing entstanden, sondern die Reflexion, d.h. die Art wie Lichtstrahlen bei Reflexionen gebogen werden, sind durch Raytracing im Shader berechnet worden (im Prinzip eine bessere Variante, den Lookup in diese Cubemap zu machen).

Übrigens verwendet dieser Raytracing-Shader in dieser Fassung nur 2 Iterationen - für wirklich gute Ergebnisse (wo man aber auch als Laie nur marginal mehr Unterschied sieht) benötigt man 5-10 Iterationen, wo dann auch die Framerate dementsprechend sinkt.

hehe ;)
ok, jetzt schauen wir das mal in einem nicht so extrem trivialen fall an wie einer kugel, sondern mal was 'realistischeres', konkaveres ;), nimm ein auto bspw. dort kann man sofort sagen, ob es korrekte reflektionen oder nicht sind.


Nein, finde ich nicht. Bei konkaveren Objekten (Stanford-Bunny, oder den Drachen oder den Happy Buddha) sieht man mehr Unterschiede, aber es ist schwerer zu identifizieren, welches richtiger ist.

Der Test mit der Kugel ist der perfekte Test um die Richtigkeit zu bestätigen - denn die Richtigkeit sieht man an den nahen Objekten (gelber Ring).

Bei komplexeren Objekten würde da nur mehr eine Distortion sein, und es wäre noch viel schwieriger, zu identifizieren was "richtig ist".




wir reden hier aber nicht von standbildern.


Keines dieser neuen Raytracing-Verfahren geht auch nur irgendwie auf Bewegung, Animation, Gestik, Mimik ein. Die E-mail von diesem Quake-Raytrace-Typen ebenfalls nicht.

Es geht tatsächlich nur darum einzelne Bilder realistisch zu machen, was sich für den Gesamtrealismus nur minimal auswirkt. Und genau das kritisiere ich.

es ist ganz einfach, schaut euch die reflektionen der dunklen stellen unten auf der kugel an. bei der cupemap technik geht man davon aus, dass alle reflektionen unendlich weit entfernte quellen hat. so gibt ein verzerrungen bei lokalen (nahen) reflektionen.

(ich hoffe ich mach mich hier grad nicht zu idioten ;))

Exakt.

Ich tippe auf keins von den beiden. Eins wird wohl über Distance Impostors laufen. Ich schätze das dürfte das 2. sein.


Das stimmt. Allerdings verwenden Distance Impostors "Raytracing". Nicht zur Bildgenerierung, aber für den Lookup.

Es soll ja nur das Prinzip verdeutlichen, dass der Unterschied zwischen "gefakten" und genauer berechneten Methoden sehr sehr oft marginal ist, und für den Laien kaum sichtbar (und in Bewegung sowieso nicht).

[Chris Lux]

nur wenn du davor stehst und versuchst es beim anstarren rauszufinden ob es echt ist oder nicht, sobald es nur ein effekt von vielen ist und man sich nicht drauf konzentriert, ist es kaum zu merken, sogar bei spielen wie GT4 wuerde es geraytraced kaum besser aussehen.
das wüsste man erst, wenn man es geraytraced sehen würde. ;)
klar würde heutige spielegraphik einfach geraytraced nicht viel anders aussehen (siehe die q3 und q4 sachen)... aber hier geht es um rtrt und nicht primär um spiele.

das ist beim raytracen nicht anders, jedes ray das bei reflektion abgeschickt wird zieht linear die performance runter (ist als ob man virtuell den screen vergroessern wuerde).klar, aber wenn man die cubemaps richtig machen will (!) müsste man für jedes pixel eine cubemap bilden.

[Chris Lux]

Keines dieser neuen Raytracing-Verfahren geht auch nur irgendwie auf Bewegung, Animation, Gestik, Mimik ein. Die E-mail von diesem Quake-Raytrace-Typen ebenfalls nicht.
ich spreche hier auch nur von statischen szenen, selbst wenn man sich nur darin bewegen könnte würden fakes sehr schnell auffallen.

Es soll ja nur das Prinzip verdeutlichen, dass der Unterschied zwischen "gefakten" und genauer berechneten Methoden sehr sehr oft marginal ist, und für den Laien kaum sichtbar (und in Bewegung sowieso nicht).
genau den punkt würde ich bestreiten, in bewegung fällt es eher auf als im stand.

_aber_ computergraphik ist inhärent unrealistisch, da man immer versucht die natur nachzuahmen und im grunde alles fake ist...


edit: sorry für multipost :/

[mickii]

das wüsste man erst, wenn man es geraytraced sehen würde. ;)
klar würde heutige spielegraphik einfach geraytraced nicht viel anders aussehen (siehe die q3 und q4 sachen)... aber hier geht es um rtrt und nicht primär um spiele.was auf spiele zutrifft ist fuer andere renderings nicht anders.


klar, aber wenn man die cubemaps richtig machen will (!) müsste man für jedes pixel eine cubemap bilden.
auch wenn man pixelweise auf dem screen traced wird das pro strahl linear teurer, allerdings spiegeln die wenigsten materialien perfekt, somit waere eigentlich ne cubemap + bluren schneller als pro spiegelndem screenpixel viele strahlen zu schicken.

[Gmax]

Ab DX10.1 wird es verstärkt um Global Illumination gehen; vielleicht nicht ganz uninteressant in diesem Zusammenhang.

http://download.microsoft.com/download/e/5/5/e5594812-cdaa-4e25-9cc0-c02096093ceb/the%20future%20of%20directx.zip