1. Foren
  2. Kommentare
  3. PC-Hardware-Forum
  4. Alle Kommentare zum Artikel
  5. › Video: Quake Wars Raytraced…
  6. Thema

ruckelt!

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


  1. Re: ruckelt!

    Autor: Sonic77 27.06.09 - 17:50

    lowbrainer schrieb:
    -------------------------------------------------------
    > also wofür?!
    >
    > wie wärs mit CUDA? oder das ding von AMD?
    >
    > aktuelle GPUs ownen doch aktuelle CPUs - oder bin
    > ich eingeschlafen?!

    Nein, Intel will einfach nicht wahrhaben, daß ihre CPUs von GPUs geownd werden.

    Raytracing wird die Rasterisierung im Echtzeitbereich niemals ablösen. Schon heute können GPUs für einzelne Spezialeffekte selbst raytracen.

  2. Re: wofür

    Autor: Blair 27.06.09 - 18:07

    sorry, aber spiele mit bildern zu vergleichen ist absolut irrführend. die bilder sehen vor allem deswegen so gut aus, weil sie extrem viele polygone haben (keine kanten), sehr feine texturen und extrem viele details. das alles kann man auch rasterisierung machen, wobei es in computerspielen völlig unrealistisch ist, überall so extrem viele details einzubauen, da der personalaufwand gigantisch wäre. an einer einzigen szene dieser bilder sitzen die bearbeiter oft 50 stunden ode noch mehr. damit ein computerspiel die selbe qualität wie die bilder erreichen würde, bäuchte man hunderte oder tausende entwickler.

    der qualitätative vorteil von raytracing sind beispielsweise realistische spiegelungen und licheffekte. doch moderne directx10-engines kriegen das mittlerweile auch so gut hin, dass die unterschiede minimal sein dürften.

    also die qualität dürfte es weniger sein. eher andere gründe, wie der offenbar niedrigere programmieraufwand. oder die bessere sklarierung. irgendwann, ab einer bestimmten rechenleistung, soll raytracing sogar performanter sein als rasterisierung.

    dafür gibts es wohl andere probleme....
    ich bin gespannt ob aus der voxel-raycasting-technik von ID noch irgendwas wird.

  3. Re: ruckelt!

    Autor: Blair 27.06.09 - 18:09

    Sonic77 schrieb:
    -------------------------------------------------------
    > lowbrainer schrieb:
    > --------------------------------------------------
    > -----
    > > also wofür?!
    >
    > wie wärs mit CUDA?
    > oder das ding von AMD?
    >
    > aktuelle GPUs
    > ownen doch aktuelle CPUs - oder bin
    > ich
    > eingeschlafen?!
    >
    > Nein, Intel will einfach nicht wahrhaben, daß ihre
    > CPUs von GPUs geownd werden.

    gibt aber noch keine spezielle hardware dafür. das soll sich mit larrabee ändern. ich denke schon sie wissen was sie da tun.



    > Raytracing wird die Rasterisierung im
    > Echtzeitbereich niemals ablösen. Schon heute
    > können GPUs für einzelne Spezialeffekte selbst
    > raytracen.

    hä? was hat das eine mit dem anderen zu tun?

  4. Re: NEIN, GPU ist schneller....

    Autor: whiteambit 27.06.09 - 19:38

    Ganz einfach, intel entwickelt den Larabee nicht für RT. RT ist lediglich eine beispiel killerapp die überhaupt etwas mit so vielen Cores anfangen kann. Und da RT sehr gut mit der Zahl der Cores skaliert hat man tolle benchmark werte. Zudem wird Larabee warscheinlich wesentlich komplexere intsruktionssets inclusive Stack etc. haben. Ausserdem könnte es beim Larabee gerade für RT tatsächlich sehr gut aussehen, da er ansatzweise die hohe rechenleistung einer GPU mit der "voraussicht" (bei Verzweigungen etc.) einer CPU verbinden kann.

    Aber momentan hängen GPUs die vorhandenen CPUs auch noch bei RT ab. Bei Problemen die sich nicht so gut auf viele minicores verteilen ist aber immer noch die CPU weit vorne! GPUs können schnell rechnen, CPUs schnell programmverzweigungen verfolgen (das hat erstmal fast nichts mit der rechenleistung in FLOPS zu tun...)

  5. Re: NEIN, GPU ist schneller....

    Autor: Blair 27.06.09 - 22:44

    whiteambit schrieb:
    -------------------------------------------------------

    > Ausserdem könnte es beim Larabee gerade für RT
    > tatsächlich sehr gut aussehen, da er ansatzweise
    > die hohe rechenleistung einer GPU mit der
    > "voraussicht" (bei Verzweigungen etc.) einer CPU
    > verbinden kann.
    >
    > Aber momentan hängen GPUs die vorhandenen CPUs
    > auch noch bei RT ab.

    noch? die vorsprünge der gpus scheinen ja ganz erheblich zu sein. kann mir nun nicht mehr recht vorstellen, dass mit rasterisierung die gpu-grafikkarten sterben würden, wie es schon einige male bei larrabee-meldungen angedeutet wurde.

    dass larrabee eigentlich für andere zwecke gedacht ist, klingt einleuchtend.

  6. Re: NEIN, GPU ist schneller....

    Autor: whiteambit 27.06.09 - 23:39

    CPU und GPU konvergieren mit Larabee ein wenig. Sowohl CPU und GPU sind auch heutzutage beide sowohl bei Rasterisierung als auch bei Raytracing eigentlich sehr gut. Mit dem nächsten DirectX soll ja auch wieder ein guter SoftwareCPUEmulations renderer kommen. Wer weiss wie gut der z.B. auf Larabee läuft, wenn sie wirklich einen x86 befehlssatz einbauen. Und bei den GPUs wird wohl MIMD die grosse nummer sein.


    Und: Wenn man so will ist Scanline sowieso nur eine Optimierung für die Primärstrahlen eines Raytracers. Ein sehr gute Optimierung die die nächsten Jahre nicht übertroffen wird von "anderen" Raytracing Algorithmen die pro Pixel ablaufen. Lustigerweise ist eine der ersten Optimierungen man bei RT aufgrund von SSE befehlen findet wieder kleine Strahlenbündel loszuschicken ;) Bei entsprechend hoher Polygonzahl und kleiner Pixelzahl kippt halt die Scanline Optimierung - nichts weiter. Bei meinem GPU Raytracer liegt das etwa bei "ganz winzig" also vielleicht 10x10 Pixel mit z.B. 100K Polygonen. Mehr Polygone wird man auch im Raytracer nicht vorfinden, da auch der ein intelligentes LOD benutzen sollte. Bleibt z.B. noch der Fall einer "Spiegelung" - der Screen ist 1x1 Pixel, also innerhalb des "break even points" von 10x20 Pixel. Deshalb nimmt man für sowas RT :) Wenn du GI machen willst müsstest du aber 256 oder mehr Strahlen losschicken, die dir ein Bild von der Umgebung zu machen, ein RT Strahl gibt ja nur den einen exakten Punkt der Reflektion. Doch da es so viele Strahlen sind, ist wieder ein Scanliner der dir alle 100K Polygone einfach aufmalt schneller. Aber weil auch der noch zu langsam ist nimmt man gefaktes Scanline. Da man die Umgebung nur Grob erfassen möchte ist das aber OK. Sowas nennt sich dann Imperfect-Shadow-Maps. Also Praktisch das genaue gegenteil von Raytracing.

    http://www.youtube.com/watch?v=Pdp3rfyFF14

  7. Re: NEIN, GPU ist schneller....

    Autor: Ach 28.06.09 - 11:39

    Ja, ich kann mir denken dass bei Spielen Texturen mehrfach Verwendung finden(Speicher/Performance). Trotzdem ist dieses Verfahren ja immer noch weit speicherschonender als vorberechnete Texturen. Außerdem reagiert die Textur doch dynamisch auf ihre Umwelt(bitte sag mir jetzt nicht dass das nicht geht)!

    Vor 5 bis 7 Jahren hätten dieses Verfahren im Visualisierungsbereich eingeschlagen wie eine Bombe. Da hätte man sich die Finger geleckt nach einer so trickreichen Möglichkeit die aufwendige GI-Berechnung zu überspringen.

    Und selbst heute erstellt man Animationen auch im professionellem Bereich in der Regel auf Scanline Basis(mit unzähligen lichtern bzw. Light Dome), da sich GI-Bilder für eine flüssige Animation zu sehr von einander unterscheiden(ich sag nur Monte Carlo :)).
    Da wünsche ich mir doch, dass diese Idee bald mal auf 3Dmax runterregnet. Ich könnte sowas gut gebrauchen. Wenn es sowas gäbe wie eine Nobellpreis für 3D-Frickler, die Jungs hätten in sich verdiehnt :).

    Ich könnte mir auch vorstellen, dass sich diese Texturen in kommenden Spieletitteln bemerkbar machen. Dank Dx9 geht das ja auch auf Konsole.

  8. Re: ruckelt!

    Autor: c & c 28.06.09 - 12:34

    Hat er denn was anderes bahauptet? -.-

  9. Re: NEIN, GPU ist schneller....

    Autor: lalalala 28.06.09 - 20:10

    Naja das verfahren gibt es eigentlich schon sehr lange. Rate mal wieso du z.B. bei OpenGL den Normalvector selbst angeben sollst und der nicht einfach ausgerechnet wird. Speicherschonender als vorberechnete Texturen ist es nicht, aber die währen ja auch nicht Dynamisch. Und Wenn du sowieso schon eine Bumpmap hast kannst du die dazu benutzen, du müsstest eventuell nichtmal den Shader austauschen ;)

  10. Re: NEIN, GPU ist schneller....

    Autor: Tja, Open GL 29.06.09 - 00:11

    Gut, bei Spielen mag das sein. Leider hat man unter den Materialeinstellungen in Max aber keine direkte Kontrolle über die Richtung der Bumpmap. Die ist wohl fest mit der Cammera verdrahtet. Vielleicht hätte ich mehr Glück, wenn ich mir die Scriptsprache von Max etwas näher betrachten würde(die ist ziemlich mächtig), aber na ja, das währe etwas weit ab von meinem eigentlichen Schwerpunkt. Und davor eine Nachführung des Bumpmapvectors nach dem Mittel der Beleuchtung zu programmieren, davor hab ich erlich gesagt, schon einen spürbaren Respekt :). Ich hoffe halt, dass irgendein Plugin vorbei kommt und mich rettet, wobei ich auch gleich mal nachschauen könnte, jetzt wo ich weis wonach ich suche.

    Ich weis dass ME eine modifizierte Unreal Engine ist. Wenn man auf sowas zugreifen könnte, in etwa so wie auf die UT Engine, dann könnte ich fast schon schwach werden und versuchen meinen Animationskram in die Spiele Engine zu portieren.

    Jedenfalls vielen Dank für die Infos. Ich muss jetzt erst mal weiterfrickeln. Grüsse von Mir und viel Erfolg! Und lasst mal wieder von euch hören, dass ist nähmlich hochinteressant!

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Network / Security Engineer (m/w/d)
    HCD Consulting GmbH, München
  2. Fachinformatiker (m/w/d) für Systemintegration zur IT-Administration an den landkreiseigenen ... (m/w/d)
    Landratsamt Schweinfurt, Schweinfurt
  3. IT Solutions Architect S / 4HANA - Technical Innovation (m/w/d)
    Schaeffler Technologies AG & Co. KG, Nürnberg
  4. Software Consultant/IT Project Manager (m/w/d)
    ecovium GmbH, Neustadt, Düsseldorf, Pforzheim (Home-Office möglich)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Ryzen 5 5600X 358,03€)


Haben wir etwas übersehen?

E-Mail an news@golem.de