"Raytracing in Spielen" von Daniel Pohl

[betasilie]

http://www.computerbase.de/artikel/hardware/grafikkarten/2008/bericht_raytracing_spielen_20/


Finde ich sehr interessant zu lesen. Mal schauen, wann der Umbruch dann wirklich kommt. Ich denke schneller, als manch einer denkt. :)

[Godmode]

Ich kann mir schwer vorstellen das der Umbruch schnell kommt. Momentan gibt es unendlich viel Software und Tools welche alle auf Rasterisierung basieren. Wenn du das jetzt alles nicht mehr verwenden kannst und alles neu schreiben musst, wird das ziemlich teuer. Ich könnte mir vorstellen das es eher fließend gehen wird. Zuerst wird vielleicht eine API geschaffen, die dann die IHVs implementieren. Bis diese dann von wirklich vielen Spieleentwicklern genützt wird, vergeht wohl auch wieder einige Zeit.

[Anarchy-HWLUXX]

Besonders im Softwarebereich geht nix schnell - schon garnicht so ein technologiewechsel.

[betasilie]

Ich kann mir schwer vorstellen das der Umbruch schnell kommt. Momentan gibt es unendlich viel Software und Tools welche alle auf Rasterisierung basieren. Wenn du das jetzt alles nicht mehr verwenden kannst und alles neu schreiben musst, wird das ziemlich teuer. Ich könnte mir vorstellen das es eher fließend gehen wird. Zuerst wird vielleicht eine API geschaffen, die dann die IHVs implementieren. Bis diese dann von wirklich vielen Spieleentwicklern genützt wird, vergeht wohl auch wieder einige Zeit.
Klar gibt es dort mehrer Hürden.

Zum ersten mal die IHVs ("ATI", nVidia), die ihrer Rasterizer-GPUs und die vielen Jahre der Investitionen gerne weiter am Markt sehen würden. Zum anderen natürlich auch die Entwickler, die die derzeitigen Rasterizer-Technologie schreiben, wobei ich durchaus denke, dass einige Studios darauf brennen vom Rasterizer wegzukommen.

Intel auf der anderen Seite, und IBM und Sony mit dem Cell ganz sicher auch, werden den Rasterizer ablösen wollen und dementsprechend auch Pläne in der Tasche haben. Auch MS wird daran Interesse haben, denn sie werden in Hinblick mit ihren Konsolen sicher nicht zu spät eine funktionierende RT-API für kommende Konsolen haben wollen, die erstmal unter Windows getestet werden solle, bevor man damit auf Konsole kommt.

Daher steht eigentlich der Großteil des Hardware-Marktes (Intel, IBM/Sony/Toshiba und MS) RT positiv gegenüber, mit Ausnahme von nVidia, die das ganze zumindest hinauszögern werden wollen. Wie AMD/ATi dazu stehen mögen, würde mich allerdings mal interessieren.


Ich denke es wird letztendlich sogar ein richtiger Wettlauf werden, weil niemand die Chance dieses neuen Marktes verpassen will. Die Karten werden völlig neu gemischt, egal ob auf Hardware-Ebene oder auf Software-Ebene. Wenn MS mitspielt, dessen ich mir sicher bin, weil sie es in Hinblick auf ihre Konsolen müssen, denn dort haben sie Konkurrenz, wird das ganze recht zügig gehen, imho. ;)


Besonders im Softwarebereich geht nix schnell - schon garnicht so ein technologiewechsel.
Schnell ist relativ. Das erste Studio, was eine vernünftige Engine liefert und gute Tools, wird extrem profitieren durch Lizenzen und Co. ... Wenn der Markt reif ist, wird es schon Studios geben, die ihre Chance nutzen wollen. Wer zuletzt kommt, den Bestraft das leben. Und das ganze ist eben keine neue DX-Version, daher ist es sogar Vorteilhaft auf RTs zu setzen, eben weil man nicht mehr diese ganzen Techlevel hat.

[betasilie]

Mich würde die technische Realität mal interessen.

Wird es eher so aussehen, dass echte CPUs auf dem Mainboard sich für RT etablieren, was natürlich kostengünstig für die Kunden wäre, oder werden sich eher Grafikkarten durchsetzen, die CPUs oder (semi-)dedizierte Hardware (wie z.B. Cell) mit schnellem Speicher anbieten?

[Coda]

Ich denke schneller, als manch einer denkt. :)
Ich nicht.

Viel zu viel ungelöste Probleme.

[betasilie]

Ich nicht.

Viel zu viel ungelöste Probleme.
Sehr viel Inhalt. :rolleyes:

Und schnell ist wohl relativ.

[Coda]

Das wurde hier schon unendlich oft diskutiert. Z.B. kannst du wenn du Raytracing verwendest Vertex- und Geometry-Shader grad mal vergessen. Das Konzept funktioniert da einfach nicht. Dynamische Geometrie ist allgemein ein großes Problem, auch wenn es inzwischen relativ gute In-Flight-Sortierungsalgorithmen gibt.

Außerdem ist Raytracing nur deutlich effizienter wenn du wirklich extrem viele Polygone zeichnen willst. Also deutlich mehr als Pixel auf dem Bildschirm. Das darfst du aber nicht, sonst flimmert dir es das Hirn raus. Das heißt man braucht eh wieder LOD und Rasterisierung ist wieder effizienter.

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.

Nur für die Bling-Bling-100%-Reflexionen und harte Schatten brauchen wir ganz sicher kein Raytracing. Sobald man dann diffuse Reflexionen und Softshadows machen will sind die Hacks mit Rasterisierung wieder billiger.

Raytracing sollte man sicher nicht aus den Augen verlieren. Aber ich wäre sehr erstaunt wenn es Rasterisierung verdrängt. Das wird sehr viel eher nebenherlaufen und man wird je nach Gebiet das Beste aus den beiden Welten einsetzen. Raytracing ist NICHT der heilige Gral des Realtime-Renderings. Es löst die Probleme die wir momentan haben auch nicht - was vor allem vollständige indirekte Echtzeit-Beleuchtung ist.

Mich regt diese Stimmungsmache seitens Intel usw. derzeit mächtig auf. Es ist nicht so als würde Raytracing die lilabunte Traumwelt jedes Grafikprogrammiers sein.

Nur mal zur Info: "Transformers" (Der Film, 2007) wurde zum größten Teil mit einem Rasteralgorithmus gerendert - auch wenn man den nicht mit dem Vergleichen kann was GPUs momentan machen. Und das Zeug was sie raytracen mussten weil sie Spiegelreflexionen haben wollten hat ewig gedauert. Vor "Cars" hat Pixar/ILM überhaupt kein Raytracing verwendet.

[betasilie]

Danke für das ausführliche Posting. :)

Ich bin mal gespannt, wie sich dass dann wirklich entwickelt, rein zeitlich. Wenn man bedenkt, dass Sony irrwitziger Weise vorhatte die PS3 mit 4 Cells als reine Raytracing laufen zu lassen, lagen sie da wohl zeitlich recht weit daneben, was die Machbarkeit angeht.

Bei den Anstrengungen, die Intel gerade aufbringt, würde es mich jedenfalls nicht wundern, wenn wir 2012/2013 das erste kommerzielle Spiel auf Basis einer RT-Engine sehen werden. Ob das dann was taugt, wird sich zeigen.

[BlackBirdSR]

Alles was ich an Raytracing bisher gesehen habe, zeigt einen unverwechselbar sterilen Charakter. Der warme Ton vieler Spiele weicht einem harten, scharfen Bild. Daran müsste ich mich erst einmal gewöhnen. Content-Hersteller wohl ebenso um dem entgegenzuwirken.
Alleine das sollte Raytracing ausreichend bremsen, dass es nicht so genial einschlagen wird, wie Intel gerne hätte.

Eventuell wird Larabee wirklich sehr stark in dieser Hinsicht. Dann würde ich Raytracing auch propagieren. Allerdings hat in der Geschichte schon viele Sachen voller Überzeugung propagiert...

[Demirug]

Intel tanzt auf vielen Hochzeiten und ein paar Leute die mit Raytracing rumspielen zahlt man doch aus der Portokasse.

BTW: Ich habe noch keinen aus der Raytracing Gruppe gesehen dessen Jobbezeichung Larrabee enthält. Aus dem Raster Lager gibt es dagegen welche. ;)

[MadManniMan]

Nanu? Gibt es denn Infos dazu, wie Transformers genau gerendert wurde? Und was Pixar vor Cars verwandt?

[Abe Ghiran]

Carmack zum Thema Ray Tracing: http://www.pcper.com/article.php?aid=532&type=expert
Wobei Coda ja schon alles wesentliche gesagt hat, Carmack schlägt in die selbe Kerbe.

Grüße,
Jan

[robbitop]

Ich finde es bedenklich, dass man auf CB einen Artikel-Zweiteiler veröffentlichen ließ, der nur die Rosinen von Raytracing herauspickt, aber nicht die Nachteile aufzeigt. Objektiver Journalismus ist was anderes.
Wenn man sieht, von wem der Kram ist (jemandem, der bei Intel arbeitet und vorher Jahrelang sich begeistert mit dem Thema auseinander gesetzt hat) wundert es natürlich nicht all zu sehr. Nicht's gegen Daniel, er ist nicht umsonst bei Intel eingestellt worden. Aber es scheint ja Firmenpolitik dahinter zustecken, sonst hätte er sich gewiss objektiver dazu geäußert.
Vieleicht hätte CB den Daniel nach dem Lesen des Artikels bitten sollen, auch die Nachteile zu erläutern, so wie er es mit den Vorteilen machte.
Schon der 2. CB-Artikel diesen Monat, der m.E. Halbwahrheiten schön in die Masse verstreut. Was ist da bloß los?

[Spasstiger]

Daniel Pohl ist schon viel zu sehr von den Vorteilen des Raytracing überzeugt, um einen neutralen Artikel zu schreiben. Die Artikel helfen auf jeden Fall, zu verstehen, wie man Raytracing in Echtzeit umsetzen kann, wenn genug Rechenleistung zu Verfügung steht. Sie klären aber nicht darüber auf, was sich mit reinem Raytracing nicht umsetzen lässt.
Raytracing ist automatisch physikalisch korrekt (im Rahmen der verwendeten Auflösung bzw. Strahlendichte), was die künstlerische Freiheit einschränkt.

Gestört hat mich z.B. die Sache mit den Vis-Portal-Bäumen. Erst versteift er sich im Artikel darauf, dass der Rechenaufwand bei Rasterisierung durch die Nichtverwendung von solchen Bäumen linear ansteigt, beim Raytracing nur logarithmisch. Später im Artikel gesteht er ein, dass solche Bäume auch bei der Rasterisierung verwendet werden, erwähnt aber im gleichen Atemzug, dass solche Portale bei der Rasterisierung umständlich seien, weil sie von Hand gesetzt werden müssen. Ich sehe ehrlichgesagt kein Problem darin, von einem Mapcompiler solche Portale automatisch setzen zu lassen. Schwierig wird es freilich bei in Echtzeit erzeugter Geometrie, aber hat da Raytracing Vorteile?

Aber man kann ihm seine Voreingenommenheit auch nicht wirklich verübeln. Er ist bei Intel sicherlich hochmotiviert durch den Zugang zu Spitzentechnologie und sehr potenten Rechenclustern. Da kann man auch mal Spielereien implementieren, die ohne diese Hardware viel zu viel Zeit fürs Testen in Anspruch nehmen würde.
Ein Dozent bei uns an der Uni schwärmt z.B. vom (clusterbasierten) VHDL-Simulator bei IBM in Böblingen. Da kann man VHDL-Modelle in Echtzeit simulieren, die auf einer Standardworkstation Wochen brauchen würde, um nur einige Sekunden Programmausführung zu simulieren.

[Gast]

Daher steht eigentlich der Großteil des Hardware-Marktes (Intel, IBM/Sony/Toshiba und MS) RT positiv gegenüber, mit Ausnahme von nVidia, die das ganze zumindest hinauszögern werden wollen.
Wie kommst du drauf, dass Nvidia eine Ausnahme bildet?
Die arbeiten da auch dran.

Klar gibt es mit Raytracing noch Probleme und für den momentanen Techlevel ists auch uninteressant. Die Vorteile bei vielen Polygonen sind auch eher... unwichtig.

Aber ihr vergesst, dass sich viele Tricks der Rasterizer auch auf Raytracer übertragen lassen. Grade im Bereich der Schatten kann man da noch vieles optimieren. Wie wärs zum Beispiel mit Screenspace Shadowmaps? Haben genau die passende Auflösung und können auch wiederverwendet werden.

Problem bei der Rasterisierung ist der Trend zu Higher-Order-Surfaces (siehe GDC08 Präsentationen von NV und AIT) und in ein paar Jahren die Zahl der Informationen die beim Raytracing durch Secondary-Rays gelöst werden. Die Primary Rays sind teurer, aber ihr Anteil an der Gesamtberechnung sinkt stetig.

[Coda]

Nanu? Gibt es denn Infos dazu, wie Transformers genau gerendert wurde? Und was Pixar vor Cars verwandt?
ILM und Pixar verwenden ausschließlich Renderman und der basiert auf Reyes (http://en.wikipedia.org/wiki/Reyes_rendering) (Mikropolygonrendering).

Es wurde in letzter Zeit aber zusätzlich dazu Raytracing für Reflexionen implementiert.

...ist der Trend zu Higher-Order-Surfaces (siehe GDC08 Präsentationen von NV und AIT)..
Welche meinst du genau?

[Thorwan]

Gestern gab es auf PC Perspective ein Interview mit John Carmack zum gleichen Thema:
http://www.pcper.com/article.php?aid=532&type=overview

Edit: ups, wurde ja doch schon gepostet :(
Dann eben noch ein Interview mit Dr. David Kirk, Chief Scientist of NVIDIA zum gleichen Thema von Anfang des Monats:
http://www.pcper.com/article.php?aid=530

[Exxtreme]

Die nächste Sau wird durch's Dorf getrieben. Wäre RT spieletauglich dann hätte man es längst. Wenn man die Rechenpower, die man ins RT stecken muss, ins Rastersizing steckt dann kommt viel mehr dabei raus. Zumindest bei den jetzigen Spielen.

[Spasstiger]

Im CAD-Bereich könnte Echtzeitraytracing für Kundenpräsentationen oder auch einfach nur für eine schnelle und hübsche Visualisierung durchaus Anklang finden. Gerade das Beispiel aus dem Artikel mit der Boeing zeigt doch ein mögliches Einsatzfeld. Im Spielebereich sehe ich die nähere Zukunft eher in Hybridmethoden, Raytracing für komplexe Spiegelungen und evtl. auch Kameraportale, Rasterisierung für alles andere.
Freuen würde es mich aber schon, wenn man zukünftig evtl. tatsächlich alles auf einer CPU rendern könnte, z.B. auf einem 64-Core-Prozessor. Das kommt einerseits dem Energieverbrauch zu Gute und spart andererseits auch Platz und Geld.

[Crazy_Chris]

Freuen würde es mich aber schon, wenn man zukünftig evtl. tatsächlich alles auf einer CPU rendern könnte, z.B. auf einem 64-Core-Prozessor. Das kommt einerseits dem Energieverbrauch zu Gute und spart andererseits auch Platz und Geld.

Das wäre nur ein weitere logischer Schritt weg von dedizierter Hardware. Bis 2015 wären solche Prozessoren im Desktop sicher denkbar. :tongue:

[PatkIllA]

Freuen würde es mich aber schon, wenn man zukünftig evtl. tatsächlich alles auf einer CPU rendern könnte, z.B. auf einem 64-Core-Prozessor. Das kommt einerseits dem Energieverbrauch zu Gute und spart andererseits auch Platz und Geld.Der angepasste Grafikchip hat einem um Welten besseren Energie und Platzbedarf sowie Transistorcount auf die Rechenleistung bezogen.
Eine Core Archtiktur mit 64 Kernen wäre immer noch langsamer als eine jetzt schon zu habende Grafikkarte.

Und auch bei 1000 facher Rechenleistung müssen bei Echtzeitrendering noch Kompromisse gemacht werden und hat noch keinen Fotorealismus.

[Aquaschaf]

Im Spielebereich sehe ich die nähere Zukunft eher in Hybridmethoden, Raytracing für komplexe Spiegelungen und evtl. auch Kameraportale, Rasterisierung für alles andere.

Ich denke das gerade Reflektionen als Argument stark überbewertet werden. Mit Tricks kriegt man es eben ziemlich gut hin das es schick aussieht. Auch wenn es nicht korrekt ist.

[Gosh]

Hab nicht ein Beispiel gesehn wo die Technik nur ansatzweise überzeugen kann.

[san.salvador]

Hab nicht ein Beispiel gesehn wo die Technik nur ansatzweise überzeugen kann.
Stichwort "Entwicklung". :rolleyes:

[Coda]

Das schlimmste am Artikel sind so arrogante Aussagen wie:

Die Ansätze der Rasterisierung in Bezug auf Korrektheit und Genauigkeit sind bei Schatten, Spiegelungen und Brechungen nicht akkurat genug.
Stencil-Shadows mit Rasterisierung erzeugen exakt das gleiche Ergebnis wie harte Schatten und Raytracing.

Außerdem wer will denn bitte exakte Ergebnisse bei Spielen? Es muss gut aussehn und mehr nicht.

[deekey777]

Hab nicht ein Beispiel gesehn wo die Technik nur ansatzweise überzeugen kann.
Nenne wenigstens ein paar Beispiele, die dich nicht überzeugt haben.

[dargo]

Das wäre nur ein weitere logischer Schritt weg von dedizierter Hardware. Bis 2015 wären solche Prozessoren im Desktop sicher denkbar. :tongue:
Wenn ich an den Fortschritt der letzten 7 Jahre bei der Rasterisierung zurückdenke dann frage ich mich wieviele Cores man für ein in 2015 aktuelles Spiel braucht? 500 oder 1000? :D

Außerdem frage ich mich warum so viele darauf scharf sind alles von der CPU berechnen zu lassen. Die CPU-Entwicklung geht viel langsamer voran als es bei den üblichen Grafikkarten der Fall ist.

[AnarchX]

Außerdem frage ich mich warum so viele darauf scharf sind alles von der CPU berechnen zu lassen. Die CPU-Entwicklung geht viel langsamer voran als es bei den üblichen Grafikkarten der Fall ist.
Mit Intels Tera-Scale-Projekt könnte sich das in Zukunft aber ganz schnell ändern:
http://www.beyond3d.com/content/articles/31/1
Und mal abwarten ob GT200 sich nicht vielleicht wieder ein größeres Stück in Richtung CPU bewegen wird.

Aber an reines Raytracing glaube ich nicht wirklich, Demirug deutet (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6350399&postcount=11) es ja auch an, dass Intel sich auf für (Software-)Rasterisierung bzw. einen Zwischenweg interessiert.

[Coda]

Außerdem frage ich mich warum so viele darauf scharf sind alles von der CPU berechnen zu lassen. Die CPU-Entwicklung geht viel langsamer voran als es bei den üblichen Grafikkarten der Fall ist.
Eigentlich nicht. GPUs skalieren halt über die Anzahl der Einheiten, das ist bei CPUs noch nicht so lange der Fall.

[dargo]

Eigentlich nicht. GPUs skalieren halt über die Anzahl der Einheiten, das ist bei CPUs noch nicht so lange der Fall.
Meinst du den Sprung von Singlecore auf Multicore? Das schon, nur wie will man heute oder von mir aus nächstes Jahr 16 und mehr Cores mit sagen wir mal der Leistung eines C2D auf einem Die (oder zumindest Package) unterbringen. Da bekommt man ganz schnell thermische Probleme. Ich frage mich auch gerade wieviel Leistung man für ein Crysis (raytraced) braucht. Quake4 ist schon lange kein Maßstab mehr.

[AnarchX]

Meinst du den Sprung von Singlecore auf Multicore? Das schon, nur wie will man heute oder von mir aus nächstes Jahr 16 und mehr Cores mit sagen wir mal der Leistung eines C2D auf einem Die (oder zumindest Package) unterbringen.
Einfach mal in den verlinkten Artikel @B3D schauen:
http://www.beyond3d.com/images/articles/IntelFuture/Image9-big.jpg
;)
Zwar ist das noch ein Blick in Richtung >2010, aber schon Nehalems SMT könnte interessant sein im Bezug auf Raytracing bzw. Software-Rendering, vorallem da ja manche Nehalem-SKU mit einem IGP daherkommen soll.

[Coda]

Da bekommt man ganz schnell thermische Probleme.
Ach und GPUs werden nicht immer heißer weil sie immer breiter werden oder was?

Ich frage mich auch gerade wieviel Leistung man für ein Crysis (raytraced) braucht. Quake4 ist schon lange kein Maßstab mehr.
Verdammt viel. Auch ein Grund warum ich mich immer frage was die Diskussion soll.

[dargo]

Einfach mal in den verlinkten Artikel @B3D schauen:
http://www.beyond3d.com/images/articles/IntelFuture/Image9-big.jpg
;)
Zwar ist das noch ein Blick in Richtung >2010, aber schon Nehalems SMT könnte interessant sein im Bezug auf Raytracing bzw. Software-Rendering, vorallem da ja manche Nehalem-SKU mit einem IGP daherkommen soll.
AnarchX, das ist zwar alles schön und gut. Nur was nützt mir das in sagen wir mal 4 Jahren wenn dann schon eventuell eine CryEngine3 existiert. Welche CPU braucht man dann für diese Engine? :ugly:
Bedenke auch, dass diese CPU dann auch noch bezahlbar sein muss, also im Bereich von ca. 100-300€ liegen sollte. Diese ganzen Folien sind zwar schön bunt und man kann wieder schöne Zahlen präsentieren. Mehr als Marketing sehe ich da aber nicht.

Ach und GPUs werden nicht immer heißer weil sie immer breiter werden oder was?

Natürlich werden sie heißer. Aber schau dir doch mal einen 3Ghz Quadcore von Intel in 65nm an. Die GPUs sind auch gerade in dieser Fertigungstechnologie vorhanden (ok, außer AMD/ATI).
Diese CPU hat gerade mal 4 Cores was total lächerlich für Raytracing ist. 8 Cores sind in 65nm unmöglich. Wie soll das dann erst mit 16 Cores aussehen. Ich wette sogar, dass wir 16 Core-CPUs frühestens erst mit 32nm sehen werden.

Edit:
Dabei sollte man auch nicht vergessen, dass die Gesamt-Stromaufnahme einer Grafikkarte zum großen Teil sich nicht nur auf die GPU bezieht. Nehme ich bei der CPU die Verlustleistung der Stromversorgung vom Mainboard und den Arbeitsspeicher dazu (wobei Letzterer keine große Rolle spielt) sieht die Verlustleistung der CPU schon ganz anders aus.

[heartache]

Noch mal zum Thema Pixar und Cars -> Klick (http://www.informationweek.com/hardware/personaltech/189501146)

"In going from a more traditional approach in the movie "The Incredibles," to ray tracing in "Cars," it increased the render time by a factor of 10. One frame typically takes about eight hours to render at 2K resolution."

[AnarchX]

AnarchX, das ist zwar alles schön und gut. Nur was nützt mir das in sagen wir mal 4 Jahren wenn dann schon eventuell eine CryEngine3 existiert. Welche CPU braucht man dann für diese Engine? :ugly:

Aber diese Frage stellt sich auch im Bezug auf die GPU, wenn Crytek wieder meint solche Ansprüche zu stellen, wie sie es mit der aktuellen Engine taten.
Zudem düften wir uns dann schon in einer erweiterten Version von D3D11 befinden, die dann wohl noch deutlich höhere Programmierbarkeit erlaubt, was wiederum den dann erhätlichen Multi-Core-"CPUs" entgegenkommt

Wie schon gesagt, darf man in diesem Zeitraum nicht mehr an heute übliche CPUs denken, Tera-Scale startet vorerst in Form von Co-Prozessoren, die man in Form von Larrabee zuerst kaufen kann, aber eine Integration in Sandy Bridge-CPUs, die zwar an sich noch auf herkömlichen Architekturen basieren, scheint wohl auch geplant zu sein.
Beim 2011/12er "Tock" (http://www.computerbase.de/news/hardware/prozessoren/intel/2008/maerz/intel_produktroadmap_2012/), der auf 22nm basieren soll, würde es mich nicht wundern, wenn hier Tera-Scale die vollständige Architekturbasis stellt.


Bedenke auch, dass diese CPU dann auch noch bezahlbar sein muss, also im Bereich von ca. 100-300€ liegen sollte.

Da Intel stets mit seiner Fertigung voraus war würde ich im Bezug auf den Preis durchaus Vorteile sehen.

Die Bilder bei B3D sind zwar bunt, aber doch steckt in den dort gemachten Aussagen viel wahres drin und man sollte sich noch von der Aufmachungen abschrecken lassen, sich ein paar Gedanken darüber zu machen.

Aber um wieder auf das eigentlich Thema zurück zu kommen, reines Raytracing wird kaum der Weg sein und das wird auch Intel wissen.

[dreas]

Wir würde wohl ein neu programmiertes Outcast auf aktuellen Dualcores laufen?
Das war doch quasi raytraced oder?
mfg dreas

[Coda]

2D-Raycasting. Also nur die Primary Rays und ein sehr vereinfachter Fall. Aber Rasterization wäre auch dort locker schneller bei gleicher Optik.

[HOT]

Intel muss erstmal zeigen, dass Larrabree in der Lage ist, ein Spiel, das traditionell erstellt wurde (als auf SM4 GPUs läuft) überhaupt was konkurrenzfähiges zu basteln, denn mit der Art "GPU" glaube ich da noch nicht so ganz dran (zumal die Treiber meiner Meinung nach wieder eine Katastrophe werden, Intel hat noch nie anständige Treiber basteln können...). Solange Intel nicht mal ansatzweise High-End Hardware herstellen kann, gibt NV in dem Segment den Ton an, da wirds nix mit RT. Auch die nächste und übernächste Konsolengeneration wird nix von RT wissen wollen, ganz einfach, weil da NV und ATI(AMD) die Hardware liefern - das kann niemand sonst mehr ;). RT in Spielen ist einfach ein grosses Luftschloss, das nicht nicht mit der Entwicklung der Rasterizer mithalten kann, ganz einfach, weil die RT Entwicklung nicht so forciert wird. Solange in die Entwicklung von Rasterizern Milliarden fließen und in RT nichts, kann aus RT auch nichts werden ;). Auch wenn die GPU zu GPGPUs werden, wird RT höchstens ein Nischendasein fristen, weil der Schwerpunkt der Entwicklung immernoch das traditionelle Rendering ist und das "GP" eigentlich nur ein netter Nebeneffekt ist.
Intel sieht das natürlich anders, aber die greifen eh nach jedem Strohhalm, der sie zu einem eigenen Standard führt, mit der man die Industrie zwingen kann, nurnoch Intel-Hardware zu verkaufen. Das ist schon seit jeher Intel-Strategie, siehe IA64. Mit diesen Massiv-Multikernen ist das nicht viel anders, die werden meiner Meinung nach genauso an der Software scheitern wie IA64/VLIW/EPIC-CPUs. Wenn Intel es schafft, eine GPU auf die Beine zu stellen, die was taugt, hat das Projekt zukunft, ansonsten wirds halt wieder ein Milliardengrab... da kann der Multikern GP sein, wie er will. Und ganz sicher setzt in dem Segment eher CUDA + CTM den Standard und nicht Intel.

[PHuV]

Wenn Intel es schafft, eine GPU auf die Beine zu stellen, die was taugt, hat das Projekt zukunft, ansonsten wirds halt wieder ein Milliardengrab...

Na, glaube ich eher nicht. Die Forschungsarbeiten werden sich in der Weise rentieren, daß es einen großen Einfluß auf Rendering im Allgemeinen haben wird. Zumindest wird die Film- und virtuelle Effektindustrie indirekt oder indirekt davon profitieren.

[HOT]

Das sicherlich, dennoch ist es aus PC-Sicht dann uninteressant. Das ändert nichts an meiner Aussage.

[Gast]

Solange Intel nicht mal ansatzweise High-End Hardware herstellen kann, gibt NV in dem Segment den Ton an, da wirds nix mit RT. Auch die nächste und übernächste Konsolengeneration wird nix von RT wissen wollen, ganz einfach, weil da NV und ATI(AMD) die Hardware liefern - das kann niemand sonst mehr ;). RT in Spielen ist einfach ein grosses Luftschloss, das nicht nicht mit der Entwicklung der Rasterizer mithalten kann, ganz einfach, weil die RT Entwicklung nicht so forciert wird.

du brauchst für RT nicht unbedingt eigene hardware, heutige GPUs sind programmierbar genug um auch eine RT-engine darstellen zu können, sogar für SM3-gpus gab es mal ein RT-demo.

[_DrillSarge]I[]

PC Perspective: Let’s just jump right into the issue at hand. What is your take on current ray tracing arguments floating around such as those featured in a couple of different articles here at PC Perspective? Have you been doing any work on ray tracing yourself?


John Carmack: I have my own personal hobby horse in this race and have some fairly firm opinions on the way things are going right now. I think that ray tracing in the classical sense, of analytically intersecting rays with conventionally defined geometry, whether they be triangle meshes or higher order primitives, I’m not really bullish on that taking over for primary rendering tasks which is essentially what Intel is pushing. (Ed: information about Intel's research is here.) There are large advantages to rasterization from a performance standpoint and many of the things that they argue as far as using efficient culling technologies to be able to avoid referencing a lot of geometry, those are really bogus arguments because you could do similar things with occlusion queries and conditional renders with rasterization. Head to head rasterization is just a vastly more efficient use of whatever transistors you have available.



But, I do think that there is a very strong possibility as we move towards next generation technologies for a ray tracing architecture that uses a specific data structure; rather than just taking triangles like everybody uses and tracing rays against them and being really, really expensive. There is a specific format I have done some research on that I am starting to ramp back up on for some proof of concept work for next generation technologies. It involves ray tracing into a sparse voxel octree which is essentially a geometric evolution of the mega-texture technologies that we’re doing today for uniquely texturing entire worlds. It’s clear that what we want to do in the following generation is have unique geometry down to the equivalent of the texel across everything. There are different approaches that you could wind up and try to get that done that would involve tessellation and different levels of triangle meshes and you can could conceivably make something like that work but rasterization architecture does really start falling apart when your typical triangle size is less than one pixel. At that point you really have lost much of the benefits of rasterization. Not necessarily all of them, because linearly walking through a list of primitives can still be much faster than randomly accessing them for tracing, but the wins are diminishing there.

In our current game title we are looking at shipping on two DVDs, and we are generating hundreds of gigs of data in our development before we work on compressing it down. It’s interesting that if you look at representing this data in this particular sparse voxel octree format it winds up even being a more efficient way to store the 2D data as well as the 3D geometry data, because you don’t have packing and bordering issues. So we have incredibly high numbers; billions of triangles of data that you store in a very efficient manner. Now what is different about this versus a conventional ray tracing architecture is that it is a specialized data structure that you can ray trace into quite efficiently and that data structure brings you some significant benefits that you wouldn’t get from a triangular structure. It would be 50 or 100 times more data if you stored it out in a triangular mesh, which you couldn’t actually do in practice.



I’ve been pitching this idea to both NVIDIA and Intel and just everybody about directions as we look toward next generation technologies. But this is one of those aspects where changing the paradigm of rendering from rasterization based approach to a ray casting approach or any other approach is not out of the question but I do think that the direction that Intel is going about it as a conventional ray tracer is unlikely to win out. While you could start doing some real time things that look interesting its always going to be a matter of a quarter the efficiency or a 10th of the efficiency or something like that. Intel of course hopes that they can win by having 4x the raw processing power on their Larrabee versus a conventional GPU, and as we look towards future generations that’s one aspect of how the battle may shape up. Intel has always had process advantage over the GPU vendors and if they are able to have an architecture that has 3-4x the clock rate of the traditional GPU architectures they may be able to soak the significant software architecture deficit by clubbing it with processing power.



From the developers stand point there are pros and cons to that. We could certainly do interesting things with either direction. But literally just last week I was doing a little bit of research work on these things. The direction that everybody is looking at for next generation, both console and eventual graphics card stuff, is a "sea of processors" model, typified by Larrabee or enhanced CUDA and things like that, and everybody is sort of waving their hands and talking about “oh we’ll do wonderful things with all this” but there is very little in the way of real proof-of-concept work going on. There’s no one showing the demo of like, here this is what games are going to look like on the next generation when we have 10x more processing power - nothing compelling has actually been demonstrated and everyone is busy making these multi-billion dollar decisions about what things are going to be like 5 years from now in the gaming world. I have a direction in mind with this but until everybody can actually make movies of what this is going to be like at subscale speeds, it’s distressing to me that there is so much effort going on without anybody showing exactly what the prize is that all of this is going to give us.

mehr: http://www.pcper.com/article.php?aid=532&type=overview

[DR.ZEISSLER]

Wir würde wohl ein neu programmiertes Outcast auf aktuellen Dualcores laufen?
Das war doch quasi raytraced oder?
mfg dreas

ja:biggrin:,

intel veröffentlicht den 16core mit voller raytracing spiele-engine und als promo-spiel ein outcast remake in full hd.;D;D;D
...wo kann ich bestellen ?

doc

[Coda]

du brauchst für RT nicht unbedingt eigene hardware, heutige GPUs sind programmierbar genug um auch eine RT-engine darstellen zu können, sogar für SM3-gpus gab es mal ein RT-demo.
Effizient ist was anderes.

[Gast]

Finde ich schon drollig. Alle Programmierer, die hier auch wohl Ahnung von der Materie haben, schreien nach DX10, weil sich damit Sachen machen lassen, die mit DX9 niemals möglich wären, die aber einem normal sterblichen weder verständlich noch erwähnenswert wichtig sind. Und man unterhält sich schon über die Möglichkeiten von DX11 und und und.
Dann ist da jemand, der eine andere Art der Berechnung und Darstellung bevorzugt, weil sie ihm besser und perfekter erscheint. Und sofort schreien alle, das geht niemals, das bringt nichts, ach du meine Güte, was soll das denn, knüpft ihn auf usw. usf.
Da geht mir doch durch den Kopf, ob die alteingesessenen D3D Programmierer Angst um ihr (anerkannt) sehr grosses Know How haben, weil es eines Tages vielleicht keiner mehr braucht und vielleicht auf den Raytracing Zug aufspringen müssen.
Wartet doch einfach mal und wartet mal ein Jahr ab. Vielleicht hat der gute Pohl ja doch mit Zitronen gehandelt und es wird nie etwas. Vielleicht ist er aber auch schon ein gutes Stück weiter, wer weiss.
Jeder fängt mal (mehr oder weniger) klein an. Und wenn alle als Spinner beschimpften Erfinder ihre Arbeit eingestellt hätten, gäbe es heute so einiges an Technik und Fortschritt nicht.

[Aquaschaf]

Vielleicht ist er aber auch schon ein gutes Stück weiter, wer weiss.
Jeder fängt mal (mehr oder weniger) klein an. Und wenn alle als Spinner beschimpften Erfinder ihre Arbeit eingestellt hätten, gäbe es heute so einiges an Technik und Fortschritt nicht.

Es geht ja nicht ums Prinzip, sondern darum dass Daniel Pohl mal wieder eine extrem einseitige und unreflektierte Darstellung in dem Artikel abgeliefert hat die überhaupt nichts neues oder interessantes bringt.

[Gast]

Na ja, das seine Sicht einseitig ist, ist vielleicht ja auch ein wenig nachvollziehbar. Genau so einseitig, wie auch die der D3D Fürsprecher. Das ist halt menschlich.
Ob in seinem Artikel nun neues oder interessantes steht, ist für mich persönlich nun nicht mal so wichtig. Fakt ist aber, das er ein spielbare Version eines (zugegebenermaßen) alten Spiels auf die Beine gestellt hat. Das hätte vor Jahren niemand erwartet.
Ob das nun besser oder schlechter aussieht, als die Originalversion sei mal dahingestellt. Aber es funktioniert zumindest. Die ersten 3D Beschleuniger waren ja auch eher 3D-Verlangsamer.
Das aber Intel jetzt mit an dieser Sache forscht oder Geld hineinsteckt ist aber zumindest bemerkenswert.

Prinzipiell geht es mir aber darum, das diese Geschichte hier von vornherein totgeredet wird. Warum? Natürlich haben hier in diesem Forum eine handvoll Leute sicherlich ordentlich Know-How im 3D Bereich. Ich glaube aber, das im Bereich des Raytracings andere Leute halt doch erheblich mehr Ahnung haben. Wenn diese Technologie von vornherein komplett aussichtslos wäre, würde Intel ja keinen Anlass sehen, da Geld zu investieren.
Ich denke halt, das man auch über den Tellerrand hinaussehen sollte. Auch wenn es aus der derzeitigen Raytracing-Perspektive nur bis zum Löffel reicht.

[Coda]

Wer schreit denn danach, dass wir kein Raytracing wollen?

Sein Ansatz, dass Rasterisierung komplett abgelöst werden soll ist einfach Schwachsinn. Gegen hybrides Rendering habe ich gar nichts, weil es an vielen Stellen Sinn ergeben kann.

Aber er tut gerade so als wäre es der heilige Gral des Renderings blafasel. Was einfach nicht stimmt. Es ist ja nicht so als wäre Raytracing was neues.

[del_4901]

Daniel Pohl, mein persöhnlicher Held! Wer zu dumm ist sich nen vernünftigen Light/Shadow/Materialmanager zu schreiben, der braucht halt eben Raytracing. Sorry aber darauf läuft es hinaus. Ich mein wenn man vom ersten Mal davon hört und was Anderes nicht kennt klingt das auch sehr verlockend.

[Gast]

Im Artikel steht:

Die vorangegangenen Betrachtungen führen also zu der Schlussfolgerung, dass der Ansatz Hybridrendering zur Darstellung der 3D-Welt nicht unbedingt die beste Idee ist. Seine einzig' brauchbare Anwendung ist meiner Meinung nach eine zusätzliche Schicht wie ein HUD (Heads Up Display), eine Konsole oder vielleicht sogar die 3D-Perspektive eines Cockpits, jedoch nicht das Rendern der effektiven 3D-Szene.


Was spricht dagegen eine zusätztliche Schicht wie z.B. ein HUD auch bei einem Raytracer einzubauen?
Im Grund doch gar nichts.
Zuerst rendert man das Bild mit dem Raytracer und legt anschließend das 2d HUD über das fertig gerenderte Bild.
Warum sollte das ein Problem darstellen oder gar ein Vorteil für einen Rasterizer sein?

[Gast]

Also Leute ihr müßt doch zugeben daß Raytracing in offenen Welten mit vielen Polygonen deutlich mehr Sinn macht als reine Rasterizer.

Das mit dem Logarthimus steht ja alles im Artikel.


Wenn man eine ganze Stadt von einem Hubschrauber aus rendern will, und der Detailgrad der Stadt sehr hoch sein soll, dann gewinnt ein Raytracer doch um längen bei der hohen Polygondichte.

[Coda]

Also Leute ihr müßt doch zugeben daß Raytracing in offenen Welten mit vielen Polygonen deutlich mehr Sinn macht als reine Rasterizer.
Nein

Das mit dem Logarthimus steht ja alles im Artikel.
Was nichts nützt, weil man eh LOD braucht.

Wenn man eine ganze Stadt von einem Hubschrauber aus rendern will, und der Detailgrad der Stadt sehr hoch sein soll, dann gewinnt ein Raytracer doch um längen bei der hohen Polygondichte.
Und flimmert dabei wie blöd.

[grandmasterw]

Mit einem Monte Carlo Path Tracer würds wohl nicht so flimmern. Allerdings reicht da wohl die Leistung noch lange nicht. Dafür ist der wohl einfacher zu parallelisieren.

[Gast]

Gut, Raytracing hat sicher seine Nachteile, aber Rasterizer existieren bereits so lange und wurden bereits so sehr weiterentwickelt, dass sie logischerweise effizienter arbeiten als RT. Was hier zum Ausdruck kommt, ist doch die Angst vor der Umstellung. Spiele sollen gut aussehen, weil sie sich dann besser verkaufen. Kurzeitig gedacht sicherlich ein vertretbares ökonomisches Argument. Aber dabei tut man doch so, als würde Raytracing programmier-technisch in der jetzigen Form auch noch in 20 Jahren umgesetzt werden. Als gäbe es da keine Weiterentwicklung.
Vielleicht habe ich da mit meinem Mangel an Programmierkenntnissen nicht den rechten Zugang, aber meine Naturwissenschafts-Logik sagt mir, dass Raytracing deutlich näher an der "Wahrheit" (zumindest die Wahrheit, die in unseren wissenschaftlichen Modellen vertreten wird) liegt, als ein Rasterizer und dass das Potential langfristig wesentlich größer ist als bei Rasterizer-Engines.

Und das Argument mit dem harten sterilem Look kann ich auch nicht ganz nachvollziehen. Das hat doch primär mal nichts mit der RT-Engine an sich zu tun, sondern mit dem Content, der in den Demos und Benchmarks verwendet wird.

[Gast]

Ach und ich persönlich würde zunächst auch einen Zwischenweg bevorzugen. Aber wenn der einmal betreten wurde, dann wird sich am Ende, so meine Überzeugung, doch das RT durchsetzten, wenn auch erst in 50 Jahren.

[Gast]

Vielleicht habe ich da mit meinem Mangel an Programmierkenntnissen nicht den rechten Zugang, aber meine Naturwissenschafts-Logik sagt mir, dass Raytracing deutlich näher an der "Wahrheit" (zumindest die Wahrheit, die in unseren wissenschaftlichen Modellen vertreten wird) liegt, als ein Rasterizer und dass das Potential langfristig wesentlich größer ist als bei Rasterizer-Engines.
Welche Naturwissenschaftslogik ist das denn? Keine mathematische auf jeden Fall. Die Rasterisierung berechnet exakt die gleichen Ray-Intersections wie Raytracing auch. Nur erscheinen die Secondary-Rays auf den ersten Blick günstiger. Auf lange Sicht sind sie es teilweise sogar, aber davon sind wir noch weit weg.

Und das Argument mit dem harten sterilem Look kann ich auch nicht ganz nachvollziehen. Das hat doch primär mal nichts mit der RT-Engine an sich zu tun, sondern mit dem Content, der in den Demos und Benchmarks verwendet wird.
Naja rein statische Objekte vermitteln nunmal einen sterilen Look. Schonmal ne Crowdsimulation in nem Echtzeitraytracer gesehen? Oder wenigstens mehrere Objekte mit Skinning?

[Gast]

Ja secondary rays und weitere rays. Gut, reine Reflektionen sind jetzt nicht das Argument schlecht hin, aber für indirekte Beleuchtung hilft das schon. So funktioniert doch die Natur in unseren Modellen auch, zumindest in den Strahlenmodellen.
Man könnte ja für Sound-Simulationen Wellenfelder mit allen Nebenerscheinungen wie Beugung und Interferenz berechnen ;)

[Gast]

Das mit LOD ist allerdings aus meiner Sicht das beste Argument gegen RT, zumindest zurzeit. Schade, dass sowas in dem Artikel gar nicht zur Sprache kommt.

[Gast]

Vielleicht habe ich da mit meinem Mangel an Programmierkenntnissen nicht den rechten Zugang, aber meine Naturwissenschafts-Logik sagt mir, dass Raytracing deutlich näher an der "Wahrheit" (zumindest die Wahrheit, die in unseren wissenschaftlichen Modellen vertreten wird) liegt, als ein Rasterizer und dass das Potential langfristig wesentlich größer ist als bei Rasterizer-Engines.

was näher an der wahrheit ist, ist egal, es muss gut aussehen.

physik nach einstein ist auch näher an der wahrheit als physik nach newton, trotzdem ist es sinnfrei für spiele irgendwelche relativistische effekte in der physikengine zu berechnen.

spielegrafik muss erstmal schnell und schön sein. wenn nun ein spiel mit raytracing schöner aussehen würde, dafür aber 10x langsamer läuft könnte man umgekehrt mit der gleichen rechenleistung mit rasterizing das ganze 10x höher auflösen und schon sieht wieder rasterizing besser aus.

[FlashBFE]

Das mit LOD ist allerdings aus meiner Sicht das beste Argument gegen RT, zumindest zurzeit. Schade, dass sowas in dem Artikel gar nicht zur Sprache kommt.

In dem Artikel ist sowieso recht wenig Sinnvolles zur Sprache gekommen. 100% Spiegelungen und Kameraportale, an was sich im Endeffekt am meisten aufgehangen wurde, sind vielleicht nette Gimmicks in Spielen, aber keine Grundvorausetzung für gute und auch glaubwürdige Grafik.

[Nakai]

Der Artikel ist eh nur Werbung für Intel.
Die ganzen DAUs und Möchtegern-Profis lesen den Artikel und denken sie wüssten alles, was man zu RT wissen muss.
Hauptsache CB bekommt ein haufen Clicks...jawohl...:frown:


mfg Nakai

[Gast]

ein Interview zwischen John Carmack (id Software ;) und PC Perspective (englisch)
http://www.pcper.com/article.php?aid=532

[Gast]

Re: was John carmack dazu meint ;)
Der meint wohl auch dazu, dass das Interview nun zum vierten mal hier im Thema verlinkt wurde, 2 eigene Themen dazu existieren und auch sonst bestimmt noch 10 mal hier im Forum gepostet wurde...

[Gast]

Und was Carmack sagt, ist Computerspielgesetz ?)

[Gast]

ja denn er ist der grafikgott

[ShadowXX]

Und was Carmack sagt, ist Computerspielgesetz ?)
Nein, das nicht, aber er a.) argumentiert wesentlich differenzierter und b.) verflucht er RT nicht sondern sagt auch das gewisse Teile davon durchaus adaptiert werden sollten.

[Gast]

I[;6356539']mehr:

There’s no one showing the demo of like, here this is what games are going to look like on the next generation when we have 10x more processing power - nothing compelling has actually been demonstrated and everyone is busy making these multi-billion dollar decisions about what things are going to be like 5 years from now in the gaming world. I have a direction in mind with this but until everybody can actually make movies of what this is going to be like at subscale speeds, it’s distressing to me that there is so much effort going on without anybody showing exactly what the prize is that all of this is going to give us.

http://www.pcper.com/article.php?aid=532&type=overview

Da ist was dran. Die paar Schnipsel bei Youtube (http://www.computerbase.de/artikel/hardware/grafikkarten/2008/bericht_raytracing_spielen_20/6/) sind doch wohl ein schlechter Witz. Das kann doch nicht so schwer sein, einen hochaufgelösten und x264-encodierten Trailer bei Filefront(o.ä.) hochzuladen.

[Coda]

Der Inhalt ist schon ein schlechter Witz.

[ScottManDeath]

Mit einem Monte Carlo Path Tracer würds wohl nicht so flimmern. Allerdings reicht da wohl die Leistung noch lange nicht. Dafür ist der wohl einfacher zu parallelisieren.

Nicht wirklich. Du musst ja immer noch dieselbe Geometrie mit Deinen Rays intersecten. Ausserdem musst Du, um Die Varianz, aka Noise zu halbieren viermal soviele Rays losschiessen. Da gibts auch Tricks, aber Monte Carlo macht das ganze Problem erstmal um 8 bis 10 Größenordnungen größer. Wenn dann noch Participating Media (Wolken, Käse,Wachs, ...) hinzukommen wird die Hässlichkeit gleich nochmal so groß. Da kann man mit einem Rasterizer deutlich mehr tricksen.

[Gast]

Ich sehe in Raytracing durchaus die Zukunft. Bei den heutigen Engines werden doch meist nur Texturen auf die Objekte "gepappt". Und wenn die Umgebung "dreckig" wirken soll, dann sind es eben dreckige Texturen, die vorher mit großen Aufwand von den Entwicklern in Texturdesigntools erstellt wurden.
Nachteil des heutigen Verfahrens ist eben der Platzbedarf im RAM und im Installationsverzeichnisses der Anwendung/Spiels. Und sollen mehrere Qualtiätsstufen existieren werden meist auch noch mehrer Texturen des selben Objektes vorgehalten in 128x128 bis 4096x4096. Bei Falschenhälsen wie Festplatten sind bei großen Landschaften dann eben die Warteorgien ein Effekt davon.
Im Raytracing kann man das ganze eben errechnen und wie schlank sowas dann sein kann, sieht man an den 64kb - Farbrauschdemos (mein Favorit FR-008), dass dann 1,6GB an Texturen extrahiert und generiert.

Zudem gehen viele davon aus, das die heutige Objektdichte ausreichend ist. Das sehe ich nicht so. Gerade im Bereich der RPGs ala Gothic/Oblivion wird doch nur getrickst um eine "gefüllte" Welt zu suggerieren.
Wie der Artikel schon sagte, werden die Vorteile von Raytracing bei steigender Anzahl Objekte immer besser.
Was viele noch gar nicht berücksichtigen ist die Pyhsik. Sollen Bäume im Wind sich biegen, Sträucher aufgrund von Kollionsabfragen sich zur Seite neigen, Charaktere den Weg versperren, dann müssen die gerendert werden.
Dann reicht es nämlich nicht einfach eine pseudo-Strauchtexture in die Landschaft zu pappen. Durchnässte Klamotten die allmählich trocknen wären mit Raytracing durchaus machbar. Das schöne am Ray ist dann noch, die Welt lässt sich
ohne Probleme aufblähen ohne das großartig viel neuer Code dazukommt.
Ich gebe zu, dass der CP-Artikel etwas sehr weit vorausgreift und teilweise noch gar nicht machbar ist bei heutiger Hardware. Was allerdings Dr. Kirk von Nvidia sagt, ist auch nur Halbwahrheit, denn auch da gehts um Marketing. Er wird sicher nicht zugeben, dass D3D den Aufwand fast schon nicht mehr rechtfertigt. Raytracing lässt sich super scallieren bis in die Unendlichkeit, die jetzigen GPUs mit ihren einzelnen
Sektionen dagegen wohl eher nicht siehe SLI. 2 Grakas haben mitnichten die doppelte Framezahl zur Folge. Quad-Sli rentiert sich fast gar nicht mehr. Dagegen sind 16 Cores für Raytracing eben die 15,7fache Leistung. Und 16 Cores finden defentiv im Jahr 2010 ihre Abnehmer.

[Aquaschaf]

Durchnässte Klamotten die allmählich trocknen wären mit Raytracing durchaus machbar.

Das hat doch überhaupt keinen Zusammenhang damit ob Raytracing oder Rasterization zum Einsatz kommt. Der ganze Rest den du beschreibst auch nicht. Und vor allem sind beide Verfahren in gleichem Maße parallelisierbar. Sieh dir einen beliebigen CGI-Film an, von Pixar beispielsweise. Das ist dem Prinzip nach auch Rasterization.

[Gast]

Das hat doch überhaupt keinen Zusammenhang damit ob Raytracing oder Rasterization zum Einsatz kommt. Der ganze Rest den du beschreibst auch nicht. Und vor allem sind beide Verfahren in gleichem Maße parallelisierbar. Sieh dir einen beliebigen CGI-Film an, von Pixar beispielsweise. Das ist dem Prinzip nach auch Rasterization.


Die Filme die mir jetzt spontan einfallen, sind alle Comichaft. FinalFantasy ist der einzige Film (zumindest kenne ich keine anderen), dessen Grafik einen gewissen Realismus aufweist. MonsterAG, Cars, Soldier, Antz, Nemo sind alle auf Zeichentrick getrimmt. Warum? Rasterizer-Limitierung?

Wegen der Skalierung: Warum ist es dann für die GPU-Hersteller so schwer eine Graka zu bauen mit 4 Gpus drauf, die dann 4mal so schnell wie eine ist.
Bei Raytracing reicht es sogar aus ein Cluster zu bauen mit G-Bit Netzwerkarte (also kein besonders schnelles Interface). Und solche Cluster haben heute schon teilweise 65000 Recheneinheiten.
Kenne kein GPU-Verbund in der Größenordnung mit der Skalierung die für Rasterizer funktionieren.

[Expandable]

Wenn du einer 8800GTX doppelt so viele Shadereinheiten gibst, und sonst nix limitiert, ist sie auch (fast) doppelt so schnell. Der Grund, warum SLI nicht 100%ig skaliert, liegt darin, dass die GPUs nicht gegenseitig auf ihren VRAM zugreifen können (würde diese Limitierung auch für CPUs gelten, hätte Raytracing übrigens genau die gleichen Skalierungsprobleme, bzw. mit anderen Worten: Falls es jemals Raytracingbeschleuniger gibt, die nicht gegenseitig auf ihren VRAM zugreifen können und du verwendest SLI, hast du wieder keine 100%ige Skalierung.).

Ich bin grad am überlegen, ob es nicht möglich wäre, nur die Sekundärstrahlen mit Raytracing zu berechnen? Also quasi man rendert den kompletten Frame in einen G-Buffer analog zum "normalen" Deferred Rendering. Dann verwendet man einen Raytracer, um festzulegen, welche Teile des Bildes im Schatten liegen und was wo und wie reflektiert wird. Evtl. könnte man das ja dank CUDA auch noch in Hardware machen teilweise. In einem letzten Pass werden die Informationen von Rasterizer und Raytracer dann zusammengeführt. Weiß jemand, ob sowas schon einmal versucht worden ist?

[Gast]

Die Filme die mir jetzt spontan einfallen, sind alle Comichaft. FinalFantasy ist der einzige Film (zumindest kenne ich keine anderen), dessen Grafik einen gewissen Realismus aufweist. MonsterAG, Cars, Soldier, Antz, Nemo sind alle auf Zeichentrick getrimmt. Warum? Rasterizer-Limitierung?
http://en.wikipedia.org/wiki/List_of_films_made_involving_PhotoRealistic_RenderMan
Jo deswegen sehn die aich alle so scheisse aus... BTW: FF-TSW ist mit auf der Liste


Wegen der Skalierung: Warum ist es dann für die GPU-Hersteller so schwer eine Graka zu bauen mit 4 Gpus drauf, die dann 4mal so schnell wie eine ist.
Bei Raytracing reicht es sogar aus ein Cluster zu bauen mit G-Bit Netzwerkarte (also kein besonders schnelles Interface). Und solche Cluster haben heute schon teilweise 65000 Recheneinheiten.
Kenne kein GPU-Verbund in der Größenordnung mit der Skalierung die für Rasterizer funktionieren.

Das ist ein Speicher und Bandbreitenproblem. Zumal das hauptsächlich in Verbindung mit Postprocessing auftritt. Weil man da Abhänigkeiten hat, die man schlecht vorhersehen kann. Und da RT genauso schlecht parallelisierbar.

[Aquaschaf]

MonsterAG, Cars, Soldier, Antz, Nemo sind alle auf Zeichentrick getrimmt. Warum? Rasterizer-Limitierung?

Weil Pixar "Comic-Filme" macht. Dann nimm eben Herr der Ringe oder irgendeinen anderen Film bei dem RenderMan benutzt wurde. Hast du den Rest des Threads gelesen? Praktisch alle Punkte die Daniel Pohl als Argumente für Raytracing aufzählt stimmen einfach nicht wenn man das Thema nicht nur oberflächlich betrachtet.

SLI als Argument für schlechtere Parallelisierbarkeit zu nehmen ist Blödsinn weil das damit einfach nichts zu tun hat.

[Gast]

Ich bin grad am überlegen, ob es nicht möglich wäre, nur die Sekundärstrahlen mit Raytracing zu berechnen? Also quasi man rendert den kompletten Frame in einen G-Buffer analog zum "normalen" Deferred Rendering. Dann verwendet man einen Raytracer, um festzulegen, welche Teile des Bildes im Schatten liegen und was wo und wie reflektiert wird. Evtl. könnte man das ja dank CUDA auch noch in Hardware machen teilweise. In einem letzten Pass werden die Informationen von Rasterizer und Raytracer dann zusammengeführt. Weiß jemand, ob sowas schon einmal versucht worden ist?

Natürlich macht man das, POM ist nichts anderes als RT in einem Volumen.
Und das ist bereits ein hybrider Ansatz. Bei Schatten würde ich das nicht machen. SoftShadows sind unverhältnissmäßig teuer mit RT, zumal ShadowMaps sehr GPU freundlich sind. Diese ganze RT Geschichte ist nicht ganz so toll für die HW. Aber gezielt eingesetzt, ist es ganz brauchbar.

[Gast]

Ich sehe in Raytracing durchaus die Zukunft. Bei den heutigen Engines werden doch meist nur Texturen auf die Objekte "gepappt". Und wenn die Umgebung "dreckig" wirken soll, dann sind es eben dreckige Texturen, die vorher mit großen Aufwand von den Entwicklern in Texturdesigntools erstellt wurden.
Nachteil des heutigen Verfahrens ist eben der Platzbedarf im RAM und im Installationsverzeichnisses der Anwendung/Spiels. Und sollen mehrere Qualtiätsstufen existieren werden meist auch noch mehrer Texturen des selben Objektes vorgehalten in 128x128 bis 4096x4096. Bei Falschenhälsen wie Festplatten sind bei großen Landschaften dann eben die Warteorgien ein Effekt davon.
Im Raytracing kann man das ganze eben errechnen und wie schlank sowas dann sein kann, sieht man an den 64kb - Farbrauschdemos (mein Favorit FR-008), dass dann 1,6GB an Texturen extrahiert und generiert.


das hat nichts mit der rendertechnik zu tun, auch bei raytracing brauchst du texturen und du kannst auch beim rasterizer wenn es sinnvoll ist prozedurale texturen einsetzen.



Was viele noch gar nicht berücksichtigen ist die Pyhsik. Sollen Bäume im Wind sich biegen, Sträucher aufgrund von Kollionsabfragen sich zur Seite neigen, Charaktere den Weg versperren, dann müssen die gerendert werden.
Dann reicht es nämlich nicht einfach eine pseudo-Strauchtexture in die Landschaft zu pappen. Durchnässte Klamotten die allmählich trocknen wären mit Raytracing durchaus machbar. Das schöne am Ray ist dann noch, die Welt lässt sich
ohne Probleme aufblähen ohne das großartig viel neuer Code dazukommt.
Ich gebe zu, dass der CP-Artikel etwas sehr weit vorausgreift und teilweise noch gar nicht machbar ist bei heutiger Hardware. Was allerdings Dr. Kirk von Nvidia sagt, ist auch nur Halbwahrheit, denn auch da gehts um Marketing. Er wird sicher nicht zugeben, dass D3D den Aufwand fast schon nicht mehr rechtfertigt. Raytracing lässt sich super scallieren bis in die Unendlichkeit, die jetzigen GPUs mit ihren einzelnen
Sektionen dagegen wohl eher nicht siehe SLI. 2 Grakas haben mitnichten die doppelte Framezahl zur Folge. Quad-Sli rentiert sich fast gar nicht mehr. Dagegen sind 16 Cores für Raytracing eben die 15,7fache Leistung. Und 16 Cores finden defentiv im Jahr 2010 ihre Abnehmer.

auch das ist mit rasterizing und raytracing gleichermaßen zu erreichen, auch die skalierung ist gleich gut möglich

[Gast]

Weil Pixar "Comic-Filme" macht. Dann nimm eben Herr der Ringe oder irgendeinen anderen Film bei dem RenderMan benutzt wurde. Hast du den Rest des Threads gelesen? Praktisch alle Punkte die Daniel Pohl als Argumente für Raytracing aufzählt stimmen einfach nicht wenn man das Thema nicht nur oberflächlich betrachtet.

SLI als Argument für schlechtere Parallelisierbarkeit zu nehmen ist Blödsinn weil das damit einfach nichts zu tun hat.


Ich bringe SLI/Crossfire aus dem Grund weil mir durchaus bewußt ist, das Shadereinheiten auch schon eine Parallelisierung darstellt und schon mehrere in einer GPU stecken. Doch irgendwann ist Ende im Gelände. Denke nicht das wir so schnell einen 10Mrd Transistor GPU sehen werden. Also müssen mehrere GPUs zusammenabreiten und da kränkelt der SLI/Crossfire-Ansatz.

[Gast]

Ich bringe SLI/Crossfire aus dem Grund weil mir durchaus bewußt ist, das Shadereinheiten auch schon eine Parallelisierung darstellt und schon mehrere in einer GPU stecken. Doch irgendwann ist Ende im Gelände. Denke nicht das wir so schnell einen 10Mrd Transistor GPU sehen werden. Also müssen mehrere GPUs zusammenabreiten und da kränkelt der SLI/Crossfire-Ansatz.
Solange du auf maximal solche Bilder stehst hast du natürlich recht:
http://de.wikipedia.org/wiki/Bild:Box_-_DirectRecursive.png

Alles darüber hinaus egal ob getraced, gerastert oder gelined, hat diese Probleme und skaliert nichtmehr so gut.

(Siehe Voodoo2, damals sah die Grafik noch genauso scheisse aus, wie das Bild da oben)

[Coda]

Die Filme die mir jetzt spontan einfallen, sind alle Comichaft. FinalFantasy ist der einzige Film (zumindest kenne ich keine anderen), dessen Grafik einen gewissen Realismus aufweist. MonsterAG, Cars, Soldier, Antz, Nemo sind alle auf Zeichentrick getrimmt. Warum? Rasterizer-Limitierung?
Star Wars, Matrix, Transformers, usw. sind auch Reyes/Renderman also Rasterisierung.

Ich bringe SLI/Crossfire aus dem Grund weil mir durchaus bewußt ist, das Shadereinheiten auch schon eine Parallelisierung darstellt und schon mehrere in einer GPU stecken. Doch irgendwann ist Ende im Gelände. Denke nicht das wir so schnell einen 10Mrd Transistor GPU sehen werden. Also müssen mehrere GPUs zusammenabreiten und da kränkelt der SLI/Crossfire-Ansatz.
Und aus genau welchem Grund sollte Raytracing das Problem nicht haben? Raytracing braucht für die gleiche Leistung mehr Resourcen.

[Gast]

Zum vergleich:
http://de.wikipedia.org/wiki/Bild:Box_-_Distributed.png

Das hier ist locker mit einem Rasterizer (jetzt schon) möglich, in Echtzeit.


Hier wirds dann eklig:
http://de.wikipedia.org/wiki/Bild:Box_-_Path_Tracing_High.png
Aber da gibt es auch schon Ansätze für Rastergrafik in Echtzeit.

[Gast]

Matrix, Transformers, usw. sind auch Reyes/Renderman also Rasterisierung.
.

nö.. es wurde auch etwas anderes benutzt

[Matt]

Um mal das PRRenderman-Argument etwas zu entschärfen:
Es gibt auch einen anderen häufig verwendeten Renderer: Mental Ray. Er rendert in etwa gleich schnell wie Renderman und verwendet dabei Raytracing. Mithilfe von photonen Mapping berechnet er globale Beleuchtung und Kaustiken physikalisch genau, schon lange bevor dies in Renderman realisierbar war.
Bei meinen Maya 8-Experimenten war Dynamische Geometrie (Explosion der Erde, Kugelbahnen) auch keine große Geschwindigkeitsbremse. Ich kann mir deshalb durchaus vorstellen, das so was in Echzeit-Engines Einzug hält. Die Versuche von Intel sind dabei aber noch meilenweit entfernt.

Weiters:
Mental Ray wurde ebenfalls für verschiedenste Filme wie The Matrix Reloaded & Revolutions oder Star Wars Episode II verwendet.
Mental Ray erhielt ebenfalls einen Academy Award (2003)
Mental Images wurde im Dezember 2007 von Nvidia übernommen.

Mfg Matthias

[ScottManDeath]

Offline renderer behandlen in der Regel frames unabhaengig, d.h. Beschleunigungsdatenstrukturen werden pro Frame komplett neu erstellt, sowohl statische, als auch dynamische Teile. Deswegen merkt man da kaum einen Unterschied.

[Gast]

Der MentalRay wurde nur für ausgewählte Szenen in den entsprechenden Filmen verwendet. (Warum wohl?) Weil er um ein vielfaches langsamer ist als der RenderMan bei subjektiv gleicher Quallität!
Dein Argument mit gleich schnell ist definitv eine Lüge!

[Coda]

nö.. es wurde auch etwas anderes benutzt
Nein. ILM verwendet ausschließlich Renderman. Renderman kann auch Raytracing, was in Transformers auch eingesetzt wurde, aber der Grundalgorithmus ist Rasterisierung.

Er rendert in etwa gleich schnell wie Renderman
Mach mal in MentalRay motion blur an und vergleich dann die Geschwindigkeit und das Ergebnis. Renderman macht das Ding sowas von unglaublich platt das glaubst du nicht und es sieht auch noch deutlich besser aus.

Mithilfe von photonen Mapping berechnet er globale Beleuchtung und Kaustiken physikalisch genau, schon lange bevor dies in Renderman realisierbar war.
Photon Mapping ist auch nicht wirklich physikalisch korrekt, aber in der Nähe. Spielt aber auch keine Rolle. Das Ergebnis muss realistisch aussehen, wie das zustande kommt ist völlig gleich.

Mental Ray wurde ebenfalls für verschiedenste Filme wie The Matrix Reloaded & Revolutions oder Star Wars Episode II verwendet.
Star Wars ist ILM. Da wurde Mental Ray allerhöchstens zusätzlich verwendet, weil Renderman noch kein Raytracing konnte.

Der MentalRay wurde nur für ausgewählte Szenen in den entsprechenden Filmen verwendet.
Nein. Es wurde Raytracing verwendet, aber kein MetalRay.

[Gast]

Dann versuche ich es anders:

Ist es möglich im Rasterizer soweit die Recheneinheiten herunterzubrechen, dass die Einzellast selbst auf einer schwachen GPU leicht zu bewältigen ist und kein dickes Interface untereinander vorhanden sein muss?

Bei Raytracing könnte ich mir vorstellen, dass man jeden einzelnen Ray auf einer separaten CPU berechnen lassen kann. Zum Zusammensetzen des Bildes scheint nicht viel Kommunikation untereinander nötig zu sein.

Noch etwas anders:
Warum werden Filme als Argument eingeworfen? Dort werden soviele Mischtechniken, Videoprocessing, Filter etc. benutzt und Kulissen weden z.B. in Herr der Ringe in Lebensgroß aufgebaut. Für Landschaftsaufnahmen hat Neuseeland hergehalten. Soll für Gothic4 dann auch Neuseeland herhalten?

[Gast]

Nein. ILM verwendet ausschließlich Renderman. Renderman kann auch Raytracing, was in Transformers auch eingesetzt wurde, aber der Grundalgorithmus ist Rasterisierung.

hmm interessant!?


ILM started using mental ray in 1995 and entered a software licensing and custom support and development agreement with mental images in 2002. mental ray has been used in particular to render objects that have required global illumination, reflection, refractions and subsurface scattering. In many cases ILM uses both PRMan and mental ray in the same shots for different elements. Also several prominent ILM members came from mental images' commercial division, including Stefen Fangmeier, John Berton and John Nelson, who all joined ILM to work on Terminator 2: Judgement Day.

Over the years ILM has also developed many proprietary renderers for specific tasks, such as rendering hair and particles. Some have been in use in recent times like pRender. SplutterFish’s Brazil is also used at ILM's Digital Matte Department.

http://www.mentalimages.com/4_1_motion_pictures/index.html

coda informier dich bitte erstmal... ( das ist ja schlimm was du machmal so ablässt)

[Aquaschaf]

Noch etwas anders: Warum werden Filme als Argument eingeworfen?

Weil Filme in Hinsicht auf Szenenkomplexität, Shading, Polygonzahlen und Anspruch auf Realismus ein weites Stück über Spielen stehen und dort gewaltige Mengen an Rechenleistung eingesetzt weren können im Vergleich zur Echtzeitgrafik. Das heißt die allermeisten Argumente die für reine Raytracing-Lösungen vorgebracht werden ziehen dort viel stärker. Nun ist es aber so dass dort eben auch Rasterization bzw. vor allem hybride Ansätze vorherrschen. Ausschließliches Raytracing als heiligen Gral für Echtzeitgrafik zu propagieren (und sogar zu behaupten hybride Ansätze seien Unsinn) wie es Daniel Pohl tut ist aus diesem Grund relativ absurd.

[Matt]

@86: Dein Argument mit gleich schnell ist definitv eine Lüge!
Nunja, dass möchte ich nicht ohne weiters so stehen lassen. Es wird viel diskutiert, welcher Renderer nun wirklich schneller sei. In vielen Szenen ist PRman richtigerweise schneller, vor allem da, wo physikalische Genauigkeit nicht erforderlich ist um gut auszusehen. In anderen Belangen, wo es auf globale Beleuchtung, Spiegelungen, Kaustiken usw. ankommt, ist Mental Ray schneller.

Viele Studios verwenden deshalb beide Render-Engines.

@Coda: Mental Ray wurde sehr wohl in den von mir genannten Filmen verwendet. Kann man im Link zwei Posts über mir nachlesen.
Das Renderman auch Raytracing kann stimmt natürlich. Allerdings weit nicht so effizient.

Gruß, Matt

[Coda]

coda informier dich bitte erstmal... ( das ist ja schlimm was du machmal so ablässt)
Meine normal zuverlässigen Quellen unterrichteten mich von was anderem. Kann schon sein dass ich da falsch lag - und jetzt?

Fakt bleibt, dass bei Transformers z.B. die Szenen die Raytracing verwendet haben unglaublich lange gerendert haben und das Reyes/Renderman bei Motion Blur z.B. weit überlegen ist.

[Roi Danton]

Fakt bleibt, dass bei Transformers z.B. die Szenen die Raytracing verwendet haben unglaublich lange gerendert haben und das Reyes/Renderman bei Motion Blur z.B. weit überlegen ist.Für sogenannte RapidMotion Szenen bietet MentalRay ebenfalls einen Rasterizer (der nach eigener Erfahrung recht schnell funktioniert und 'nen guten Kompromiss zum Scanline darstellt - jaaa, PRman ist dabei schneller, aber das ist nicht die Diskussion hier). Insofern ist die Feststellung MentalRay == ausschließlich Raytracing nicht korrekt.

[Gast]

Da geht mir doch durch den Kopf, ob die alteingesessenen D3D Programmierer Angst um ihr (anerkannt) sehr grosses Know How haben, weil es eines Tages vielleicht keiner mehr braucht und vielleicht auf den Raytracing Zug aufspringen müssen.
Daniel Pohl, mein persöhnlicher Held! Wer zu dumm ist sich nen vernünftigen Light/Shadow/Materialmanager zu schreiben, der braucht halt eben Raytracing.

Hehe lol das musste einfach mal zitiert werden so schön wie der obere post den unteren vorausschauend beschreibt :D

[aths]

Weil Filme in Hinsicht auf Szenenkomplexität, Shading, Polygonzahlen und Anspruch auf Realismus ein weites Stück über Spielen stehen und dort gewaltige Mengen an Rechenleistung eingesetzt weren können im Vergleich zur Echtzeitgrafik. Das heißt die allermeisten Argumente die für reine Raytracing-Lösungen vorgebracht werden ziehen dort viel stärker. Nun ist es aber so dass dort eben auch Rasterization bzw. vor allem hybride Ansätze vorherrschen. Ausschließliches Raytracing als heiligen Gral für Echtzeitgrafik zu propagieren (und sogar zu behaupten hybride Ansätze seien Unsinn) wie es Daniel Pohl tut ist aus diesem Grund relativ absurd.Beim Raytracing kommt man schnell in Teufels Küche, wenn man es korrekt berechnen möchte, weil man Unmengen Strahlen und eine hohe Iterationstiefe braucht. Aber es ist immerhin möglich. Rechenleistung ist nur eine Frage der Zeit. Wenn man die Rechenleistung fürs Raytracing hat, wird man es wahrscheinlich tun – zumal andere Sachen wie Kollisionabfragen und damit auch Physik-Berechnungen sich viel besser integrieren lassen.

[Aquaschaf]

Rechenleistung ist nur eine Frage der Zeit.

Wenn nicht irgendein Wunder geschieht eben nicht, genug davon kann man nie haben. Wie ja schon mehrfach ausgeführt wurde bleibt man auch bei hybriden Lösungen in Bereichen wo um ganze Größenordnungen mehr Rechenleistung zur Verfügung steht als bei Echtzeitgrafik. Physik und Kollisionen lasse ich nicht wirklich als Argument gelten, dafür die selbe Geometrie (d.h. genauso fein aufgelöste) wie für die grafische Repräsentation zu verwenden macht wenig Sinn.

[Gast]

Sorry Jungs aber als Informatiker solltet ihr es besser wissen. Es ist schnups piep egal wie hoch die Rechenleistung ist. Rastierisierung bleibt trotzdem effizienter.

[Gast]

Rastierisierung bleibt trotzdem effizienter.

aber dafür mächtig limitiert....

[Coda]

Deshalb kann man ja auch dafür wo man es braucht zusätzlich Raytracing einsetzen.

[Spasstiger]

Kann man denn generell festhalten, dass Rasterisierung immer schneller ist, solange tricksen erlaubt, vielleicht sogar gewünscht ist?
Und dass Raytracing besser ist, wenn ein physikalisch korrektes Ergebniss wichtig ist (z.B. damit ein Autodesigner abschätzen kann, wie das lackierte Fahrzeug wirken wird)?

[Coda]

Physikalisch korrekt ist Raytracing auch nur wenn man jede Wellenlänge separat berechnet usw.

[aths]

Sorry Jungs aber als Informatiker solltet ihr es besser wissen. Es ist schnups piep egal wie hoch die Rechenleistung ist. Rastierisierung bleibt trotzdem effizienter.Für die meisten Spiele, ja. Man kann aber zu einem Punkt kommen wo es einfacher ist, mit massivem Recheneinsatz eine Szene halbwegs korrekt zu berechnen, anstatt den ganzen Fake-Content erstellen zu müssen.


Wenn nicht irgendein Wunder geschieht eben nicht, genug davon kann man nie haben. Wie ja schon mehrfach ausgeführt wurde bleibt man auch bei hybriden Lösungen in Bereichen wo um ganze Größenordnungen mehr Rechenleistung zur Verfügung steht als bei Echtzeitgrafik. Physik und Kollisionen lasse ich nicht wirklich als Argument gelten, dafür die selbe Geometrie (d.h. genauso fein aufgelöste) wie für die grafische Repräsentation zu verwenden macht wenig Sinn.Wieso, wir haben längst mehr als genug Rechenleistung fürs Multitexturing. Mehr Rechenleistung brauchts dafür nicht, was man jetzt braucht, sind gute Texturen. Was Kollisionsabfragen angeht, sollte diese schon genauso fein wie die Grafik sein. Ich hasse es, wenn ein halber Arm der Spielfigur in der Wand verschwindet.

[Aquaschaf]

Für die meisten Spiele, ja. Man kann aber zu einem Punkt kommen wo es einfacher ist, mit massivem Recheneinsatz eine Szene halbwegs korrekt zu berechnen, anstatt den ganzen Fake-Content erstellen zu müssen.


Wieso, wir haben längst mehr als genug Rechenleistung fürs Multitexturing. Mehr Rechenleistung brauchts dafür nicht, was man jetzt braucht, sind gute Texturen. Was Kollisionsabfragen angeht, sollte diese schon genauso fein wie die Grafik sein. Ich hasse es, wenn ein halber Arm der Spielfigur in der Wand verschwindet.

Wiederholung: dieser Punkt ist noch nicht einmal bei Offline-Rendering auch nur annähernd erreicht. Warum sollte es bei Echtzeitgrafik anders sein?

Was haben gute Texturen damit zu tun?

Es geht ja nicht um halbe Arme die in einer Wand stecken. Aber wenn man als Ziel annimmt die Geometrie so fein aufzulösen dass die Auflösung der begrenzende Faktor ist, dann tut es auch noch deutlich gröbere Kollisionsgeometrie ohne sichtbare Inkonsistenzen.

[aths]

Wiederholung: dieser Punkt ist noch nicht einmal bei Offline-Rendering auch nur annähernd erreicht. Warum sollte es bei Echtzeitgrafik anders sein?Als wir 286-er CPUs hatten hätte wahrscheinlich kaum jemand damit gerechnet, binnen absehbarer Zeit Echtzeit-3D-Rendering in VGA-Auflösung, Highcolor und mit gefilterten Texturen bezahlbar im Privatcomputer zu sehen. Aus damaliger Sicht wäre es absoluter WAHNSINN, etliche Megatexel bilinear zu filtern. Ich hätte auch zu den Leuten gehört die dir vorgerechnet hätten, dass wir das erst in langer, langer Zeit sehen würden, weil erforderliche Bandbreite und der Rechenaufwand VIEL zu groß wären.

Was haben gute Texturen damit zu tun?Gute Texturen erlauben unter anderem den Verzicht auf (extrem teure) prozedurale Texturen.

Es geht ja nicht um halbe Arme die in einer Wand stecken. Aber wenn man als Ziel annimmt die Geometrie so fein aufzulösen dass die Auflösung der begrenzende Faktor ist, dann tut es auch noch deutlich gröbere Kollisionsgeometrie ohne sichtbare Inkonsistenzen.Wenn man schon Raytracing macht, ist es beinahe wurscht, zumindest für statische Geometrie.

[Aquaschaf]

Als wir 286-er CPUs hatten hätte wahrscheinlich kaum jemand damit gerechnet, binnen absehbarer Zeit Echtzeit-3D-Rendering in VGA-Auflösung, Highcolor und mit gefilterten Texturen bezahlbar im Privatcomputer zu sehen. Aus damaliger Sicht wäre es absoluter WAHNSINN, etliche Megatexel bilinear zu filtern. Ich hätte auch zu den Leuten gehört die dir vorgerechnet hätten, dass wir das erst in langer, langer Zeit sehen würden, weil erforderliche Bandbreite und der Rechenaufwand VIEL zu groß wären.

Und was soll daran analog zur jetzigen Situation sein? Hardware die Raytracing beherrscht beherrscht auch Rasterization, bloß letzteres schneller.

[betasilie]

Physikalisch korrekt ist Raytracing auch nur wenn man jede Wellenlänge separat berechnet usw.
Es gibt unendlich viele Wellenlängen. Wie willst Du das machen?

[ScottManDeath]

Indem man den Bereich (400 nm bis 700 nm) und die Unterteilung des Spektrums dem menschlichen visuellem System anpasst.

[Gast]

Als wir 286-er CPUs hatten hätte wahrscheinlich kaum jemand damit gerechnet, binnen absehbarer Zeit Echtzeit-3D-Rendering in VGA-Auflösung, Highcolor und mit gefilterten Texturen bezahlbar im Privatcomputer zu sehen. Aus damaliger Sicht wäre es absoluter WAHNSINN, etliche Megatexel bilinear zu filtern. Ich hätte auch zu den Leuten gehört die dir vorgerechnet hätten, dass wir das erst in langer, langer Zeit sehen würden, weil erforderliche Bandbreite und der Rechenaufwand VIEL zu groß wären.


trotzdem wird raytracing immer langsamer sein, und die gesparte leistung kann man dann in bessere effekte beim rasterizing investieren, so dass im endeffekt bei gleicher perfomrance letzteres wieder besser aussieht.


Gute Texturen erlauben unter anderem den Verzicht auf (extrem teure) prozedurale Texturen.


was hat das jetzt mit der rendertechnik zu tun? sowohl für raytracing als auch für rasterizing braucht man gute texturen.

[aths]

Und was soll daran analog zur jetzigen Situation sein? Hardware die Raytracing beherrscht beherrscht auch Rasterization, bloß letzteres schneller.Das gilt nur bei überschaubarem Geometrie-Level und beim Verzicht auf "Raytracing-Effekte", welche mit Rasterung so gleich gar nicht geboten werden können.

Herr Pohl stellt in einem Artikel die Sache so dar als sei Raytracing insgesamt viel besser, aber er beleuchtet eigentlich nur die Vor-, nicht die Nachteile. Da sich statische Geometrie für Raytracing schön optimieren lässt, ist es zwar mit Raytracing eher denkbar, eine Oberfläche mit geometrischem Detail zu versehen als Bump- oder Parallaxmapping zu nutzen. Wie er bei Verkleinerung das Geometrieflimmern in den Griff bekommen will, sagt er leider nicht.

Was Spiegel-Effekte angeht, oder richtigen Nebel, lässt sich das mit Raytracing viel hochwertiger berechnen.

trotzdem wird raytracing immer langsamer sein, und die gesparte leistung kann man dann in bessere effekte beim rasterizing investieren, so dass im endeffekt bei gleicher perfomrance letzteres wieder besser aussieht.Das stimmt so lange man keine (annähernd) korrekte Berechnung braucht. Soll es nur gut aussehen, was für die Spiele-Praxis eigentlich völlig ausreichend ist, ist das Rasterverfahren überlegen.

was hat das jetzt mit der rendertechnik zu tun? sowohl für raytracing als auch für rasterizing braucht man gute texturen.Es bleibt ein Fake. Texturen haben immer das Problem begrenzter Auflösung; Dinge wie MIP-Mapping sind nicht zufriedenstellend wenn es um maximale Qualität geht. Für heutige Spiele ists natürlich voll ausreichend.

Tendenziell steigt die Rechenleistung schneller als die Bandbreite. Es wäre denkbar dass wir mal zu einem Punkt gelangen, wo ein prozeduraler Holz-Shader billiger ist, als Texturen samplen zu müssen.

[Coda]

Das gilt nur bei überschaubarem Geometrie-Level und beim Verzicht auf "Raytracing-Effekte", welche mit Rasterung so gleich gar nicht geboten werden können.
Das "überschaubare Geometrie-Level" sollte man auch beibehalten. Mehr als 2/3 Polygone pro Pixel wird einfach definitiv flimmern. Da sind wir schon bald.

Es gibt unendlich viele Wellenlängen. Wie willst Du das machen?
Das ist der Punkt an der Sache ;)

Es bleibt ein Fake. Texturen haben immer das Problem begrenzter Auflösung; Dinge wie MIP-Mapping sind nicht zufriedenstellend wenn es um maximale Qualität geht. Für heutige Spiele ists natürlich voll ausreichend.
Jetzt geht das wieder los. Um was wollen wir wetten, dass wir in 10 Jahren immer noch Texturen haben?

Mip-Mapping ist genial, weil es automatischer LOD ist wovon alle bei Geometrie träumen würden. Das musst du bei prozeduralem Zeug im Shader auch wieder von Hand machen. Das ist mit ein Grund warum das Zeug einfach völlig unbrauchbar ist. Ganz abgesehen davon dass es kein Artist erstellen kann weil man dafür programmieren muss und es deshalb schon überhaupt niemand machen wird

[Roi Danton]

Ich hab zu wenig Ahnung, um zur Diskussion beizutragen, aber hier ein kleiner Denkanstoß: Bei Infinity werden für die (Echtzeit)Planeten- und Terraindarstellung prozedurale (Heightmaps &) Texturen verwendet (ausgenommen Objekte wie die Bäume in Bsp1 oder Häuser/Raumschiffe). Der Gründe sind wohl die Einsparung von Zeitaufwand & Speicherplatz (http://www.infinity-universe.com/Infinity/infinity_faq.php#a3.1). Relativ aktuelle Terrainscreenshots gibts hier (http://www.infinity-universe.com/InfinityForums/viewtopic.php?t=7385&highlight=procedural).

Beispielvideo (http://video.google.com/videoplay?docid=-3744650885934024232) - Reise von der Planetenoberfläche bis in mehrere Millionen Kilometer Entfernung.

Beispiel #1:
http://www.infinity-universe.com/Infinity/Media/Misc/terrain_30_med.jpg (http://www.infinity-universe.com/Infinity/Media/Misc/terrain_30.jpg)
Beispiel #2:
http://www.infinity-universe.com/Infinity/Media/Screenshots/planet_full_33_thumb.jpg (http://www.infinity-universe.com/Infinity/Media/Screenshots/planet_full_33.jpg)

Mip-Mapping ist genial, weil es automatischer LOD ist wovon alle bei Geometrie träumen würden. Das musst du bei prozeduralem Zeug im Shader auch wieder von Hand machen. Das ist mit ein Grund warum das Zeug einfach völlig unbrauchbar ist. Ganz abgesehen davon dass es kein Artist erstellen kann weil man dafür programmieren muss und es deshalb schon überhaupt niemand machen wirdWenn es unbrauchbar wäre, würde es in diesem Beispiel wohl nicht verwendet werden? =)

[Gast]

Beispiel #1:
http://www.infinity-universe.com/Infinity/Media/Misc/terrain_30_med.jpg (http://www.infinity-universe.com/Infinity/Media/Misc/terrain_30.jpg)
Beispiel #2:
http://www.infinity-universe.com/Infinity/Media/Screenshots/planet_full_33_thumb.jpg (http://www.infinity-universe.com/Infinity/Media/Screenshots/planet_full_33.jpg)


sieht aber nicht besonders toll aus, die bäume sind grauenhaft und auch die schnee- und steindarstellung wirkt extrem künstlich.

[Gast]

Ich hab zu wenig Ahnung, um zur Diskussion beizutragen, aber hier ein kleiner Denkanstoß: Bei Infinity werden für die (Echtzeit)Planeten- und Terraindarstellung prozedurale (Heightmaps &) Texturen verwendet (ausgenommen Objekte wie die Bäume in Bsp1 oder Häuser/Raumschiffe).
Mööp - Fehler.

Infinity berechnet die ganzen Planeten on-the-fly. Aber die Basistexturen sind nicht prozedural. Aus diesen werden anhand verschiedener Parameter (Höhe,Neigung, Vegetation,...) per Blending neue Texturen erstellt. Von richtigen prozeduralen Texturen oder Textursynthese ist das noch ein gutes Stück weg. Der einziger Unterschied zu anderen Blendingverfahren ist das Cachen des Ergebnisses als Textur.
sieht aber nicht besonders toll aus, die bäume sind grauenhaft und auch die schnee- und steindarstellung wirkt extrem künstlich.
Dafür dass man Planeten mit ein paar Parametern erzeugen kann, abertausende Planeten existieren und das eigentlich ein Ein-Mann-Projekt ist, sieht das extrem geil aus.

[Coda]

Wenn es unbrauchbar wäre, würde es in diesem Beispiel wohl nicht verwendet werden? =)
Siehe Gast. Rein prozedurales Zeug sieht einfach komplett künstlich aus. Für so spezielle Fälle wird man auf Shader zurückgreifen die trotzdem Artist-Input aus Texturen bekommen.

[Roi Danton]

sieht aber nicht besonders toll aus, die bäume sind grauenhaft und auch die schnee- und steindarstellung wirkt extrem künstlich.Die Bäume sind WIP, zur Bodendarstellung schau Dir mal FSX, Lock On & Co an. Soviel besser sieht es dort auch nicht aus.
Mööp - Fehler.

Infinity berechnet die ganzen Planeten on-the-fly. Aber die Basistexturen sind nicht prozedural. Aus diesen werden anhand verschiedener Parameter (Höhe,Neigung, Vegetation,...) per Blending neue Texturen erstellt. Von richtigen prozeduralen Texturen oder Textursynthese ist das noch ein gutes Stück weg. Der einziger Unterschied zu anderen Blendingverfahren ist das Cachen des Ergebnisses als Textur.Ah okay, schade. Da ist das also doch nicht als Beispiel geeignet (Ad-Astra (http://a-astra.com/index.htm) wäre wohl besser geeignet gewesen, aber da ist das Ergebnis entsprechend schlechter). Na ja, danke für die Aufklärung. :up:

[aths]

Das "überschaubare Geometrie-Level" sollte man auch beibehalten. Mehr als 2/3 Polygone pro Pixel wird einfach definitiv flimmern. Da sind wir schon bald.Jedenfalls bei Verkleinerung, ja. Und Geometrie-LOD hat bisher die hässliche Eigenschaft, dass der Detailgrad sprunghaft gewechselt wird. Da hilft nur die Echtzeit-Tesselation komplexerer Objekte.

Jetzt geht das wieder los. Um was wollen wir wetten, dass wir in 10 Jahren immer noch Texturen haben?Texturen werden wir wohl immer haben, weil sich viele Sachen so einfach damit lösen lassen.

Mip-Mapping ist genial, weil es automatischer LOD ist wovon alle bei Geometrie träumen würden. Das musst du bei prozeduralem Zeug im Shader auch wieder von Hand machen. Das ist mit ein Grund warum das Zeug einfach völlig unbrauchbar ist. Ganz abgesehen davon dass es kein Artist erstellen kann weil man dafür programmieren muss und es deshalb schon überhaupt niemand machen wirdDer Verkleinerungsfilter beim MIP-Mapping bringt immer irgendwelche Probleme.

[Gast]

Jedenfalls bei Verkleinerung, ja. Und Geometrie-LOD hat bisher die hässliche Eigenschaft, dass der Detailgrad sprunghaft gewechselt wird.
Sind wir in der Steinzeit? Schonmal was von Progressive Meshes gehört?

[Coda]

Der Verkleinerungsfilter beim MIP-Mapping bringt immer irgendwelche Probleme.
Die sind in der Praxis aber vernachlässigbar wenn man die Mips mit nem ordentlichen Downfilter erzeugt und nicht bloß idiotisch Box nimmt.

[AnarchX]

Inside Intel's ray tracing research (http://www.tgdaily.com/index2.php?option=com_content&task=view&id=36606&pop=1&page=0&Itemid=118)
Filed in Business and Law
By Theo Valich
Tuesday, March 25, 2008 01:00

Interview - Intel will soon be extending its product portfolio into visual computing. And while Nvidia isn’t publicly admitting that Intel is an increasing threat to the company, we know that Intel isn’t aiming for second place. While Larrabee is one of the firm’s key hardware products, Intel is busy developing lots of related technologies in the background as well - including ray-tracing engines. We had a chance to talk to Intel’s Daniel Pohl, a young German engineer who first got our attention when he rewrote the rasterization engines of Quake III Arena and Quake IV into full-blown ray tracing engines. Back then, Daniel used OpenRT API. Today, he is developing API currently known as IntelRT and gave TG Daily editor Theo Valich a fascinating look into his work.
[...]

[DR.ZEISSLER]

ich war damals bei der 3dfx revolution dabei...und bei der OpenRT revolution werde ich auch dabei sein.

doc

[Coda]

Bauer's Law...

[betasilie]

Bauer's Law...
Ich warte dann auf pi's refinement of Krahl's Law

[Gast]

Inside Intel's ray tracing research (http://www.tgdaily.com/index2.php?option=com_content&task=view&id=36606&pop=1&page=0&Itemid=118)
Nicht schlecht!

Besonders das hier:
I am a research scientist [...] We explore real-time ray tracing,[...] most importantly, how to improve the image quality. This, for example, includes Adaptive SuperSampling (AntiAliasing).

[Matt]

Wichtig wär noch Photon Mapping. Damit bekommt man genaue globale Beleuchtung, Kaustiken uvw., was sie mit der IntelRT-Engine auch schaffen wollen. Ich habe aber keine Ahnung, wie sie das in Echtzeit umsetzen wollen.

Gruß, Matt

[Gast]

ich kenn mich mit der materie zwar überhaupt net aus aber allein die "tatsache" das der rechenaufwand beim raytracing logarithmisch und beim rastracing linear ansteigt, führt doch automatisch zum schluß, das "irgendwann" das raytracing ganz klar im vorteil sein muß!? oder gibts da irgend einen denkfehler bzw ist der logarithmische anstieg beim raytracing eine "falschaussage"??

[san.salvador]

ich kenn mich mit der materie zwar überhaupt net aus aber allein die "tatsache" das der rechenaufwand beim raytracing logarithmisch und beim rastracing linear ansteigt, führt doch automatisch zum schluß, das "irgendwann" das raytracing ganz klar im vorteil sein muß!? oder gibts da irgend einen denkfehler bzw ist der logarithmische anstieg beim raytracing eine "falschaussage"??
Diese Regel gilt IIRC nur für die Anzahl der Polygone, aber das ist ja nur ein Teil der nötigen Berechnungen.

[Gast]

Diese Regel gilt IIRC nur für die Anzahl der Polygone, aber das ist ja nur ein Teil der nötigen Berechnungen.

ach so, also wäre es doch denkbar das zu eine hybride lösung kommen könnte, obwohl es von daniel pohl angezweifelt wird?!

wie sieht es denn bei sehr sehr koplexen licht/schattenberechnungen aus??
sagen wir mal in ein paar jaheren sind wir so weit das wir z.b. einen schotterweg aus tatsächlich etlichen tausenden von kiselsteinen darstellen können (physikalisch korekt natürlicH) und dieser durch einem wald führt wo nicht nur die schatten der bäume sondern noch diverse reflektionen von glatten oberflächen mit einfliesen und natürlich jeder einzelne kiselstein einen korekten schatten werfen soll (bzw sogar kleine spiegelungen durch "quarzeinschlüsse" in den kiselsteinen).
also so komplexe licht und schattenspiele, dir für uns heute noch absolutes scifi sind!

was wäre dann besser geeignet?
reines rastaricing?
reines raytracing?
oder eine hybridlösung?

[Gast]

oder gibts da irgend einen denkfehler bzw ist der logarithmische anstieg beim raytracing eine "falschaussage"??
Ja bzw Nein.
Raytracing hat logarithmische Laufzeit zur Anzahl der Polygone.
Rasterisierung hat dagegen lineare. Aber nur, wenn man kein LOD und kein Culling nutzt. Dann hat man dort auch logarithmische Laufzeit. Deswegen ist die Gesamtaussage für die heutige Praxis falsch. (Wer nun kommt, dass man mit Raytracing kein LOD braucht, wird an einen Stuhl gefesselt und muss sich 48 Stunden am Stück das Geflimmer anschauen.)

Ich hab schon öfters überlegt, ob man bei Raytracing mit LOD auf log(log(n)) kommt. Aber das ist glaub ich nicht der Fall.

[Gast]

was wäre dann besser geeignet?
reines rastaricing?
reines raytracing?
oder eine hybridlösung?


keines davon, am besten wäre die kieselsteine nicht zu modellieren sondern weiter texturen zu verwenden.

ausmodelliert wären die kieselsteine nämlich viel zu klein und würden bei heutigen auflösungen grauenhaft flimmern, abgesehen davon wird das rendering bei kleinen polygonen sehr ineffizient.

[DR.ZEISSLER]

das ganze hier steht und fällt doch mit dem release eines voll spielbaren angepassten ray-titels bei vorstellung des entsprechenden dafür ausgelegten intel-prozessors und dem direkten vergleich mit einem dann verfügbaren rasterizer.

so lange das nicht möglich ist, ist jedes weitere wort, was letztendlich besser ist, zuviel.

doc

[Demirug]

das ganze hier steht und fällt doch mit dem release eines voll spielbaren angepassten ray-titels bei vorstellung des entsprechenden dafür ausgelegten intel-prozessors und dem direkten vergleich mit einem dann verfügbaren rasterizer.

so lange das nicht möglich ist, ist jedes weitere wort, was letztendlich besser ist, zuviel.

doc

Und damit fällt es wohl.

Solange Intel dieses Spiel nicht vollständig finanziert wird sich niemand finden der sowas programmiert.

[Coda]

Wichtig wär noch Photon Mapping. Damit bekommt man genaue globale Beleuchtung, Kaustiken uvw., was sie mit der IntelRT-Engine auch schaffen wollen. Ich habe aber keine Ahnung, wie sie das in Echtzeit umsetzen wollen.
Naja. Tricksen oder Hardware draufwerfen. So wie immer halt.

Ich hab schon öfters überlegt, ob man bei Raytracing mit LOD auf log(log(n)) kommt. Aber das ist glaub ich nicht der Fall.
LOD ist mit Raytracing auch zusätzlich etwas schwieriger als mit Rasterizern. Ein weiterer wunder Punkt.

das ganze hier steht und fällt doch mit dem release eines voll spielbaren angepassten ray-titels bei vorstellung des entsprechenden dafür ausgelegten intel-prozessors und dem direkten vergleich mit einem dann verfügbaren rasterizer.

so lange das nicht möglich ist, ist jedes weitere wort, was letztendlich besser ist, zuviel.
Ich würde dir trotzdem zu etwas mehr Skepsis raten. Man muss zwischen dem Marketing-Hype lesen der hier betrieben wird.

[Gast Nr.1583755]

Raytracing sollte man sicher nicht aus den Augen verlieren. Aber ich wäre sehr erstaunt wenn es Rasterisierung verdrängt. Das wird sehr viel eher nebenherlaufen und man wird je nach Gebiet das Beste aus den beiden Welten einsetzen. Raytracing ist NICHT der heilige Gral des Realtime-Renderings. Es löst die Probleme die wir momentan haben auch nicht - was vor allem vollständige indirekte Echtzeit-Beleuchtung ist.


Ich dachte für dynamisches global illumination wäre Raytracing perfekt geeignet?
Vor allem wenn man den Begriff "Photorealismus" ernst nimmt! Z.B. die "echten" Photorenderer wie Maxwell, die bereits auf einem Level von physikalischer Lichtsimulation sind, nutzen Raytracing Verfahren.
Natürlich wird so etwas nicht auf der Playstation4 laufen, aber am Ende der Fahnenstange in X Jahren wird dann doch wieder das Raytracing stehen.

[Gast Nr.1583756]

IA64/VLIW/EPIC-CPUs. Wenn Intel es schafft, eine GPU auf die Beine zu stellen, die was taugt, hat das Projekt zukunft, ansonsten wirds halt wieder ein Milliardengrab... da kann der Multikern GP sein, wie er will. Und ganz sicher setzt in dem Segment eher CUDA + CTM den Standard und nicht Intel.


CUDA empfinde ich (zumindest im Moment) mehr als so eine Art Notlösung.
Man kann zwar damit jetzt C-Code ausführen, aber einigermaßen effizient nur mit schrecklichen Verrenkungen. Das ist eher so eine Art "proof of conecpt", damit wollte man nicht wirklich arbeiten, wenn man stattdessen eine ähnlich schnelle Standard x86-Umgebung hätte!

[Gast]

Ich dachte für dynamisches global illumination wäre Raytracing perfekt geeignet?
Vor allem wenn man den Begriff "Photorealismus" ernst nimmt! Z.B. die "echten" Photorenderer wie Maxwell, die bereits auf einem Level von physikalischer Lichtsimulation sind, nutzen Raytracing Verfahren.
Natürlich wird so etwas nicht auf der Playstation4 laufen, aber am Ende der Fahnenstange in X Jahren wird dann doch wieder das Raytracing stehen.
In X Jahren, wenn Rasterizer alleine nicht mehr ausreichen, wirst du entsprechend eine hybride Version sehen.

[FlashBFE]

CUDA empfinde ich (zumindest im Moment) mehr als so eine Art Notlösung.
Man kann zwar damit jetzt C-Code ausführen, aber einigermaßen effizient nur mit schrecklichen Verrenkungen. Das ist eher so eine Art "proof of conecpt", damit wollte man nicht wirklich arbeiten, wenn man stattdessen eine ähnlich schnelle Standard x86-Umgebung hätte!

Sowas sinnvoll zu nutzen ist eher eine Sache des Frameworks. Ohne Grundlage auf dem Chip mit C anzufangen, ist wirklich bucklig. Aber wenn es schon häufig benutzte Standardfunktionen mitbringt, die auf den Chip optimiert sind, hats der Programmierer (wie immer) viel leichter.

[Gast]

Sowas sinnvoll zu nutzen ist eher eine Sache des Frameworks. Ohne Grundlage auf dem Chip mit C anzufangen, ist wirklich bucklig. Aber wenn es schon häufig benutzte Standardfunktionen mitbringt, die auf den Chip optimiert sind, hats der Programmierer (wie immer) viel leichter.


Nicht wenn sich der Programmierer dazu erst einmal mit den Eigenheiten von Rasterizing-Grafikkarten beschäftigen muss, um dann zu versuchen z.B. der Karte die Nutzdaten als eine Art Textur zu verkaufen und möglichst sein Problem mit Vektoren und Matrizen zu bearbeiten, um die maximale Geschwindigkeit heraus zu holen.
Man kann nicht alles mit vorgefertigten Funktionen umschiffen und einfach in der gewohnten Umgebung mit den gewohnten Frameworks zu arbeiten ist sicher wesentlich angenehmer. Von daher ist Intel hier klar im Vorteil!

[kokett]

Und damit fällt es wohl.

Solange Intel dieses Spiel nicht vollständig finanziert wird sich niemand finden der sowas programmiert.

Was kostet denn die Entwicklung von einem guten PC Spiel? 30 Mio Dollar ca. ? Das blecht Intel doch aus der Portokasse, wenn sie müssen.

[dildo4u]

Intel converts ET: Quake Wars to ray-tracing

Intel demonstrated ET: Quake Wars running in basic HD (720p) resolution, which is, according to our knowledge, the first time the company was able to render the game using a standard video resolution, instead of 1024 x 1024 or 512 x 512 pixels. Seeing ETQW running in 14-29 frames per second in 1280x720 has brought up our hopes for Intel's CPU architecture, since we do not believe that CPUs would deliver a similar performance when rasterizing graphics. For the record, the demonstration ran on a 16-core (4 socket, 4 core) Tigerton system running at 2.93 GHz.

The game itself was vastly expanded when compared to original title. Intel’s Daniel Pohl showed how the engine now shoots three million rays in all directions, enabling collision detection based on rays alone.

Also, during the conversion, some effects were integrated by default, even if they had not been planned. One of those effects was fog shadow on the floor and physically-correct refractions of water. If you ever dived into a swimming pool or sea and looked up, you could have seen that the world is distorted. Now, ET: Quake Wars has the very same effect.

An impressive part of demonstration was looking at glass surfaces. Glass now reflects the environment to the tiniest detail - no LOD trickery here. Seeing a 200-window portal was quite an impressive demonstration of a situation when you are shooting rays into the environment. Check out our gallery to get more detail on this demo.

The icing on the cake was that the game was actually demonstrated running on a 64-bit Linux operating system. Intel stated that with ray-tracing, the company now supports 32-bit and 64-bit versions of Linux and Windows operating systems. We'll see what will happen with Mac OS X support, but that should be on the cards as well.

http://www.tgdaily.com/html_tmp/content-view-37925-113.html

[AnarchX]

Und immernoch werden die gleichen lächerlichen Argumente für Raytracing angeführt (die in der Landschaft verteilten, schwebenden Chrome-Kugeln sind gut auf den Bildern zu erkennen;)), von der benötigten Leistung mal ganz zu schweigen.

Wie man Raytracing beeindruckend darstellt hat ATi vor kurzem gezeigt:
http://picasaweb.google.co.uk/Fudzilla.com/ATI4800SeriesTechDemo/photo#5208079896638449394
;)

[DR.ZEISSLER]

Und immernoch werden die gleichen lächerlichen Argumente für Raytracing angeführt (die in der Landschaft verteilten, schwebenden Chrome-Kugeln sind gut auf den Bildern zu erkennen;)), von der benötigten Leistung mal ganz zu schweigen.

Wie man Raytracing beeindruckend darstellt hat ATi vor kurzem gezeigt:
http://picasaweb.google.co.uk/Fudzilla.com/ATI4800SeriesTechDemo/photo#5208079896638449394
;)

also die intel-sachen überzeugen derzeit leider NICHT!

[Aquaschaf]

since we do not believe that CPUs would deliver a similar performance when rasterizing graphics

Da haben sie recht. Rasterization auf der CPU wäre viel flotter. Ich denke Carmack hat es in dem Interview zu dem Thema gut auf den Punkt gebracht. Man beeindruckt niemanden indem man Spiele mit der Technologie von gestern (Spiele mit der id engine sind ja noch schön herausgegriffen weil sie dank stencil shadows mit Polygonen relativ geizig umgehen) mit der Performance von Grafikkarten von vorvorgestern zeigt. Und erst recht nicht mit reflektierenden Kugeln.

[AnarchX]

Laut B3D ist es wohl nicht mal ein vollständiges QW inkl. Raytracing, so hat man aus Performancegründen einige Shader herausgeworfen:
http://forum.beyond3d.com/showthread.php?t=48493

Pohl mag zwar in seinem Fachbereich viel auf dem Kasten haben, aber seine Vorstellungen von Raytracing in Spielen sind doch sehr realitätsfern.

Mal sehen ob mit Larrabee oder AMDs Cinema 2.0 vielleicht der Raytracing-Anteil in der Echtzeitgrafik etwas steigt.

[DR.ZEISSLER]

ich hatte von ati bisher gar nix erwartet, aber das, was da gezeigt wurde im dem 30 sek demo, sah sehr beeindruckend aus (im gegensatz zu qw mit pohls raytracer)

Doc

[aths]

Ich dachte für dynamisches global illumination wäre Raytracing perfekt geeignet?
Vor allem wenn man den Begriff "Photorealismus" ernst nimmt! Z.B. die "echten" Photorenderer wie Maxwell, die bereits auf einem Level von physikalischer Lichtsimulation sind, nutzen Raytracing Verfahren.
Natürlich wird so etwas nicht auf der Playstation4 laufen, aber am Ende der Fahnenstange in X Jahren wird dann doch wieder das Raytracing stehen.Nicht unbedingt. Spiele sind in erster Linie von einem funktionierenden Gameplay und insich glaubwürdiger Grafik abhängig. Fotorealismus ist in vielen Genres gar nicht erwünscht. Wo doch, lassen sich mehr oder minder fotorealistische Szenen auch per Rasterizer erstellen.

[Gast]

Nicht unbedingt. Spiele sind in erster Linie von einem funktionierenden Gameplay und insich glaubwürdiger Grafik abhängig. Fotorealismus ist in vielen Genres gar nicht erwünscht. Wo doch, lassen sich mehr oder minder fotorealistische Szenen auch per Rasterizer erstellen.
doch leider verkaufen sich spiele sehr oft nur ueber die grafik, zumindestens erreichen sie durch sie die erste aufmerksamkeit. es gibt viele viele gute spiele die die meisten erst garnicht kennen weil diese keine super grafik bieten.
im hart umkaempften markt muss man irgendwie herausragen und grafik ist das am einfachsten vorzuzeigende.
leider seh ich aber auch nicht was raytracing dem ganzen bringen sollte, kinofilme sind meistens auch nicht realistaetsnah, sondern absichtlich richtung kuenstlich geshoben, weil es auf uns besser wirkt. Die artist dort koennten radiosity berechnen lassen und sie bevorzugen per hand positive und negative lichtquellen hinzustellen um den look zu erreichen den sie wollen. es soll gut aussehen, nicht echt.
fuer mich sieht UT3 auch besser aus als Quakewars mit raytracing, selbst wenn sie sich stunden zeit pro bild lassen wuerden.
realitaet hat mehr als nur das berechnen eines bildes, was nuetzt das wenn zwei objekte trotzdem aussehen als ob sie zusammengesteckt worden waeren?

[Coda]

Laut B3D ist es wohl nicht mal ein vollständiges QW inkl. Raytracing, so hat man aus Performancegründen einige Shader herausgeworfen:
http://forum.beyond3d.com/showthread.php?t=48493

Pohl mag zwar in seinem Fachbereich viel auf dem Kasten haben, aber seine Vorstellungen von Raytracing in Spielen sind doch sehr realitätsfern.

Mal sehen ob mit Larrabee oder AMDs Cinema 2.0 vielleicht der Raytracing-Anteil in der Echtzeitgrafik etwas steigt.
Hybride Ansätze sind für mich genauso realitätsfern. Sobald man irgendwas in Richtung Raytracing machen will muss man sofort die ganze Zeit für alle Geometrie eine Szenenhierarchie updaten und mitschleppen.

Allein das würde z.B. dazu führen dass Vertex- und Geometry-Shader wie wir sie heute haben gar nicht mehr einsetzbar wären. Viel Spaß das den Entwicklern beizubringen. Ich halte das außerdem für den absoluten Horror wenn man z.B. noch Geometrie streamen will bei großen Welten. Außer man lässt wenigstens den Baum immer komplett im Speicher.

Der Aufwand für Raytracing lohnt sich einfach nicht. In der Zeit in der man das implementiert kann man soviel an Rasterisierung forschen und pfuschen dass es wohl immer noch bessere Resultate liefert.

[Kriton]

Aber gibt es nicht irgendwann einen Punkt X wo Rasterizer so aufwendig werden (von der Grafikqualität her), dass sie sich nicht mehr lohnen, während Raytracer, wenn sie denn einmal stehen, unabhängig von der Grafikqualität kaum unterschiedliche Performance brauchen (die natürlich erst einmal da sein muss)?

[Aquaschaf]

unabhängig von der Grafikqualität kaum unterschiedliche Performance brauchen

Nein, die nötige Performance steigt dort genauso mit der Grafikqualität.

[Arcanoxer]

Der 16-Kern (4x4) 2.93 GHz Tigerton auf den Intel ETQW in Raytracing demonstriert hat, lief auf ein 64bit Linux OS.
Das ist doch mal zukunftsweisend! (y)

"Der Effekt des Ganzen: Authentische und live berechnete Spiegelungen in den Fensterscheiben, reale Diffusionseffekte im und unter Wasser." holarse.de (http://www.holarse-linuxgaming.de/news/et_quake_wars_durch_ray_tracing) tgdaily.com (http://www.tgdaily.com/html_tmp/content-view-37925-113.html)

Ich finde es gut wenn man mit alternativen Renderingmethoden experimentiert, die Prozessoren werden ja auch immer schneller und schneller.

[Exxtreme]

Aber gibt es nicht irgendwann einen Punkt X wo Rasterizer so aufwendig werden (von der Grafikqualität her), dass sie sich nicht mehr lohnen, während Raytracer, wenn sie denn einmal stehen, unabhängig von der Grafikqualität kaum unterschiedliche Performance brauchen (die natürlich erst einmal da sein muss)?
Nein. Es gibt sicherlich Szenarien wo RT besser ist als Rastersizer. In Spielen ist es meist nicht der Fall. Spiele müssen nicht realistisch beleuchtet sein sondern einfach nur "gut aussehen".

Zudem bedeutet auch bei RT mehr Content höheren Rechenaufwand.

[Gast]

Spiele müssen nicht realistisch beleuchtet sein sondern einfach nur "gut aussehen".

Ein Wiederspruch in sich!
Spiele werden immer besser aussehen, weil die Beleuchtung ect. immer besser wird!

[Aquaschaf]

Ein Wiederspruch in sich!

"Besser" ist ungleich "realistischer".

[Gast]

"Besser" ist ungleich "realistischer".
Wenn man sagt "ein Spiel sieht immer besser und besser aus", meint man automatisch realistischer!
Das ist ja das Ziel von der immer besseren Grafik => sie soll realistischer sein!

[rotalever]

Wenn man sagt "ein Spiel sieht immer besser und besser aus", meint man automatisch realistischer!
Das ist ja das Ziel von der immer besseren Grafik => sie soll realistischer sein!
Nein nicht unbedingt. Es reicht wenn sie die richtige Atmosphäre erzeugt. (Photo-)realistisch muss sie dazu nicht sein.

[Gast]

(Photo-)realistisch muss sie dazu nicht sein.

auch ein foto muss nicht unbedingt realistisch, sein, ein spiel sollte aber durchaus "fotorealistisch" sein ;)

[rotalever]

auch ein foto muss nicht unbedingt realistisch, sein, ein spiel sollte aber durchaus "fotorealistisch" sein ;)
Okay.. Halt "Augenrealistisch" oder so ähnlich

[Gast]

ein spiel sollte aber durchaus "fotorealistisch" sein ;)Sicher nicht. Will ich Mario Kart spielen, darf das nicht wie eine Rennsimulation aussehen. Will ich Beyond Good And Evil spielen, darf das nicht wie ein verbessertes Max Payne 1 aussehen. Soll Team Fortress wie ein CoD 7 wirken? World of Warcraft wie Second Life 712?
Photorealismus ist vielen Spielen durchaus nicht förderlich.

[Aquaschaf]

Wenn man sagt "ein Spiel sieht immer besser und besser aus", meint man automatisch realistischer!

Nein. Wie kommst du darauf? Beispielsweise sieht Team Fortress 2 technisch fortgeschrittener, wenn man so will auch "besser", aus als Max Payne 2. Realistischer aber ganz bestimmt nicht.

[Gast]

realismus ist meistens eine frage des contents, wenn ein artist was kunderbuntes zeichnet statt ein photo zu machen oder wenn shader gewaehlt werden die cartoonish shaden statt microfacets zu simulieren, wird es nicht photorealistisch aussehen.

qualitaet haengt dagegen eher von der technik ab, wenn etwas besser aussieht, dann weil es besser aufgeloest texturen hat(fuer artists kann es nie genug sein, daher ist es keine frage des contents), weil schatten dynamisch sind, weil felder dicht mit grass belegt sind (wenn auch das grass vielleicht nur wie bei zeldaWW aussieht).

ich glaube es wuerde echt oede werden wenn spiele photorealistisch geraytraced werden wuerden. die ersten 3 crysis-raytraced wuerden toll sein, aber wenn man das dann ueberall hat (UT3 mit photorealismus :eek:), wuerde das im einheitsbrei enden. (sowas wie in etwa mit T&L aufkam).

[betasilie]

Nein. Wie kommst du darauf? Beispielsweise sieht Team Fortress 2 technisch fortgeschrittener, wenn man so will auch "besser", aus als Max Payne 2. Realistischer aber ganz bestimmt nicht.
Diese Art von Grafik ist aber auch mit Raytracern möglich. Im Grunde ist alles mit Raytracern möglich, die Frage ist nur, bei welchen Renderstilen sie ihre Stärken ausspielen können. TF2 und seine Optik ist aber weniger eine Frage der Rendertechnik, als vielmehr des Designs.

[Aquaschaf]

Im Grunde ist alles mit Raytracern möglich

Das stand hier ja nie zur Debatte.

[deekey777]

In der aktuellen c't (15/2008) gibt es einen Artikel zum Thema Raytracing vs. Rasterizing.
Da wird so manches Argument für Raytracing entkräftet, insbesondere auf die Sicht der Entwickler wird hingewiesen.

[betasilie]

Also ich bin mitlerweile auch nicht mehr von Raytracern überzeugt. Es kommt halt wirklich nur auf das subjektive Ergebnis an und da werden Rasterizer wohl lange, lange im Vorteil bleiben.

[][immy]

Also ich bin mitlerweile auch nicht mehr von Raytracern überzeugt. Es kommt halt wirklich nur auf das subjektive Ergebnis an und da werden Rasterizer wohl lange, lange im Vorteil bleiben.

der vorteil das die rechenkraft aber nicht so stark steigen muss um bessere optik zu bieten wird so langsam aber immer deutlicher. man siehe sich einfach nur die letzten grafikkarten-generationen an.
viel mehr hardware, aber eine so extreme vervielfachung der performance oder bildqualität gab es dafür nicht.

ray-tracing ist bestimmt nicht der heile gral der computergrafik, aber so langsam scheint doch die zeit dafür gekommen zu sein. allerdings wenn man auch bedenkt das der rechenaufwand dann maßgeblich mit der auflösung verbunden ist und diese derzeit in de höhe schnellt, dann könnte ich mir vorstellen das es doch noch sehr viel länger dauern wird. aber gpus mutieren langsam aber sicher eh zu alles-beschleunigern, von daher würde es mich auch nicht wundern wenn in nächster zeit (also ein paar jahre) vielleicht die ersten RT-titel vor der tür stehen.

andererseits gibt es grafisch derzeit auch viele "rückschritte". die Wii zeigt es ja deutlich. massenware ist angesagt und da zählt gute grafik nunmal nicht. zudem ist gute grafik teuer und zeitintensiv. von daher kommt RT vielleicht auch wieder deutlich später.

[Aquaschaf]

[immy;6656085']der vorteil das die rechenkraft aber nicht so stark steigen muss um bessere optik zu bieten wird so langsam aber immer deutlicher.

Dass Raytracing da im Vorteil ist stimmt einfach nicht. Diese O(log n) vs. O(n) Geschichte ist in der Praxis falsch.

[Coda]

Vor allem unter Annahme von dynamischer Geometrie und LOD.

[deekey777]

[immy;6656085']der vorteil das die rechenkraft aber nicht so stark steigen muss um bessere optik zu bieten wird so langsam aber immer deutlicher. man siehe sich einfach nur die letzten grafikkarten-generationen an.
viel mehr hardware, aber eine so extreme vervielfachung der performance oder bildqualität gab es dafür nicht.

ray-tracing ist bestimmt nicht der heile gral der computergrafik, aber so langsam scheint doch die zeit dafür gekommen zu sein. allerdings wenn man auch bedenkt das der rechenaufwand dann maßgeblich mit der auflösung verbunden ist und diese derzeit in de höhe schnellt, dann könnte ich mir vorstellen das es doch noch sehr viel länger dauern wird. aber gpus mutieren langsam aber sicher eh zu alles-beschleunigern, von daher würde es mich auch nicht wundern wenn in nächster zeit (also ein paar jahre) vielleicht die ersten RT-titel vor der tür stehen.

andererseits gibt es grafisch derzeit auch viele "rückschritte". die Wii zeigt es ja deutlich. massenware ist angesagt und da zählt gute grafik nunmal nicht. zudem ist gute grafik teuer und zeitintensiv. von daher kommt RT vielleicht auch wieder deutlich später.

In dem oben erwähnten Artikel gibt es eine Passage, die das Prädikat "Klugscheißer" verdient:
"Doch gerade in Spielen müssen 3D-Welten bloß gut aussehen und nicht physikalisch exakt sein. Hier gibt es auch wenige Gelegenheiten, in denen Raytracing seine größten Stärken zeigen kann: Hochglanz-Flächen und komplizierte Glaskörper sind in natürlichen Umgebungen eher ungewöhnlich."

[DR.ZEISSLER]

ohne jetzt den thread durchgelesen zu haben poste ich mal das hier:
http://forum.ingame.de/quake/showthread.php?s=&threadid=247804

kann jemand damit was anfangen und was ist das überhaupt ?

Doc

[Coda]

ioquake3 sind inoffizielle Patches für Quake 3 weil der Source Code ja seit ner Weile GPL ist.

Da hat halt jemand seine Raytracing-Lib reingepatcht. Und offenbar verwendet er kein Mipmapping *würg*

[Gast]

@zeissler

http://ioquake3.org/files/angst/ioquake3-latest.x86.exe

[RaumKraehe]

Interessant an dieser ganzen Diskussion finde ich den Fakt das Raytracing gerade von einem Prozessorhersteller forciert wird. Welche ein Wunder. ;)

Intel hat schlicht das Problem das Rechenpower auf heimischen Schreibtischen reichlich vorhanden ist und der Grund jedes Jahr einen neunen Prozessor zu kaufen immer geringer wird. Da kommt die Idee Raytracing einzusetzen doch gerade richtig. Multicore Prozessoren bis zum Abwinken. Und schon hat man wieder ein Markt der nie genug Cores haben kann.

Gutes Marketing würde ich sagen. ;)

[roidal]

In dem Artikel "Raytracing in Spielen" von Computerbase wird ja erklärt dass Raytracing logarithmisch mit der Anzahl der Polygone scaliert und es somit einen Punkt gibt wo Raytracing effizienter wird. Ist es aber nicht eher so das beide linear scalieren, und nur durch spezielle Optimierungen (wie eben den sortierten Bäumen) bei Raytracing dafür gesort wird das es logarithmisch scaliert? Ist es auch nicht der Fall dass beim Rasterisieren auch optimierungen eingesetzt werden wodurch die bei heutigen Spielen auch nicht linear scalieren?

[Chris Lux]

In dem Artikel "Raytracing in Spielen" von Computerbase wird ja erklärt dass Raytracing logarithmisch mit der Anzahl der Polygone scaliert und es somit einen Punkt gibt wo Raytracing effizienter wird. Ist es aber nicht eher so das beide linear scalieren, und nur durch spezielle Optimierungen (wie eben den sortierten Bäumen) bei Raytracing dafür gesort wird das es logarithmisch scaliert? Ist es auch nicht der Fall dass beim Rasterisieren auch optimierungen eingesetzt werden wodurch die bei heutigen Spielen auch nicht linear scalieren?
genau richtig.

mit hilfe von spatialen datenstrukturen und occlusion culling techniken erreichen rasterizer renderer auch logarithmisches laufzeitverhalten.

[Coda]

"spatialen" ist fast genauso gut wie "Code exekutieren".

[roidal]

http://www.golem.de/0808/61949.html - und es geht weiter.

[DR.ZEISSLER]

DAMIT HABEN DIE SICH KEINEN GEFALLEN GETAN.
SIEHT WIRKLICH NCIHT BESONDERS AUS UND PERFORMT AUCH SEHR SCHLECHT!

Doc

[deekey777]

DAMIT HABEN DIE SICH KEINEN GEFALLEN GETAN.
SIEHT WIRKLICH NCIHT BESONDERS AUS UND PERFORMT AUCH SEHR SCHLECHT!

Doc
Schrei nicht so.

Man sollte sich den Spaß erlauben und die RT-Leute fragen, wie lange es noch dauert, bis wir ein "Raytracing-Spiel" sehen, das die visuelle Qualität eines Crysis hat.

[roidal]

Man sollte sich den Spaß erlauben und die RT-Leute fragen, wie lange es noch dauert, bis wir ein "Raytracing-Spiel" sehen, das die visuelle Qualität eines Crysis hat.

Ich denke mal mit entsprechenden Texturen und Modellen sollte man damit schon einiges machen können. Zusätzliche Effekte werden sicher auch bald kommen, nur die dafür benötigte Rechenleistung ist etwas..."hoch" :D

[Coda]

Das größte Problem wären wohl Soft Shadows. Das ist mit Raytracing ziemlich teuer.

[roidal]

Das größte Problem wären wohl Soft Shadows. Das ist mit Raytracing ziemlich teuer.

Wo wir wieder bei der Fragen wären was wohl in Zukunft verwendet wird...Rasterisierung oder Raytracing...:biggrin:

[AnarchX]

Wo wir wieder bei der Fragen wären was wohl in Zukunft verwendet wird...Rasterisierung oder Raytracing...:biggrin:
Beides in einer Engine, wenn auch Herr Pohl davon nicht hören will.;)

Zumal Raytracing nicht nur im Zusammenhang mit großen, reflektierenden Kugeln in Spielen sinnvoll ist:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6742022#post6742022

Aber insgesamt finde ich das momentane Unterfangen dem Pohl nachgeht doch eher sinnlos, welche Nutzen hat man davon das ein eigentliches Raster-Game auf ein $10.000 4-Sockel-High-End-PC in etwa wie auf einer Einsteiger-GraKa um die ~$50 läuft. :|

Da wäre es doch sinnvoller etwas auf nativer Basis zu machen...

Aber naja im Endeffekt ist eh nur Werbung für Multi-CPUs die Intel aus der Portokasse zahlt und entsprechend Wirkung zeigt, aber mit den eigentlichen Zielen von Intel bzw. der VCG im Bezug auf Spielegrafik hat es wohl weniger zu tun.

[tombman]

welche Nutzen hat man davon das ein eigentliches Raster-Game auf ein $10.000 4-Sockel-High-End-PC in etwa wie auf einer Einsteiger-GraKa um die ~$50 läuft.
Jo, das ist das Problem. Nur wegen der perfekten Spiegelung haut kein gamer mit Verstand soviel Kohle raus.
24 cpu Kerne ist einfach nur LOL.

Da traue ich doch eher Nvidia/ATI zu etwas Sinnvolles zu machen, zb eine Mischung aus den Methoden...

[Gast]

Jo, das ist das Problem. Nur wegen der perfekten Spiegelung haut kein gamer mit Verstand soviel Kohle raus.
24 cpu Kerne ist einfach nur LOL.

Da traue ich doch eher Nvidia/ATI zu etwas Sinnvolles zu machen, zb eine Mischung aus den Methoden...

Mag sein. Allerdings sind 24 CPU kerne in zehn Jahren vielleicht auch nur noch LOL.

[Exxtreme]

Mag sein. Allerdings sind 24 CPU kerne in zehn Jahren vielleicht auch nur noch LOL.
Und was meinst du was für Rastersizer AMD und Nvidia in 10 Jahren haben?

[tombman]

Und was meinst du was für Rastersizer AMD und Nvidia in 10 Jahren haben?
Nicht nur Rasterizer. Die werden supercomputer-on-a-chip haben ;)
Dagegen wird heutige hw Kinderkacke sein, so wie hw von 1998 jetzt ;)

[Coda]

Zumal Raytracing nicht nur im Zusammenhang mit großen, reflektierenden Kugeln in Spielen sinnvoll ist:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6742022#post6742022
Da ist Raycasting auf Terrain-Geometrie gemeint. Das hat mit dem Raytracing was du meinst rein gar nichts zu tun.

[dargo]

Mag sein. Allerdings sind 24 CPU kerne in zehn Jahren vielleicht auch nur noch LOL.
Jetzt mal ersthaft - wer will in 10 Jahren noch Quake Wars sehen? Bei dem Tempo könnten wir ~2018 schon eine mögliche CryEngine 4 zu Gesicht bekommen. Und jetzt schaue dir mal FarCry und Crysis an. X-D

[Gast]

Warum führen so viele von euch Diskussionen über die benötigte Rechenpower bei den Ansätzen von Rasterizer vs Raytracer?

Lasst doch mal die benötigte Rechenleistung außen vor und geht davon aus, ihr hätten unendlich viel Rechenpower. Welches verfahren kann mit dieser Annahme bereits heute mehr visuell umsetzen und das sollte doch die wesentliche Frage sein.

Und so nebenbei: Kann mir jemand sagen, warum ich teilweise Spieletitel aus dem Regal ziehen kann von anno 1998 und dort ein Intro zu sehen ist (wahrscheinlich mit 3Ds gerendert) und das durchaus mit heutigen Rasterengines gleich zieht? Auch heute noch werden gerne Intros vorgerendert präsentiert anstatt mit der eigentlichen Engine zu generieren. Warum nur? und warum sehen diese auch mehr kinoartig aus mit wesentlich mehr Details als es die eigentlichen Engines des Spiels? De beiden Fragen sind eher rhetorisch zu sehn ;-)

[Ganon]

Lasst doch mal die benötigte Rechenleistung außen vor und geht davon aus, ihr hätten unendlich viel Rechenpower. Welches verfahren kann mit dieser Annahme bereits heute mehr visuell umsetzen und das sollte doch die wesentliche Frage sein.

Und welchen Sinn hat das?

Da können wir uns auch gleich darüber unterhalten, wie das Leben wäre wenn wir nicht essen oder schlafen müssten. Hat genauso viel Sinn.

[Coda]

Und so nebenbei: Kann mir jemand sagen, warum ich teilweise Spieletitel aus dem Regal ziehen kann von anno 1998 und dort ein Intro zu sehen ist (wahrscheinlich mit 3Ds gerendert) und das durchaus mit heutigen Rasterengines gleich zieht?
Die meisten Offline-Renderer sind auch Rasterizer.

[Gast]

Und welchen Sinn hat das?

Da können wir uns auch gleich darüber unterhalten, wie das Leben wäre wenn wir nicht essen oder schlafen müssten. Hat genauso viel Sinn.


Ich sehe du hattest keine Monster3D-Karte Anfang der 90er in deinen Rechner gesteckt. Welchen Sinn hat das ganze lol. Es hat den Sinn sich nicht über irgendwelche linear vs. log Anstiegskurven zu unterhalten.

Mir wären neue Engine-Konzepte lieber die in der ersten Generation kaum spielbar sind, in der 2ten Generation fast flüssig und in der dritten ihr Potential zeigen.


@Coda

Scheinst absoluter Rasterizer-Verfechter zu sein. Sei es drum, ich arbeite in dieser Branche nicht.
Unter was fällt dann 3D Studio bei Dir? Habe das Teil eher als Raytracer verstanden.

[Coda]

Scheinst absoluter Rasterizer-Verfechter zu sein.
Nein bin ich nicht. Ich bin nur der Meinung, dass Raytracing weit überbewertet wird.

Unter was fällt dann 3D Studio bei Dir? Habe das Teil eher als Raytracer verstanden.
Hybrid.

[Gast]

Nicht nur Rasterizer. Die werden supercomputer-on-a-chip haben ;)
Dagegen wird heutige hw Kinderkacke sein, so wie hw von 1998 jetzt ;)
Ich würde sogar soweit gehen zu sagen, das AMD/NV in 10 Jahren die Leistung vermehrfacht haben, also einen 2x-4x weiteren Sprung hinlegen als in den letzten 10 Jahren.
Natürlich müsste man den Fertigungsprozess nicht nur "verkleinern", sondern auch so langsam ausbessern. Je kleiner diese werden, umso mehr Fehler entstehen bei der Produktion bzw. Fertigung.
Da gabs doch mal auch vor kurzem News das in Deutschland speziell daran gearbeitet wird.?!?!

[Gast]

Ich würde sogar soweit gehen zu sagen, das AMD/NV in 10 Jahren die Leistung vermehrfacht haben, also einen 2x-4x weiteren Sprung hinlegen als in den letzten 10 Jahren.

Glaub ich nicht. Grafikkarten sind in den letzten Jahren, verglichen mit der restlichen Halbleiterindustrie, überproportional viel schneller geworden. Dies u.a. daher, dass zu Anfangszeiten der 3D Grafik eher Low-End Fertigung benutzt wird, mittlerweile aber absolutes High-End genutzt wird. Es ist also kein Spiel mehr da um mit aktueller Technologie mehr Leistung herauszuholen.

Natürlich müsste man den Fertigungsprozess nicht nur "verkleinern", sondern auch so langsam ausbessern. Je kleiner diese werden, umso mehr Fehler entstehen bei der Produktion bzw. Fertigung.
Da gabs doch mal auch vor kurzem News das in Deutschland speziell daran gearbeitet wird.?!?!

Der Fertigungsprozess wird laufend verbessert. Die Ausbeute eines Prozess wird zu seinem Lebensende immer besser, damit warten sie nicht bis 11nm.

[Coda]

Also NV5 (NVIDIA Riva TNT 2) war 1999 250nm, Der Katmai Pentium III war 1999 auch 250nm

Wo war das Low-End? Eigentlich hat man immer den neusten TSMC-Prozess verwendet, vor allem ATI.

[dust]

wegen der entwicklung, rückblick auf vor 10 jahren
http://en.wikipedia.org/wiki/RIVA_TNT
Direct3D and Shader version Direct3D 6.0

aktuell ist
http://en.wikipedia.org/wiki/GeForce_9_Series
Direct3D and Shader version D3D 10, Model 4

hat sich also einiges getan und das wird so ähnlich weitergehen. deswegen bin ich mir sicher realtime raytracing in spielen wird kommen und die frage ist nicht ob sondern wann.

[Coda]

Die Frage ist eher "wozu?"

[Deinorius]

Also mehr nach der Frage:
Will man die bestaussehendste Grafik? oder
Will man die am meisten realistische Grafik?

[dust]

es gibt arcade gamer die wollen effekte und sim gamer die wollen realismus.

[Coda]

Also mehr nach der Frage:
Will man die bestaussehendste Grafik? oder
Will man die am meisten realistische Grafik?
Nein.

Raytracing ist nicht "realistischer" als Rasterisierung und Rasterisierung ist nicht "realistischer" als Raytracing. Beide Algorithmen können prinzipiell genau die gleichen Bilder erzeugen. Es geht darum was effizienter ist.

[dust]

Nein.

Raytracing ist nicht "realistischer" als Rasterisierung und Rasterisierung ist nicht "realistischer" als Raytracing. Beide Algorithmen können prinzipiell genau die gleichen Bilder erzeugen. Es geht darum was effizienter ist.
das ist falsch! http://de.wikipedia.org/wiki/Rendergleichung darum geht es beim raytracing.

[Coda]

das ist falsch! http://de.wikipedia.org/wiki/Rendergleichung darum geht es beim raytracing.
Nein ist es nicht. Die Rendergleichung gilt genauso für Rasterisierung.

Normales Forward-Raytracing behandelt genauso wie Rasterisierung auch nur einen sehr eingegrenzten Fall dieser Formel. Die volle Formel liese sich mit ausreichender Rechenzeit aber auch mit beiden Verfahren abdecken.

Und du brauchst mir ganz sicher nicht erklären worum es beim Raytracing geht, ich habe schon selber einen einfachen geschrieben.

[Gast]

das ist falsch! http://de.wikipedia.org/wiki/Rendergleichung darum geht es beim raytracing.
Falsch, darum geht es bei raytracing nicht.

[dust]

Nein ist es nicht. Die Rendergleichung gilt genauso für Rasterisierung.

Normales Forward-Raytracing behandelt genauso wie Rasterisierung auch nur einen sehr eingegrenzten Fall dieser Formel.
beim rastern geht es um effekte, man hat diesen weg gewählt weil die leistung für raytracing nicht gereicht hat und damit eben versucht die grafik realitischer aussehen zu lassen.

[dust]

Falsch, darum geht es bei raytracing nicht.
beim raytracing geht es um die rendergleichung, andernfalls bleib beim rastern.

[Coda]

beim rastern geht es um effekte, man hat diesen weg gewählt weil die leistung für raytracing nicht gereicht hat und damit eben versucht die grafik realitischer aussehen zu lassen.
Mir platzt echt langsam der Kragen mit dir.

NEIN. Und ich habe schon etliche Male ausgeführt warum das einfach nur Bullshit ist.

beim raytracing geht es um die rendergleichung, andernfalls bleib beim rastern.
Das ist völlig unhaltbar.

[Gast]

beim rastern geht es um effekte, man hat diesen weg gewählt weil die leistung für raytracing nicht gereicht hat und damit eben versucht die grafik realitischer aussehen zu lassen.
Warum lässt du es nicht einfach. Du machst dich grad mal wieder extrem lächerlich mit deiner Unwissenheit.

[dust]

Mir platzt echt langsam der Kragen mit dir.

NEIN. Und ich habe schon etliche Male ausgeführt warum das einfach nur Bullshit ist.


Das ist völlig unhaltbar.
ach seit wann gibt es deiner meinung nach für den home user käufliche hardware die realtime raytracing kann? eben weil nicht nimmt man das rastern.

natürlich geht es beim raytracing um die rendergleichung. worum soll es sonst gehen? andernfalls kannst beim rastern bleiben.

[dust]

Warum lässt du es nicht einfach. Du machst dich grad mal wieder extrem lächerlich mit deiner Unwissenheit.
ich sehe es genau umgekehrt...

[Coda]

ach seit wann gibt es deiner meinung nach für den home user käufliche hardware die realtime raytracing kann? eben weil nicht nimmt man das rastern.
Nein, weil es effizienter ist. Und zwar sowohl in Software als auch in Hardware.

natürlich geht es beim raytracing um die rendergleichung. worum soll es sonst gehen? andernfalls kannst beim rastern bleiben.
Du hast nicht den blassesten Schimmer von was du redest. Und schon gar nicht davon was die Rendergleichung überhaupt bedeutet.

Und den "andernfalls kannst beim rastern bleiben"-Spruch kannst du dir auch sparen, weil die Rasterisierung genauso wie Raytracing einen Teil der Rendergleichung abdeckt. Das ist die fundamentale Formel jedes 3D-Renderings.

[Gast]

ich sehe es genau umgekehrt...
Ja "selber, selber!".
Kindergartenniveau...

[MadMax@]

Nein, weil es effizienter ist. Und zwar sowohl in Software als auch in Hardware.


Du hast nicht den blassesten Schimmer von was du redest. Und schon gar nicht davon was die Rendergleichung überhaupt bedeutet.

Und den "andernfalls kannst beim rastern bleiben"-Spruch kannst du dir auch sparen, weil die Rasterisierung genauso wie Raytracing einen Teil der Rendergleichung abdeckt. Das ist die fundamentale Formel jedes 3D-Renderings.

Nun ja das halte ich aber doch für sehr an den Haaren herbeigezogen. Die RG ist die fundamentale Gleichung für Globale Beleuchtung und mehr nicht. Rastering ist nach meiner Definition erst mal nichts anderes als ein Darstellungs Verfahren sowie Raycasting. Raytracing ist eben die Verbindung zwischen einem Darstellungs und einem Globalen(all. nur spekular) Beleuchtungsverfahren.
Du kannst auch komplett ohne Beleuchtung Rasterisieren oder einen nicht photorealistische Beleuchtung benutzen das hat alles aber nicht mit der Rendering Gleichung zu tun.

[Coda]

Nun ja das halte ich aber doch für sehr an den Haaren herbeigezogen.
Ich nicht, das wird uns auch so beigebracht.

"Normales" Raytracing ohne irgendwelches Monte-Carlo-Zeug kann halt einen Bruchteil mehr als Rasterisierung mit Stencil-Shadows ausfüllen, und zwar die perfekten Spiegelungen. Das geht theoretisch aber auch mit Cubemaps für jedes Sample (ja, das ist praktisch nicht machbar).

Die Frage ist wirklich nur die Laufzeit bei beiden Verfahren.

[Sven77]

Selbst Productionrenderer wie Mental Ray, Pixar Renderman, VRay usw. benutzen fuer Primary Rays immer den Rasterizer, weil dieser effektiver ist. Und hier kommt es auf Qualitaet an, nicht auf Renderzeit... auf gut deutsch: dust, du redest Quark..

[dust]

Selbst Productionrenderer wie Mental Ray, Pixar Renderman, VRay usw. benutzen fuer Primary Rays immer den Rasterizer, weil dieser effektiver ist. Und hier kommt es auf Qualitaet an, nicht auf Renderzeit... auf gut deutsch: dust, du redest Quark..
als ob es in filmen auf realismus ankommen würde und nicht auf "coole" effekte. zb. die ganzen auto explosionen sind natürlich voll realistisch...

[Sven77]

wenn du etwas ahnung haettest, wuesstest du, das explosionen immer noch SFX sind, und kein VFX, egal in welchen Produktionen..
Ausserdem was haben in dem Zusammenhang Effekte und Realismus zu suchen.. Auch ein Transformer wird mit Rasterizer gerendert, Raytracing nur da eingesetzt wo noetig (Occlusion, Reflection, Refraction, Schatten). Wer glaubt in Filmen wird mit Global Illumination gerendert, irrt uebrigens..

[Deinorius]

Die Explosion soll ja auch realistisch aussehen. Warum das Auto explodiert hat mit dem Renderverfahren absolut rein gar nix zu tun. Mach die Filmemacher dafür verantwortlich, aber nicht die Renderer.

[Gast]

als ob es in filmen auf realismus ankommen würde und nicht auf "coole" effekte. zb. die ganzen auto explosionen sind natürlich voll realistisch...
vielleicht schon, da man die hingezauberten bilder nicht von den gefilmten unterscheiden kann - das ist doch zumindest das ziel oder steh ich aufm faden? ich finde du solltest dich besser informieren. ich hab auch keine ahnung aber lalle wenigstens nicht irgendwas zusammen und versuche es mit wiki zu untermauern.

[dust]

Ausserdem was haben in dem Zusammenhang Effekte und Realismus zu suchen..
weil es im film um illusionen geht und nicht um realität!

[Gast]

weil es im film um illusionen geht und nicht um realität!
Und wie erzeugt man deiner Meinung nach eine Illusion ?
Was ist denn DEINE Referenz für Grafik ? Wenn nicht der Film, was dann?
Wenn dir Filme zu "unrealistisch" sind, was willst du dann mit Games ?

Du redest dermassen wirren Schei§§ das ist kaum auszuhalten.

[Gast]

Wer glaubt in Filmen wird mit Global Illumination gerendert, irrt uebrigens..

;) auch in filmen wird global illumination benutzt...

das explosionen immer noch SFX sind,

na nicht alle ;) du solltest nicht so radikal denken sven!

[dust]

Und wie erzeugt man deiner Meinung nach eine Illusion ?
Was ist denn DEINE Referenz für Grafik ? Wenn nicht der Film, was dann?
Wenn dir Filme zu "unrealistisch" sind, was willst du dann mit Games ?

Du redest dermassen wirren Schei§§ das ist kaum auszuhalten.
meine referenz ist die realität, ich mag am liebsten simulationen.

ich habe schon weiter oben geschrieben es gibt arcade gamer und simulations gamer...

[AnarchX]

meine referenz ist die realität, ich mag am liebsten simulationen.

ich habe schon weiter oben geschrieben es gibt arcade gamer und simulations gamer...
Mal als Erinnerung, dass hier ist das Technologieforum, wenn hier von dir nur Flames kommen, anstatt sinnvoller Inhalt, mit fachlichen Hintergrund, wird das Konsequenzen haben.

[AnarchX]

Ich nicht, das wird uns auch so beigebracht.

"Normales" Raytracing ohne irgendwelches Monte-Carlo-Zeug kann halt einen Bruchteil mehr als Rasterisierung mit Stencil-Shadows ausfüllen, und zwar die perfekten Spiegelungen. Das geht theoretisch aber auch mit Cubemaps für jedes Sample (ja, das ist praktisch nicht machbar).

Die Frage ist wirklich nur die Laufzeit bei beiden Verfahren.
Und da sollte man sich einfach mal in seiner Umgebung umschauen: Wie groß ist der Anteil an Objekten mit perfekten Spiegelungen?
Und warum platziert Pohl in seinen Demos immer irgendwelche, doch deplatzierte Chrom-Objekte?;)

Da gibt es doch weit andere Teilaspekte, deren Darstellung zu einer weit realitätsnäheren Darstellung führen, wie eben weiche Schatten, die bei fast jedem Objekt auftretten können, und deren Implementierung scheint im erprobten Rasterverfahren sinnvoller zu sein.

[Sven77]

;) auch in filmen wird global illumination benutzt...

nein, wird nur gefaked

[Gast]

Man dreht sich im Kreis hier...

Wie sieht es denn nun aus mit der besseren Parallelisierung der einzelnen Verfahren. Lässt sich Rasterizer oder Raytracer im Form von Hardware besser in die "Breite" bauen?

Ich bin nur Laie, aber soweit ich das verstehe, sind die Hauptprobleme doch die, das ein Einzelbild sich nicht einfach in Einzelsegmente aufteilen kann und dann sag, GPU1 macht Segement1, GPU2 macht Segment 2....

Hat da nicht das Raytracing einen gewissen Vorteil?

[Coda]

Also es gibt Pixar-Papers die davon sprechen, dass in Cars z.B. durchaus GI verwendet wurde.

[Sven77]

Aber nicht mit Path Tracing oder Photon Mapping, diese Techniken verbieten sich praktisch mit Animationen, weil bei jedem Renderdurchgang unterschiedliche Ergebnisse entstehen. Radiosity gibt keine echte GI, sondern ist nur ein Bestandteil. Tatsächlich ist der Unterschied zwischen physikalisch richtiger GI und der Fakevariante, die, das die zweite besser aussieht, schneller rendert, und man komplette Kontrolle darüber hat.

[Coda]

Oh doch, Photon Mapping:
http://graphics.pixar.com/ShotRendering/paper.pdf
Our technique is complimentary to photonmapping and can be used to accelerate final gathering.

Radiosity ist auch kein Fake. Es behandelt halt nur diffuse Oberflächen.

[Sven77]

Natürlich ist es kein Fake.. Aber auch nur ein Bestandteil von GI.. Radiosity kommt interessanterweise nur in Animationsfilmen zum Einsatz, weil hier Colorbleeding z.B. eher auffällt als bei einem VFX-Titel wie Transformers.. hier kommt weiterhin Ambient Occlusion zum Einsatz, bei dem man mit einem entsprechenden Setup genau ähnliche Ergebnisse erzielen kann.

edit: Gerade unseren Lighting TD gefragt. Tatsaechlich wurde nur in Cars diese Technik benutzt, und auch nur als Extra Layer im Compositing, weil es eine sehr schmutzige GI ist, und nicht direkt ins Bild gerendert werden kann (wird sowieso nie gemacht). Normalerweise gibt es von jedem Shot Referenzbilder, gerendert mit GI, Final-Gather, und allem was die Technik gerade hergibt, und die Lighting-Artists duerfen dann jede Szenen mit irrwitzig vielen Lichtern auffuellen, um exakt denselben Look zu erreichen.

[Gast]

Wie sieht es denn nun aus mit der besseren Parallelisierung der einzelnen Verfahren. Lässt sich Rasterizer oder Raytracer im Form von Hardware besser in die "Breite" bauen?

Ich bin nur Laie, aber soweit ich das verstehe, sind die Hauptprobleme doch die, das ein Einzelbild sich nicht einfach in Einzelsegmente aufteilen kann und dann sag, GPU1 macht Segement1, GPU2 macht Segment 2....
Klar kann man ein Bild in Einzelsegmente aufteilen. Man muss nur schauen was Intel macht.
Allerdings sinkt mit steigender Arbeit die Effizienz. Das ist eins der Argumente warum man bei ID mit Volumeraycasting experimentiert.

[Coda]

Eigentlich ist der Grund dass sie völlig dynamische Geometrie möchten. Voxel-Raycasting ist dann doch auch etwas anderes ggü. Rasterisierung als Raytracing auf Polygongeometrie.

[ScottManDeath]

Bei Shrek 3 wurde wohl Ambient Occlusion eingesetzt, was wiederum die Anzahl der bounce lights die der Artist setzen muss ungefaehr halbiert hat.

[Fragman]

bei shrek2 wurde schon gi eingesetzt, sicher das man bei teil3 auf ao zurueck ging?

[ScottManDeath]

Kann schon sein, der Talk war schon ne Weile her :redface:

[Sven77]

Es wurde wenn mit Sicherheit beides verwendet.. Dem Pixarpaper zufolge kann man GI im Compositing auf jedenfall verwenden, aber nicht als alleinige Methode. Relighting in 2D ist ja auch noch möglich, und wird sicher gemacht..

[roidal]

Man dreht sich im Kreis hier...

Wie sieht es denn nun aus mit der besseren Parallelisierung der einzelnen Verfahren. Lässt sich Rasterizer oder Raytracer im Form von Hardware besser in die "Breite" bauen?

Ich bin nur Laie, aber soweit ich das verstehe, sind die Hauptprobleme doch die, das ein Einzelbild sich nicht einfach in Einzelsegmente aufteilen kann und dann sag, GPU1 macht Segement1, GPU2 macht Segment 2....

Hat da nicht das Raytracing einen gewissen Vorteil?

Würde ich nicht sagen. Bei Rasterisierung werden ja in den Vertex/Pixel-Shadern auch jeder Vertex/Pixel unabhängig voneinander berechnet wordurch sich auch hier parallelisierparkeit ergibt. Heutige Grafikkarten haben auch unzählige Recheneinheiten parallel geschaltet. (Siehe GTX280 mit 280 parallelen Streamprozessoren oder die HD 48x0 mit 800 parallelen SPs)

[MadMax@]

Wie schon in meinem letzten Post geschrieben. Was hat das für einen Sinn zu Diskutieren wen ihr euch nicht mal über die Definitionen einig seit.
Nochmal Rastering != Beleuchtungsverfahren.
Man kann mit Rastering dazu benutzen eine komplette GI Lösung zu implementieren wen man das möchte(mache ich zb.). Man kann es aber auch genauso gut lassen und Raycasting dafür benutzen.

[deekey777]

„Quake Wars“ mit Raytracing (1/5) (http://www.computerbase.de/artikel/hardware/grafikkarten/2009/bericht_quake_wars_raytracing/)
Da beim letzten Artikel paar böse Worte gefallen sind:
Wir weisen darauf hin, dass der nachfolgende Artikel ohne Mitarbeit der ComputerBase-Redaktion entstanden ist und allein die Meinung des Autors bzw. seines Arbeitgebers widerspiegelt. ...

Das Performance-Problem

Performance ist der Hauptgrund, warum Raytracing derzeit noch nicht in kommerziellen Spielen benutzt wird. Verglichen mit einer spezialisierten Rasterisierungshardware (beispielsweise aktuelle GPUs von ATi oder Nvidia) ist Raytracing relativ langsam. Die fehlenden Hardware-Textureinheiten in unserem CPU-basierten Ansatz bringt einen großen Performanceeinbruch beim trilinearen Filtern aller Textursamples. Mit dem neuesten Intel-Quad-Socket-System (ausgestattet mit einem 2.66-GHz-Dunnington-Prozessor (6 Kerne) in jedem Sockel; macht insgesamt 24 Kerne) erreichen wir im Spiel zwischen 20 und 35 Frames pro Sekunde bei einer Auflösung von 1280 x 720 Pixel.
Das ist zwar schön und gut, aber wie wär's mit "Crysis ray-traced"? ;(

Es wird wieder verschwiegen, dass - egal ob RT oder Rasterizing - die Materialshader vor der Beleuchtung stehen. Und diese brauchen auch eine Menge Rechenleistung, denn anders als bei Spiegelungen oder Beleuchtung fällt gefaketes Rostblech eher auf.

[Coda]

Nicht schon wieder...

Edit: Naja, dieses Mal steht nichtmal Mist drin. Erstaunlich.

[Gast]

Nicht schon wieder...

Edit: Naja, dieses Mal steht nichtmal Mist drin. Erstaunlich.
In dem ganzen Artikel steht NICHTS drin.

[Coda]

Naja, es kommen ja noch 4 Teile zum Mist reden ;)

Aber ich glaube die Praxis und die Zusammenarbeit mit den anderen Leuten bei Intel hat ihn auf den Boden der Tatsachen zurückgeholt.

[thacrazze]

Woher hat er eigentlich den Code von Quake 4 und Quake Wars? Haben die eine Lizenz von id?

[Coda]

Hat er nicht. Die Levelformate sind aber in Textformat und einfach lesbar.

Sie müssen aber von id Software zumindest die Erlaubnis haben das Artwork in den Publikationen zu verwenden.

[Simon]

Die Levelformate sind aber in Textformat und einfach lesbar.
Nicht bei Quake Wars.

Der Artikel von ihm ist diesmal wirklich besser, nicht annähernd so reißerisch, sondern sachlich und zeigt auch Probleme auf =)

[deekey777]

In dem ganzen Artikel steht NICHTS drin.
Naja, die Sache mit den Bäumen fand ich schon interessant.
Andererseits haben die Entwickler das Ganze so gelöst:
Some screenshots show soft shadowing under the trees. Are you using shadow maps for this or the texture projection capability of DOOM 3? If the later, will these shadows still be compatible with dynamic day/night cycles?

As several people already deducted from our screenshots, the tree shadows aren’t actual shadows in that sense. They are projected textures using a special shader and a carefully setup projection. While we do end up with some double shadowing issues, they look really convincing as they interact with any light receiving object in the game.
http://www.beyond3d.com/content/interviews/11/2

Und genau darum geht's ja: Mag sein, dass es nicht so superdupergenau ist wie mit Ray-Tracing, aber Wayne? So lange es keinem auffällt und gut aussieht.

Andererseits ist es in erster Linie Forschung, nur hätte ich lieber kein ETQW ray-traced, sondern Crysis.

[Gast]

Andererseits ist es in erster Linie Forschung, nur hätte ich lieber kein ETQW ray-traced, sondern Crysis.
Wenn es für Crysis einen Linux port geben würde, hätten sie es villeicht auch gemacht.

[Coda]

Und genau darum geht's ja: Mag sein, dass es nicht so superdupergenau ist wie mit Ray-Tracing, aber Wayne? So lange es keinem auffällt und gut aussieht.
Im finalen Spiel waren es aber wieder Shadow Volumes - Und zwar nur vom Stamm und nicht von den Blättern.

Wenn es für Crysis einen Linux port geben würde, hätten sie es villeicht auch gemacht.
Da wär nicht nur Linux das Problem gewesen. Die QW-Engine ist um einiges einfacher.

[Gast]

Da wär nicht nur Linux das Problem gewesen. Die QW-Engine ist um einiges einfacher.
OpenGL ist auch um einiges flexibler als D3D und somit für die Raytracing Experimente bestens geeignet.