Abo
  1. Foren
  2. Kommentare
  3. Audio/Video
  4. Alle Kommentare zum Artikel
  5. › Nvidia-Interview: "Die Multi-GPUs…

oh doch, es gibt einen Grund... (Raytracing)

  1. Thema

Neues Thema Ansicht wechseln


  1. oh doch, es gibt einen Grund... (Raytracing)

    Autor: derSeher 17.04.08 - 15:33

    ...und der heißt Raytracing! In ein paar Jahren wird es vermutlich wieder die guten alten Framebuffer-Grafikkarten geben. Spezielle GPU's sind dann unnötig und reine Energie- und Geldverschwendung;-)

    Die pseudo 3D Grafik wird aussterben. Und damit vermutlich auch Nvidia irgendwann;-)

    Meine zwo Cent...

    Gruss,
    derSeher 8-)

  2. liesmich->

    Autor: derSeher 17.04.08 - 15:35

    Hier noch etwas Lektüre dazu:

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

  3. Raytracing vs. 3D

    Autor: GrakaKlaus 17.04.08 - 17:34

    derSeher schrieb:
    -------------------------------------------------------
    > ...und der heißt Raytracing! In ein paar Jahren
    > wird es vermutlich wieder die guten alten
    > Framebuffer-Grafikkarten geben. Spezielle GPU's
    > sind dann unnötig und reine Energie- und
    > Geldverschwendung;-)
    >
    > Die pseudo 3D Grafik wird aussterben. Und damit
    > vermutlich auch Nvidia irgendwann;-)
    >
    > Meine zwo Cent...
    >
    > Gruss,
    > derSeher 8-)

    Raytracing ist schön und gut in der Theorie, solange man sich da auch nur an der Oberfläche aufhält. Aber da muss erst mal eine Demo hin, die wenigstens die aktuelle Grafikpracht der GPUs zeigen kann. Zudem bewegt sich alles mehr dahin, dass immer mehr sich bewegt, deswegen ja auch die Physikengine, die irgendwelche durch die Luft fliegenden Teile berechnen soll. Je mehr sich aber alles bewegt desto rechenintensifer wird Raytracing. Rastericing zwar auch, aber eben nicht so stark wie Raytracing. Außerdem sind 3D-Spiele immer wieder im Gespräch. Zur Zeit braucht man noch eine Brille aber es soll ja jetzt auch Monitore geben, die keine Brille benötigen... Für 3-Dspiele brächte man noch mehr Leistung, bis das alles auf Raytracing läuft können die GPUs also noch ziemlich viel abgraßen und danach kann eine GPU mit ein wenig umbauten genau so RAytracing berechnen, da man dort genau so eine parallelarchitektur braucht. Cuda ist ja jetzt schon vorhanden, dann noch die Speichercaches etwas anderes auslegen, weil Raytracing sehr speicherhungrieg ist und schon hat man aus einer GPU ein Raytracer gemacht. Warum soll also da nVida verschwinden, wenn RAytracing gewinnen sollte?!


  4. Falsch!

    Autor: MarekP. 17.04.08 - 19:00

    Der Aufwand fürs Raytracing bleibt gleich Bewegung und Anzahl Objekte sind da ziemlich latte, denn die Anzahl der "Lichtstrahlen" bleibt gleich.
    Das ist ja gerade das tolle am Raytracing wenn es läuft ist die Komplexität der Szenerie egal.


    GrakaKlaus schrieb:
    -------------------------------------------------------
    > derSeher schrieb:
    > --------------------------------------------------
    > -----
    > > ...und der heißt Raytracing! In ein paar
    > Jahren
    > wird es vermutlich wieder die guten
    > alten
    > Framebuffer-Grafikkarten geben.
    > Spezielle GPU's
    > sind dann unnötig und reine
    > Energie- und
    > Geldverschwendung;-)
    >
    > Die pseudo 3D Grafik wird aussterben. Und
    > damit
    > vermutlich auch Nvidia
    > irgendwann;-)
    >
    > Meine zwo Cent...
    >
    > Gruss,
    > derSeher 8-)
    >
    > Raytracing ist schön und gut in der Theorie,
    > solange man sich da auch nur an der Oberfläche
    > aufhält. Aber da muss erst mal eine Demo hin, die
    > wenigstens die aktuelle Grafikpracht der GPUs
    > zeigen kann. Zudem bewegt sich alles mehr dahin,
    > dass immer mehr sich bewegt, deswegen ja auch die
    > Physikengine, die irgendwelche durch die Luft
    > fliegenden Teile berechnen soll. Je mehr sich aber
    > alles bewegt desto rechenintensifer wird
    > Raytracing. Rastericing zwar auch, aber eben nicht
    > so stark wie Raytracing. Außerdem sind 3D-Spiele
    > immer wieder im Gespräch. Zur Zeit braucht man
    > noch eine Brille aber es soll ja jetzt auch
    > Monitore geben, die keine Brille benötigen... Für
    > 3-Dspiele brächte man noch mehr Leistung, bis das
    > alles auf Raytracing läuft können die GPUs also
    > noch ziemlich viel abgraßen und danach kann eine
    > GPU mit ein wenig umbauten genau so RAytracing
    > berechnen, da man dort genau so eine
    > parallelarchitektur braucht. Cuda ist ja jetzt
    > schon vorhanden, dann noch die Speichercaches
    > etwas anderes auslegen, weil Raytracing sehr
    > speicherhungrieg ist und schon hat man aus einer
    > GPU ein Raytracer gemacht. Warum soll also da
    > nVida verschwinden, wenn RAytracing gewinnen
    > sollte?!
    >
    >


  5. Re: Raytracing vs. 3D

    Autor: Martin F. 17.04.08 - 19:14

    GrakaKlaus schrieb:
    -------------------------------------------------------
    > Raytracing ist schön und gut in der Theorie,
    > solange man sich da auch nur an der Oberfläche
    > aufhält. Aber da muss erst mal eine Demo hin, die
    > wenigstens die aktuelle Grafikpracht der GPUs
    > zeigen kann.

    Es gab doch so eine Quake-4-Demo?

    --
    Bitte prüfen Sie, ob Sie diesen Beitrag wirklich ausdrucken müssen!

  6. Re: Raytracing vs. 3D

    Autor: Grakaklaus 17.04.08 - 20:01

    Martin F. schrieb:
    -------------------------------------------------------
    > GrakaKlaus schrieb:
    > --------------------------------------------------
    > -----
    > > Raytracing ist schön und gut in der
    > Theorie,
    > solange man sich da auch nur an der
    > Oberfläche
    > aufhält. Aber da muss erst mal
    > eine Demo hin, die
    > wenigstens die aktuelle
    > Grafikpracht der GPUs
    > zeigen kann.
    >
    > Es gab doch so eine Quake-4-Demo?
    >
    > --
    > Freiheit stirbt mit Sicherheit.

    Ist Quake-4 ein aktuelle Grafikpracht? Ist doch schon 3 Jahre alt und sieht auch nicht toll aus. Zudem lief die Demo in einer Mikrigen Auflösung, so dass das noch miserabler aussah.

  7. Re: Falsch!

    Autor: GrakaKlaus 17.04.08 - 20:06

    MarekP. schrieb:
    -------------------------------------------------------
    > Der Aufwand fürs Raytracing bleibt gleich Bewegung
    > und Anzahl Objekte sind da ziemlich latte, denn
    > die Anzahl der "Lichtstrahlen" bleibt gleich.
    > Das ist ja gerade das tolle am Raytracing wenn es
    > läuft ist die Komplexität der Szenerie egal.
    >
    >

    Nix Falsch, du bist falsch und auf dem Holzweg. Es ist egal wie Komplex die Scene ist in Bezug auf Texturen etc. aber eben nicht in Bezug auf bewegte Objekte.

    nur wenn die ganze Sache statisch ist, gibt es auch die von Phol propagierte logharithmische Kurve. In Spielen, wo sich alles bewegt ist das aber ganz und gar nicht so.

    Zitat:

    Ralf Kornmann: Vergleicht man Raytracer und Rasterverfahren miteinander, skalieren beide linear mit der Anzahl der Dreiecke. Wobei der Aufwand pro Dreieck bei einem Rasterisierer kleiner ist, da hier nur die tatsächliche Größe berücksichtigt werden muss, während bei einem Raytracer immer die gesamte Zielauflösung zum Tragen kommt.

    Raytracer erreichen die gute logarithmische Skalierung nur bei einer vorsortierten statischen Dreiecksmenge, welche bei Spielen jedoch immer kleiner wird. Beim Rasterverfahren optimiert man die Skalierung durch das sogenannte "Culling". Dabei wird auf verschiedenen Detailstufen die weitere Berechnung vorzeitig abgebrochen.

    Aktuelle GPUs unterstützen dies auf Dreicksebene. Die Objektebene muss weiterhin von der CPU übernommen werden. Hier könnten zukünftige Chips noch weitere Verbesserungen bringen.


    Quelle:http://www.pcgameshardware.de/aid,638477/News/PCGH-Interview_Raytracing_vs_Rasterizing/

  8. Re: Falsch!

    Autor: _Michael_ 17.04.08 - 20:44

    GrakaKlaus schrieb:
    -------------------------------------------------------
    > MarekP. schrieb:
    > --------------------------------------------------
    > -----
    > > Der Aufwand fürs Raytracing bleibt gleich
    > Bewegung
    > und Anzahl Objekte sind da ziemlich
    > latte, denn
    > die Anzahl der "Lichtstrahlen"
    > bleibt gleich.
    > Das ist ja gerade das tolle
    > am Raytracing wenn es
    > läuft ist die
    > Komplexität der Szenerie egal.
    >
    > Nix Falsch, du bist falsch und auf dem Holzweg. Es
    > ist egal wie Komplex die Scene ist in Bezug auf
    > Texturen etc. aber eben nicht in Bezug auf bewegte
    > Objekte.
    >
    > nur wenn die ganze Sache statisch ist, gibt es
    > auch die von Phol propagierte logharithmische
    > Kurve. In Spielen, wo sich alles bewegt ist das
    > aber ganz und gar nicht so.
    >
    > Zitat:
    >
    > Ralf Kornmann: Vergleicht man Raytracer und
    > Rasterverfahren miteinander, skalieren beide
    > linear mit der Anzahl der Dreiecke. Wobei der
    > Aufwand pro Dreieck bei einem Rasterisierer
    > kleiner ist, da hier nur die tatsächliche Größe
    > berücksichtigt werden muss, während bei einem
    > Raytracer immer die gesamte Zielauflösung zum
    > Tragen kommt.
    >
    > Raytracer erreichen die gute logarithmische
    > Skalierung nur bei einer vorsortierten statischen
    > Dreiecksmenge, welche bei Spielen jedoch immer
    > kleiner wird. Beim Rasterverfahren optimiert man
    > die Skalierung durch das sogenannte "Culling".
    > Dabei wird auf verschiedenen Detailstufen die
    > weitere Berechnung vorzeitig abgebrochen.
    >
    > Aktuelle GPUs unterstützen dies auf Dreicksebene.
    > Die Objektebene muss weiterhin von der CPU
    > übernommen werden. Hier könnten zukünftige Chips
    > noch weitere Verbesserungen bringen.
    >
    > Quelle:www.pcgameshardware.de
    >

    Du hast vollkommen recht. Dieser Daniel Pohl hat, wenn man seine Artikel liest, nicht wirklich Ahnung und damit ganz schön was angerichtet. Nun glauben nämlich alle nachdem sie den Artikel gelesen haben, sie hätten Ahnung von Raytracing aber sie haben keine Ahnung von den dort eingesetzten Beschleunigungsstrukturen und deren Problem mit sich bewegenden Objekten. Es gibt natürlich welche damit besser zurrecht kommen aber, wenn sich wie bei Spielen, sehr sehr viel bewegt wirds schwieriger.
    Andere Probleme sind bspw. weiche Schatten, die mit Raytracing ein ganzes Stück aufwändiger sind als die Schatten mit harten Kanten, wie man sie in Quake4 Raytraced sieht.

    Ein paar aufschlussreiche Kommentare zum Computerbase Artikel:

    http://www.forum-3dcenter.de/vbulletin/showthread.php?t=407773

  9. Re: Falsch!

    Autor: knallivd 18.04.08 - 10:45

    Hallo

    > Nix Falsch, du bist falsch und auf dem Holzweg. Es
    > ist egal wie Komplex die Scene ist in Bezug auf
    > Texturen etc. aber eben nicht in Bezug auf bewegte
    > Objekte.

    Eben nicht. Daniel Pohl hat in dem zitierten Artikel auch die Lösung des Problems angegeben: Baumstrukturen, in welche die Szene einsortiert wird. Die Suche in so einem Baum hat logarithmische Komplexität. Damit kann man die Anzahl der Objekte, welche ein Sichtstrahl treffen könnte, deutlich reduzieren.

    > Ralf Kornmann: Vergleicht man Raytracer und
    > Rasterverfahren miteinander, skalieren beide
    > linear mit der Anzahl der Dreiecke. Wobei der

    Falsch. Ein Raytracer skaliert etwa linear mit der Anzahl der gesendeten Sichtstrahlen. Außerdem arbeitet ein Raytracer nicht mit Dreiecken, sondern mit konvexen Objekten. Man kann komplette Kugeln, Kegel oder Würfel darstellen, ohne sie vorher in Dreiecke zerlegen zu müssen. Die Objekte werden durch Baumstrukturen sortiert.

    Das Zeitaufwändige an der gebräuchlichen Dreiecksprojektion ist auch nicht die Anzahl der Dreiecke, sondern deren Erzeugung aus den Objekten und die spätere "Bearbeitung" durch Texturen und Spezialeffekte.

    > Aufwand pro Dreieck bei einem Rasterisierer
    > kleiner ist, da hier nur die tatsächliche Größe
    > berücksichtigt werden muss, während bei einem
    > Raytracer immer die gesamte Zielauflösung zum
    > Tragen kommt.

    Die Zielauflösung ist auch für einen heutigen Rasterer wichtig. Nur merkt man das nicht, da praktisch alle anderen Stufen der Grafikpipeline mehr Zeit benötigen.

    > Raytracer erreichen die gute logarithmische
    > Skalierung nur bei einer vorsortierten statischen
    > Dreiecksmenge, welche bei Spielen jedoch immer
    > kleiner wird. Beim Rasterverfahren optimiert man

    Falsch. Genau die selben Probleme gibt es mit Kollisionserkennung. Hier müssen die Objekte auch vorsortiert werden und die Sortierung muss immer aktuell gehalten werden, wenn sich ein Objekt bewegt. Diese Sortierung, Du ahnst es schon, findet durch die erwähnten Bäume statt. Diese Daten des Physiksimulators kann man im Raytracer direkt wieder verwenden.

    > die Skalierung durch das sogenannte "Culling".
    > Dabei wird auf verschiedenen Detailstufen die
    > weitere Berechnung vorzeitig abgebrochen.

    'Culling' erfolgt erst, wenn man schon Dreiecke in der Grafikkarte hat. Die übergeordneten Objekte müssen vorher trotzdem trianguliert werden.

    Was die Sache mit den Schatten angeht: Schau dir mal an, durch welche Reifen man springen muss, um heute ein paar Schatten und eine halbwegs realistische Beleuchtung zu erzeugen. Beim Raytracer bekommst Du das alles automatisch. Dagegen sind die scharfen Kanten der Schatten ein kleines Problem.

    Die heutige Grafik-Pipeline lässt sich halt gut in eine GPU mit SIMD-Architektur abbilden, deshalb lässt sie sich überhaupt so gut beschleunigen. Beim Raytracer geht das nicht, weshalb die CPU hier deutlich mehr Leistung liefern muss.

    -Thomas

  10. Halbwissen vs. Experte

    Autor: GrakaKlaus 18.04.08 - 15:10

    knallivd schrieb:
    -------------------------------------------------------
    > Hallo

    Hallo!
    So oft "falsch" geschrien und keine einzige Quelle. Ich mach mir jetzt sicher nicht die Mühe die Quellen zu suchen, die deine Behauptungen widerlegen. Vorgestellt hast du dich auch nicht. Ich weiß gar nicht, ob du überhaupt das Wissen hast um Ralf Kornmann zu widersprechen.

  11. Halbwissen vs. Experte

    Autor: Grakaklaus 18.04.08 - 15:37

    knallivd schrieb:
    -------------------------------------------------------
    > Hallo
    >
    > > Nix Falsch, du bist falsch und auf dem
    > Holzweg. Es
    > ist egal wie Komplex die Scene
    > ist in Bezug auf
    > Texturen etc. aber eben
    > nicht in Bezug auf bewegte
    > Objekte.
    >
    > Eben nicht. Daniel Pohl hat in dem zitierten
    > Artikel auch die Lösung des Problems angegeben:
    > Baumstrukturen, in welche die Szene einsortiert
    > wird. Die Suche in so einem Baum hat
    > logarithmische Komplexität. Damit kann man die
    > Anzahl der Objekte, welche ein Sichtstrahl treffen
    > könnte, deutlich reduzieren.
    >
    Eben doch. Wo bleibt der Beweis für deine eben nicht Behauptung? Ralf Kornmann hat die Baumstrukturgeschichte von Pohl auch gehört und dennoch widersprochen!

    > > Ralf Kornmann: Vergleicht man Raytracer
    > und
    > Rasterverfahren miteinander, skalieren
    > beide
    > linear mit der Anzahl der Dreiecke.
    > Wobei der
    >
    > Falsch. Ein Raytracer skaliert etwa linear mit der
    > Anzahl der gesendeten Sichtstrahlen. Außerdem
    > arbeitet ein Raytracer nicht mit Dreiecken,
    > sondern mit konvexen Objekten. Man kann komplette
    > Kugeln, Kegel oder Würfel darstellen, ohne sie
    > vorher in Dreiecke zerlegen zu müssen. Die Objekte
    > werden durch Baumstrukturen sortiert.
    >
    Man kann, aber Phol macht das ja nicht. Der ist immer noch bei Dreiecken von daher bist du falsch!

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

    Zitat von John Carmack:
    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.


    So ist das halt mit dem Halbwissen. Man hat mal was gehört und schon schreit man "Falsch" bevor man sich das ganze genau angeschaut hat. Weiter dein Halbwissen zu zerlegen hab ich aber nu wirklich keine Lust.

  12. Re: Halbwissen vs. Experte

    Autor: knallivd 19.04.08 - 21:05

    Hallo,

    ich kann leider meine Antwort nicht posten, da sie angeblich Spam enthält. Ich habe die Redaktion kontaktiert, um das Problem zu beheben. Die gewünschten Quellen werden hoffentlich bald hier erscheinen.

    -Thomas

  13. Fehlende Quellen

    Autor: knallivd 21.04.08 - 19:00

    Hallo,

    hab die Spam-Warnung behoben. Hier also die Quellen.

    "Halbwissen vs. Experte"

    So würde ich das nicht formulieren, aber deine Forderung nach Quellen ist natürlich berechtigt.

    Ich hab meinen Bücherschrank durchwühlt und einige Literatur zum Thema gefunden. Los geht's:

    Ein Standardwerk über Grafik ist "Computer Graphics" [1] von James Foley, u.a. . Das Buch ist schon älter, aber immer noch lesenswert, da es Unmengen an Grundlagen enthält. hie findest Du vor allem eine exemplarische Grafik-Pipeline, grundlegende Algorithmen(Kapitel 3,15+19), Beleuchtung und Schattierung (Kapitel 13) und die Grundlagen der linearen Algebra (Kapitel 5+6, Anhang), welche für die Projektion der Dreiecke benötigt wird.

    Falls Du etwas praktisch orientiertes suchst, empfehle ich dir "The OpenGL Programming Guide" [2] von Dave Shreiner, u.a., auch bekannt als "Red Book". Das Buch enthält eine Übersicht über die Stufen der OpenGL-Pipeline und detaillierte Informationen, wie man diese programmiert. Der Verweis führt auf eine ältere Ausgabe, da die aktuelle nicht besitze.

    Schatten werden heute meist durch Shadow Mapping, wobei man für eine Lichtquelle eine Texture aus Tiefeninformationen berechnet und diese dann in die Szene projeziert. NVIDIA hat ein interessantes Paper [3] dazu. Gebräuchlich sind auch Shadow Volumes. Dabei schickt man Strahlen von der Lichtquelle in die Szene und "schneidet" den unbeleuchteten Bereich aus. Nochmal NVIDIA [4].

    Für Raytracing kann ich Dir leider keine konkrete Buchempfehlung geben. Soweit ich weis, soll [5] ganz gut sein. Die Grundlagen aus "Computer Graphics" gelten aber weitest gehend auch für Raytracer.

    Die Sortierung von Daten durch hierarchische Strukturen ist Allgemeingut. Ein beliebiges Buch über Datenstrukturen verrät dir die Details. Für 3D-Szenen sind Bsp-, Quad- und Oct-Trees typisch, andere Bäume sind meist Varianten dieser. Es gibt eine FAQ [6] zu BSP-Trees. dort erfährst Du, wie sowas funktioniert.

    Ein Raytracer schneidet Strahlen mit Objekten. Diesen Strahl kannst Du direkt in den Physiksimulator eingeben und erhälst den Schnittpunkt. Der Raytracer ist sozusagen die "graphische Ausgabe" des Physiksimulators. Hier möchte ich Dich an die Open Dynamics Engine [7] verweisen, einen freien Rigid-Body-Simulator mit Kollisionserkennung/-behandlung. Wahrscheinlich kennst Du das Programm schon. Dort findest Du das beschriebene Konzept. Ich finde den Quelltext etwas unübersichtlich, aber er enthält die Strahl-Objekt-Schnitte für verschiedene Objekttypen und eine hierarchische Datenstruktur, welche die Szene vorsortiert. Das Programm ist nicht nur Proof-Of-Concept sondern wird auch häufig eingesetzt.

    Um einen Physiksimulator zu verstehen, solltest Du wissen, wie ein Rigid-Body-Simulator funktioniert und wie man den Abstand zwischen konvexen Objekten bestimmt.

    Das beste Online-Tutorium zum Thema Rigid-Body-Simulator ist [8] von David Baraff. Dort erfährt Du alles über die Bewegung und Drehung von Objekten.

    Der verbreitete Algorithmus zur Bestimmung des Abstandes zwischen zwei konvexen Objekten ist der GJK-Algorithmus von Gilbert, Johnson und Keerthi. Ich weiß nicht genau, ob man das Original-Paper [9] auch online bekommt. Es ist allerdings schon recht alt und bezieht sich meines Wissens nur auf Polyeder. Das heute gebräuchliche Paper ist [10] von Gino van den Bergen. Dieses Paper zeigt Dir, wie man den GJK-Algorithmus auf beliebige konvexe Objekte erweitern kann und wie man einige unschöne Grenzfälle behandelt, welche im Original zu Problemen führen.

    Der Strahl-Objekt-Test basiert nicht auf GJK. Dazu gibt's für jeden Objekt-Typ eine eigene Funktion. Das geht dann analytisch.

    Ich denke mal, ich hab mein erstes Posting mit Quellen abgedeckt. Soviel zum Thema "Halbwissen".

    Nachdem ich mir die Mühe gemacht habe, die Sache zusammenzustellen, möchte ich nun Dich bitten, Belege für die Aussagen von Ralf Kornmann anzugeben. Deine "Quelle", PC Games Hardware, ist leider unbrauchbar. Sie enthält keine Argumentionen oder Verweise auf andere Quellen. Dir scheint auch nicht aufgefallen zu sein, dass es sich gar nicht um eine Diskussion handelt. Es wurden einfach einige Fragen gestellt und beide Befragten geben jeweils ein Statement ab. Sie gehen nicht auf einander ein, noch gehen die Fragen auf die vorherigen Antworten ein. Wahrscheinlich hat die Redaktion den beiden die Fragen per Email gesendet und sie haben per Email geantwortet. Das ist heutzutage nicht unüblich.

    John Carmack hat natürlich eine Meinung zu dem Thema, aber er ist nicht der Einzige. Es gibt zur Zeit einige Diskussion, wie man die Multicore-CPUs am Besten baut. Eine Fraktion möchte CPUs mit viele generischen Cores. Die andere Fraktion möchte CPUs mit wenigen generischen und dafür einigen spezialisierten Cores. Eine Zusammenfassung findest Du unter [11].

    -Thomas

    [1] James Foley et al. Computer Graphics: Principles and Practice, 2. Auflage, Addison-Wesley Longman 1995, ISBN 0201848406

    [2] Dave Shreiner, et al. OpenGL Programming Guide: The Official Guide to Learning OpenGL 1.2, 3.Auflage, Addison-Wesley Longman 2006, ISBN 0201604582

    [3] Cass Everit et al. Hardware Shadow Mapping, http://developer.nvidia.com/attach/8456

    [4] Morgan McGuire et al. Fast Practical and Robust Shadows, http://developer.nvidia.com/attach/6432

    [5] Andrew S. Glassner. An Introduction to Raytracing, Morgan Kaufman Publishers 1989, ISBN 0122861604

    [6] Binary Space Partitioning Trees FAQ, http://www.faqs.org/faqs/graphics/bsptree-faq/

    [7] Open Dynamics Engine, http://www.ode.org

    [8] Physically Based Modeling: Principles and Practice,
    http://www <dot> cs <dot> cmu <dot> edu/~baraff/sigcourse/
    (etwas verändert, wegen der Spam-Warnung)

    [9] E. G. Gilbert, D. W. Johnson, and S. S. Keerthi. A fast procedure for comput
    ing the distance between complex objects in three-dimensional space. IEEE
    Journal of Robotics and Automation, 4(2):193–203, 1988.

    [10] Gino von den Bergen. A Fast and Robust Implementation for Collision Detection of Convex Objects. http://www.win.tue.nl/~gino/solid/jgt98convex.pdf

    [11] Nightmare On Core Street. http://rebelscience.blogspot.com/2008/03/nightmare-on-core-street.html

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. XION GmbH, Berlin
  2. Wirecard Acceptance Technologies GmbH, Aschheim bei München
  3. Julius-Maximilians-Universität Würzburg, Würzburg
  4. SEG Automotive Germany GmbH, Stuttgart-Weilimdorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. For Honor für 11,50€, Anno 1404 Königsedition für 3,74€, Anno 2070 Königsedition...
  2. (aktuell u. a. Cryorig Gehäuselüfter ab 7,49€, Sandisk Ultra 400-GB-microSDXC für 59,90€)
  3. (u. a. Total war - Three Kingdoms für 35,99€, Command & Conquer - The Ultimate Collection für 4...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ryzen 3900X/3700X im Test: AMDs 7-nm-CPUs lassen Intel hinter sich
Ryzen 3900X/3700X im Test
AMDs 7-nm-CPUs lassen Intel hinter sich

Das beste Prozessor-Design seit dem Athlon 64: Mit den Ryzen 3000 alias Matisse bringt AMD sehr leistungsstarke und Energie-effiziente CPUs zu niedrigen Preisen in den Handel. Obendrein laufen die auch auf zwei Jahre alten sowie günstigen Platinen mit schnellem DDR4-Speicher.
Ein Test von Marc Sauter

  1. Ryzen 3000 BIOS-Updates schalten PCIe Gen4 für ältere Boards frei
  2. Mehr Performance Windows 10 v1903 hat besseren Ryzen-Scheduler
  3. Picasso für Sockel AM4 AMD verlötet Ryzen 3400G für flottere iGPU

Wizards Unite im Test: Harry Potter Go mit Startschwierigkeiten
Wizards Unite im Test
Harry Potter Go mit Startschwierigkeiten

Der ganz große Erfolg ist das in der Welt von Harry Potter angesiedelte Wizards Unite bislang nicht. Das dürfte mit dem etwas zähen Einstieg zusammenhängen - Muggel mit Durchhaltevermögen werden auf den Straßen dieser Welt aber durchaus mit Spielspaß belohnt.
Von Peter Steinlechner

  1. Pokémon Go mit Harry Potter Magische Handy-Jagd auf Dementoren

LEDs: Schlimmes Flimmern
LEDs
Schlimmes Flimmern

LED-Licht zu Hause oder im Auto leuchtet nur selten völlig konstant. Je nach Frequenz und Intensität kann das Flimmern der Leuchtmittel problematisch sein, für manche Menschen sogar gesundheitsschädlich.
Von Wolfgang Messer

  1. Wissenschaft Schadet LED-Licht unseren Augen?
  2. Straßenbeleuchtung Detroit kämpft mit LED-Ausfällen und der Hersteller schweigt
  3. ULED Ubiquitis Netzwerkleuchten bieten Wechselstromversorgung

  1. Qualcomm: Snapdragon 855 Plus hat ein Plusschen mehr Takt
    Qualcomm
    Snapdragon 855 Plus hat ein Plusschen mehr Takt

    Im zweiten Halbjahr sollen erste Smartphones wie das ROG Phone 2 von Asus mit dem Snapdragon 855 Plus erscheinen: Qualcomm verspricht mehr Takt bei den CPU-Kernen und eine schnellere Adreno-Grafikeinheit.

  2. Epic Games Store: Cloud-Saves, Mods und Zombies kommen
    Epic Games Store
    Cloud-Saves, Mods und Zombies kommen

    Verbesserungen beim Offlinemodus, dazu Speicherstände in der Cloud und etwas später Nutzerbewertungen: Epic Games hat die Pläne für seinen Epic Games Store aktualisiert. Und es gibt ein Spiel von einem Entwickler exklusiv, der bis vor kurzem noch vehement gegen solche Deals war.

  3. Remix3D: Microsoft schließt seine 3D-Modell-Datenbank komplett
    Remix3D
    Microsoft schließt seine 3D-Modell-Datenbank komplett

    Am 10. Januar 2020 ist Schluss: Microsoft wird seine Plattform Remix3D schließen. Dort konnten Mitglieder ihre 3D-Modelle teilen und diese für Powerpoint, Virtual Reality oder Minecraft benutzen. Das Unternehmen empfiehlt, beliebte Modelle vor dem Ende herunterzuladen - dann werden sie gelöscht.


  1. 17:07

  2. 17:02

  3. 15:07

  4. 14:52

  5. 14:37

  6. 14:20

  7. 14:02

  8. 13:47