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: NEIN, GPU ist schneller....

    Autor: coder 26.06.09 - 19:46

    ich auch schrieb:
    -------------------------------------------------------
    > Primärstrahlen sind uninterressant, Scanline
    > gewinnt hier!

    Geb ich Dir Recht. Aber schnelle Primärstrahlen sind die Vorraussetzung, wenn man nicht Hybrid machen will.

    > Wie sieht es mit den
    > Sekundärstrahlen aus? Wiviele FPS schaffst du da
    > bei 500K Auflösung und einem 100K Model wenn die
    > Primärstrahlen auseinanderlaufen? Und vor allem wo
    > ist mal ein Link mit ein paar Bildern und
    > Benchmarks, oder gar eine ausführbare demo?

    Wie schnell Sekundärstrahlen sind hängt einzig davon ab wie komplex die Szene ist, durch die sie sich bewegen. In seiner Szene gibt es keine Umgebung die sich spiegeln könnte, nur das Modell selbst, also sollte das recht schnell gehen.
    Da ich immernoch am experimentieren bin hab ich momentan keine optimierte Version die Reflektionen kann. Und bei den Versionen die Fresnel Reflektionen, Refraction + Beer's Law, adaptive soft shadows usw. haben laufen mangels Optimierung schon die Primärstrahlen zu langsam um etwas zu reißen.

    Wenn du ne Demo sehen willst, dann schau dir eine von jemandem an der alles auf neuestem Stand und zusammengefügt hat. Wie z. B. hier: http://igad.nhtv.nl/~bikker/
    ansonsten sieh dich mal in diesem Forum um:
    http://ompf.org/forum/
    Und das hier könnte vielleicht interessant werden:
    http://www.gamedev.net/community/forums/topic.asp?topic_id=539098
    Ich hab letztes Jahr? von sngan ne demo auf dem Rechner gehabt, und die war da schon verdammt schnell.

    > PPS: Wie implementierst du ein MegaPartikelsystem
    > als Raytracer ;)

    Die Partikel auf ner Grafikkarte sind fürn Arsch, da dabei ein Volumeneffekt mit einzelnen 2d Bildchen simuliert wird, was zu 'wunderhübschen' clipping Fehlern und und ähnlichen Schwierigkeiten führt. Warum sollte man das überhaupt im Raytracing haben wollen?
    Für massive Effekte besser direkt raymarching für den Bereich einsetzen.
    Wenn du es allerdings unbedingt möchtest, dann kannst du natürlich die Partikel als Kugeln implementieren und sehr effizient rendern, da nur die Partikle gerendert werden, die auch tatsächlich in irgendeiner Form sichtbar sind.


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

    Autor: Ach 26.06.09 - 20:05

    Oha,
    Nun gut, du sprichst also nicht von dem eigentlichem Rendering, sondern von der Reduktion der Berechnung auf die Renderpfade, die schließlich überhaupt sichtbar werden. Ist das so gemeint?
    Die Sache mit dem "sparse-voxel-octrees" ist aber jetzt doch ein ganz anderer Film. Damit meinst du sicher das Voxelverfahren wie es etwa John Carmack bevorzugt?

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

    Autor: whiteambit 26.06.09 - 20:30

    coder schrieb:
    -------------------------------------------------------
    > ich auch schrieb:
    > --------------------------------------------------
    > -----
    > > Primärstrahlen sind uninterressant,
    > Scanline
    > gewinnt hier!
    >
    > Geb ich Dir Recht. Aber schnelle Primärstrahlen
    > sind die Vorraussetzung, wenn man nicht Hybrid
    > machen will.

    Und wieso sollte man nicht Hybrid machen wollen. Scanline ist IMO die beste optimierung für Primärstrahlen eines Raytracers die in den nächsten 10 Jahren kommen wird ;)

    > Wie schnell Sekundärstrahlen sind hängt einzig
    > davon ab wie komplex die Szene ist, durch die sie
    > sich bewegen. In seiner Szene gibt es keine
    > Umgebung die sich spiegeln könnte, nur das Modell
    > selbst, also sollte das recht schnell gehen.

    Das ist relativ egal für die Performance. Es ist ein 100K Model, was wohl mehr sein dürfte als die meisten Szenen in Arauna bei deinem ersten Beispiel. Leider gibt es da keine Benchmarks (oder ich finde sie nicht), aber der FPS counter der manchmal zu sehen ist zeigt selten mehr als 8. Und da reflektieren nur Spheres. Ausserdem scheinen Sie auch stark Hybridtechniken anzuwenden. Die ImperfectShadowMaps sind z.B. eigentlich klar dem Scanline ansatz zuzuordnen...

    > Da ich immernoch am experimentieren bin hab ich
    > momentan keine optimierte Version die Reflektionen
    > kann. Und bei den Versionen die Fresnel
    > Reflektionen, Refraction + Beer's Law, adaptive
    > soft shadows usw. haben laufen mangels Optimierung
    > schon die Primärstrahlen zu langsam um etwas zu
    > reißen.

    Guckst du. Da mein Ansatz deferred Shading unterstützt ist sowas alles kein Performance einbruch...

    > Wenn du ne Demo sehen willst, dann schau dir eine
    > von jemandem an der alles auf neuestem Stand und
    > zusammengefügt hat. Wie z. B. hier: igad.nhtv.nl
    > ansonsten sieh dich mal in diesem Forum um:
    > ompf.org
    > Und das hier könnte vielleicht interessant
    > werden:
    > www.gamedev.net
    > Ich hab letztes Jahr? von sngan ne demo auf dem
    > Rechner gehabt, und die war da schon verdammt
    > schnell.

    Welche auflösung und wieviel FPS, und bitte keine Primärstrahlen, da gewinnt Scanline sowieso, weil es genaugenommen auch nur eine Optimierung für die Primärstrahlen eines RT ist wenn man so will...

    > > PPS: Wie implementierst du ein
    > MegaPartikelsystem
    > als Raytracer ;)
    >
    > Die Partikel auf ner Grafikkarte sind fürn Arsch,
    > da dabei ein Volumeneffekt mit einzelnen 2d
    > Bildchen simuliert wird, was zu 'wunderhübschen'
    > clipping Fehlern und und ähnlichen Schwierigkeiten
    > führt.

    Oh man, du darfst nicht vergessen das Scanline auch fortschritte macht. Es gibt auch volumetirsche Partikel und die sind kaum langsamer haben aber nicht die clippingfehler...

    > Warum sollte man das überhaupt im
    > Raytracing haben wollen?
    > Für massive Effekte besser direkt raymarching für
    > den Bereich einsetzen.
    > Wenn du es allerdings unbedingt möchtest, dann
    > kannst du natürlich die Partikel als Kugeln
    > implementieren und sehr effizient rendern, da nur
    > die Partikle gerendert werden, die auch
    > tatsächlich in irgendeiner Form sichtbar sind.

    Was du vergisst ist das es Praktisch unmöglich sein dürfte eine Beschleunigungsstruktur fürs RT bei derartigen Systemen performant genug für echtzeit zu bekommen...

    Danke für die Links, aber bisher konnte ich kein beispiel sehen wo die Leistung auch nur nah herankommt. Die interaktive auflösung wird mit 512x384 für einen DualCore angegeben - also vielleicht 10fps. Auf dieser Auflösung steigt die Leistung auf einer GTX260 auf 50-150fps an. Und die Szene ist auch noch komplexer...

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

    Autor: whiteambit 26.06.09 - 20:31

    Ach schrieb:
    -------------------------------------------------------
    > Oha,
    > Nun gut, du sprichst also nicht von dem
    > eigentlichem Rendering, sondern von der Reduktion
    > der Berechnung auf die Renderpfade, die
    > schließlich überhaupt sichtbar werden. Ist das so
    > gemeint?

    Wenn du so willst macht RT occlusion culling per pixel...

    > Die Sache mit dem "sparse-voxel-octrees" ist aber
    > jetzt doch ein ganz anderer Film. Damit meinst du
    > sicher das Voxelverfahren wie es etwa John Carmack
    > bevorzugt?

    Naja, du hörst einfach beim RT bei deinem Blatt auf und machst die Blätter klein. Soooo anders ist das nicht...

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

    Autor: Ach 26.06.09 - 20:44

    > occlusion culling per pixel...
    Einen Test, nehme ich an?

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

    Autor: ich auch 26.06.09 - 20:49

    Sagen wir mal du hast einen KD-Tree, dann macht man das so

    für jeden pixel:
    0. gehe zur baumwurzel,
    1. gucke ob der strahl zuerst den linken oder rechten teilbaum durchläuft
    2. wenn du nicht im blatt bist gehe zu 1.,
    sonst teste gegen die übrig bleibende geometrie.

    würde man jeden strahl gegen alle primitive (dreiecke) testen, hättest du du bei 1mio primitiven viel zu tun...

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

    Autor: coder 26.06.09 - 21:16

    Da ham wir das Problem. Es ist unheimlich schwer zwei unterschiedliche Szenen zu vergleichen.

    Wirklich inkohärent werden reflektierte Strahlen erst wenn sie sich von dem Punkt der Reflektion entfernen. Da sie bei dir aber nur mit dem Modell selbst kollidieren können, sind sie nicht viel problematicher als es shadow rays wären. Des weiteren ist dein shading absolut minimal.
    In Arauna dagegen befindest du dich innerhalb einer Umgebung mit mehreren Lichtquellen vergleichsweise komplexem shading, wo Reflektionen auch die Umgebung um dich herum zeigen.
    Unter projects auf der Arauna Seite findest du zwei 'Spiele', bei denen die Level aus millionen von Dreiecken bestehen.

    Poste doch einfach mal deinen Raytracer im ompf-Forum, und fordere die Leute da heraus das gleiche schneller auf ner CPU zu machen. Ich bin selber gespannt auf den direkten Vergleich, und werd mich vielleicht beteiligen, wenn es die Zeit zulässt (und die anderen nicht so schnell sind, daß ich mich zu sehr blamieren würde :)


    Alles was momentan an realtime raytracern zu sehen ist, ist sowieso nichts halbes und nichts ganzes. Die Geschwindigkeit reicht gerade so um eine komplexe Szene mit Primärstrahlen + ein paar einfache extras in Echtzeit darzustellen. Dabei bekommt Raytracing erst mit massiv Sekundärstrahlen einen Vorteil über Rasterizing. Dann sind die Primärstrahlen aber unbedeutend im Vergleich zur Gesamtrenderzeit. Darum macht Hybrid eigentlich nur Sinn solange Raytracing mangels performance eigentlich noch keinen Sinn macht, und man lieber ganz bei Rasterizing bleiben sollte. :)

    Und zum Thema volumetrische Partikel: selbst in den aktuellsten und hochgelobten AAA-Titeln findest du immer noch diese netten clipping Fehler von den flachen Partikeln. Das mit den Fortschritten lässt für meinen Geschmack etwas zu Wünschen übrig...

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

    Autor: Einleuchtend 26.06.09 - 21:19

    Da steckt also die "Intelligenz". Zu Versuchen den Zufall auszuschalten. Der Aufwand den man betreibt um das genaue Gegenteil einer Brute Force Berechnung zu erhalten.


    Noch eine Frage:

    Dann kann RT also auch nicht viel gemein haben, mit dem was Monte Carlo Renderer so machen, sprich: Teststrahlen in den Raum schicken, die Ergebnisse zu einem Lichtplan zusammenfügen um die Szene mit neuen, aus dem Lichtplan entnommenen Lichtquellen + dem ursprünglichem Direktlicht in einem klassischem Scanlineverfahren zu berechnen. Etwa Vray für 3ds Max.


    Btw:

    http://www.youtube.com/watch?v=PDMYxDMF67M&feature=related
    http://www.youtube.com/watch?v=LL6tdidjWgE&feature=related

    (In den Videos wird das Activ Shade Fenster von einem Zweitrechner berechnet. Derzeit noch komplett via CPU)

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

    Autor: coder 26.06.09 - 21:57

    Du schmeißt da ein paar Dinge durcheinander.
    Monte Carlo steht für Zufall. (Glücksspiel :)
    Beim Monte Carlo Rendering werden die Strahlen einfach nur weiter verfolgt als beim Whitted style Raytracing, von dem hier meist gesprochen wird. Der Strahl endet nicht auf einer Diffusen Fläche, sondern wird in eine (mehr oder weniger) >zufällige< Richtung geschossen, bis eine Lichtquelle getroffen wird. Dann wird berechnet wie viel Licht auf diesem Weg das Pixel erreicht. Je mehr Strahlen man auf diese Weise verfolgt, desto mehr nähert man sich dem korrekten Ergebnis. Dann gibt es noch diverse Optimierungen und Erweiterungen dazu, aber alle sind nur verschiedene Formen des Raytracing. Überall werden Strahlen verfolgt, Schnittpunkte berechnet, der Weg des Lichtes zurückverfolgt.

    Was du da mit Lichtplan usw. beschreibst hört sich nach 'instant radiosity' an, und ist eigentlich nur ein hack um den Eindruck von global illumination in Echtzeit zu vermitteln. Und das hat tatsächlich nur am Rande mit Raytracing zu tun. Hat übrigens auch nur wenig mit 'radiosity' an sich zu tun, trotz des namens. Ist aber ne nette Sache um schnell ein hübscheres Ergebnis zu bekommen als ganz ohne GI.

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

    Autor: unwissender 26.06.09 - 22:50

    wieso lässt man nicht das spiegeln den cpu machen, und das raytracen die gpu (singlechipdings)

    gibts im raytracing noch texturen (wennja, wozu noch?)

    wieso füllt man polygone noch mit texturen? es gibt ja mittlerweile eh schon so viele an einem modell..

    was machen dann die 94kb 3d artists? das läuft ja alles wie hölle und sieht manchmal auch richtig gut aus?



    (sorry bin AD + texturenverweigerer)


    (eigentlich bin ich dafür, endlich direkt in der cpu, räume aus paar tausend nm grösse zu schaffen, wo dann mit nanopartikeln die physik richtig simuliert , ausgelesen und weitergegeben wird)





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

    Autor: unwissender 26.06.09 - 23:01

    http://de.wikipedia.org/wiki/Kolmogorow-Smirnow-Test

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

    Autor: Ach 26.06.09 - 23:02

    Erst mal thx Godness das hier Leute unterwegs sind, die wirklich von der Materie kommen. Da hab ich schon andere Zeiten erlebt^^.

    coder schrieb:
    -------------------------------------------------------
    > Du schmeißt da ein paar Dinge durcheinander.
    > Monte Carlo steht für Zufall. (Glücksspiel :)
    > Beim Monte Carlo Rendering werden die Strahlen
    > einfach nur weiter verfolgt als beim Whitted style
    > Raytracing, von dem hier meist gesprochen wird.

    Ok, das wollte ich wissen. Monte Carlo und Russisch Roullett bei der Strahlenberechnung sind mir allerdings schon beläufige Begriffe :).

    > Der Strahl endet nicht auf einer Diffusen Fläche,
    > sondern wird in eine (mehr oder weniger)
    > >zufällige< Richtung geschossen, bis eine
    > Lichtquelle getroffen wird. Dann wird berechnet
    > wie viel Licht auf diesem Weg das Pixel erreicht.
    > Je mehr Strahlen man auf diese Weise verfolgt,
    > desto mehr nähert man sich dem korrekten Ergebnis.
    > Dann gibt es noch diverse Optimierungen und
    > Erweiterungen dazu, aber alle sind nur
    > verschiedene Formen des Raytracing. Überall werden
    > Strahlen verfolgt, Schnittpunkte berechnet, der
    > Weg des Lichtes zurückverfolgt.
    >
    > Was du da mit Lichtplan usw. beschreibst hört sich
    > nach 'instant radiosity' an.

    Hmm, also in der Programm Bezeichnung nennt sich das Irradiance Map. In dieser werden Materialinformationen von deren Lichtaufnahme wie -abgabe festgehalten. Diese Map kann man als Datei speichern und sie gegebenenfalls wieder aufrufen. Mit jeder neuen Perspektive aus der man rendert, wird die Map vollständiger. Ändert man etwas in der Geometrie oder dem Licht, sollte man den Aufbau der Irradiance Map von neuem beginnen, sonnst bekommt man meisten ziemlich viel Müll.

    Mit Radiosity(Gott hab es selig) hat das wohl nicht viel zu tun. Ich verstehe es vom Standpunkt deiner RT-Baum-Erklärung als ein Verfahren, bei dem die Ergenisse der Baumberechnung zwichensgepeichert werden um bei statischen Szenen von vorhergehenden Berechnungen profitieren zu können.

    Weils so schön ist:

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

    Das ist der Angriff von der andern, der Non RT Seite auf das Darstellungs-Timing-Problem :), diesmal mit allen Infos zur verwendeten Hardware.
    Ist reines Pathtracing(noch!)über CPU. also wenn Spiele mal so aussehen...

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

    Autor: Ähm, 27.06.09 - 00:23

    nur falls es da Missverständnisse gab, "mit Leuten die nicht von der Materie kamen" meinte ich niemals irgendwelche Berichtautoren, (die find ich auf Golem außergewöhnlich gut), sondern krasse Postings aus dem Off.

    Ich hab aber noch eine DICKE Frage:

    Ist Mirrors Edge vorberechnet?

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

    Autor: whiteambit 27.06.09 - 05:35

    coder schrieb:
    -------------------------------------------------------
    > Darum macht Hybrid
    > eigentlich nur Sinn solange Raytracing mangels
    > performance eigentlich noch keinen Sinn macht, und
    > man lieber ganz bei Rasterizing bleiben sollte.
    > :)

    Das ist mal ein Argument ;) aber Hybrid sollte es sowieso sein wenns nach was aussieht. Guck Dir z.B. Imperfect Shadow Maps an - klar Scanline, es werden in den Shadow maps alle Polys "gemalt". Aber das ergebnis ist für Schattenwurf einfach genial. RT bringts doch fast nur für nicht diffuse spiegelungen, harte "stencil" gleiche schatten, caustics und refraction. AO/GI und SubsufaceScattering würde ich nicht als RT machen.´

    > Und zum Thema volumetrische Partikel: selbst in
    > den aktuellsten und hochgelobten AAA-Titeln
    > findest du immer noch diese netten clipping Fehler
    > von den flachen Partikeln. Das mit den
    > Fortschritten lässt für meinen Geschmack etwas zu
    > Wünschen übrig...

    Naja es gibt immer noch welche die es anders einbauen. Aber das ist kein Gegenargument. Es ginge, und wie lange wirds wohl dauern bis das ein oder andere im RT gut umgesetzt wird...


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

    Autor: whiteambit 27.06.09 - 05:47

    jaein. ich weiss nicht genau wie sie es bei ME machen. Aber es gibt einen tollen Trick, wie man Dynamisches AO recht brauchbar für die kosten von BumpMapping bekommt. Es funktioniert aber nur näherungsweise für statische Geometrie. Aber da ganz gut, wie ein vorposter so schön bemerkte "besser als gar kein GI". Der fake beruht auf "bentNormal"-Maps die man sich z.B. mit faogen oder xNormal generieren kann. Dazu wird praktisch die normale des Bump Mapping leicht in die richtung der möglichen lichtquellen verschoben. Die innenseitenwand einer tasse bekommt ja nicht aus der richtung der normalen (wand gegenüber) sondern wenn dann schräg von oben licht. Und da die stelle generell leicht abgedungkelt ist verkürzt man den normalvector noch. Das Ergebnis ist erstaunlich gutes "self AO" das sogar noch dynamisch zur lichtrichtung funktioniert und sogar softshadows wirft - und das ganze kostet ausgeführt nur so viel leistung wie bumpmapping, letztlich also ein "dot-product" :P

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

    Autor: Ach so 27.06.09 - 08:34

    Also quasi "missbraucht" man ein Bump bzw. Nomalmapping, welches zur Detailierung von Charaterdetails benutzt wird, stüllpt es über die gesammte Architektur und setzt es in Abhängigkeit zu der(den) Lichtquelle(wenn ich das richtig verstanden habe). Cool! Das Ergebniss spricht für ja sich!

  17. Re: ruckelt!

    Autor: __Michael__ 27.06.09 - 15:05

    Du wohl nicht! Das kann man auch auf der GPU berechnen mit CUDA. Ist zwar umständlicher als mit normalem C oder besser C++ aber durchaus machbar.

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

    Autor: whiteambit 27.06.09 - 16:44

    Ja, aber du brauchst dann ein eindeutiges UV-Map (texturzuordnung) weil du keine muster mehr doppelt benutzen kannst. Bei der berechnung nimmst du eine gedachte gleichmäßige weisse umgebung (so wie der "waffenraum" in Matrix), für die anschließende berechnung bei der darstellung kannst du dann beliebige lichtquellen in bezug zu diesem verbogenem vector aus der bump-map setzen. Genauso wie sonst zur Oberflächennormalen, oder der Bump-Normalen.

    http://raven.cnblogs.com/

    Oben siehst du das gängige Verfahren, ganz unten die verbesserung die du durch Bent- (oder Bend-) Normals erwarten kannst. Ausser den Vorberechnungen die man auch abspeichern kann, kostet es zur laufzeit nichtmal mehr Rechenleistung. Es ist sicherlich nicht Perfect, aber besser als das gängige NdotL verfahren ganz oben alle mal...

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

    Autor: Spielkinder 27.06.09 - 16:49

    > doppelt benutzen kannst. Bei der berechnung nimmst
    > du eine gedachte gleichmäßige weisse umgebung (so
    > wie der "waffenraum" in Matrix), für die

    Lichtallergie!

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

    Autor: Blair 27.06.09 - 17:12

    whiteambit schrieb:
    -------------------------------------------------------
    > Danke für die Links, aber bisher konnte ich kein
    > beispiel sehen wo die Leistung auch nur nah
    > herankommt. Die interaktive auflösung wird mit
    > 512x384 für einen DualCore angegeben - also
    > vielleicht 10fps. Auf dieser Auflösung steigt die
    > Leistung auf einer GTX260 auf 50-150fps an. Und
    > die Szene ist auch noch komplexer...

    Was ich nicht verstehe: Warum entwickelt dann Intel eine Many-Core-CPU (Larrabee) für Raytracing, wenn GPUs dafür angeblich besser geeignet sind?

    PS: Für den Preis einer GTX260 bekommt man auch Quadcore-CPUs.

  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. IT Systemadministrator*in als Systembetreuer*in (m/w/d)
    Stadtwerke München GmbH, München
  2. Trainee (m/w/d) Anwendungsentwicklung C#
    Hallesche Krankenversicherung a. G., Stuttgart
  3. IT-Systemadministrator (m/w/d)
    Stadtwerke Lünen GmbH, Lünen
  4. (Junior) Inhouse IT - Consultant (m/w/d)
    Nordwest Industrie Group GmbH, Bundesweit

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Undefined Technologies: Start-up will Drohne mit Ionenantrieb getestet haben
Undefined Technologies
Start-up will Drohne mit Ionenantrieb getestet haben

Das US-Start-up Undefined Technologies behauptet, eine Drohne mit Ionenantrieb gebaut zu haben. Es gibt Zweifel, die Rede ist von Betrug.

  1. Künstliche Intelligenz Griechenland testet autonome Drohnenschwärme
  2. Unbemannte Flugzeuge Erstflug der weltweit größten Solar-Drohne
  3. Luftwaffe in Afghanistan und Mali "Meister eines Drohnensystems" mit schwerem Trauma

Softwareentwicklung: Erste Schritte mit dem modernen Framework Flutter
Softwareentwicklung
Erste Schritte mit dem modernen Framework Flutter

Flutter ist ein tolles und einfach zu erlernendes Framework, vor allem für die Entwicklung mobiler Apps. Eine Anleitung für ein erstes kleines Projekt.
Eine Anleitung von Pascal Friedrich

  1. Google Flutter läuft stabil auf Windows

Ryzen 7950X/7700X im Test: Brachialer Beginn einer neuen AMD-Ära
Ryzen 7950X/7700X im Test
Brachialer Beginn einer neuen AMD-Ära

Nie waren die Ryzen-CPUs besser: extrem schnell, DDR5-Speicher, PCIe Gen5, integrierte Grafik. Der (thermische) Preis dafür ist jedoch hoch.
Ein Test von Marc Sauter und Martin Böckmann

  1. Threadripper Pro 5995WX im Test AMDs Oktopus ist zurück
  2. Mendocino Ryzen/Athlon-Chip vereint Zen2, RDNA2 und LPDDR5
  3. Notebooks AMD ändert das Namensschema für Mobilprozessoren