3 Punkte von GN⁺ 2023-11-24 | 1 Kommentare | Auf WhatsApp teilen
  • Der Einstieg in Grafikprogrammierung hängt weniger von der einen richtigen Antwort ab als von Vorwissen, Lernstil und Hardware; das AMD Game Engineering Team sieht möglicherweise Bedarf an einem einsteigerfreundlicheren Ausgangspunkt.
  • Grafikprogrammierung besteht darin, C++-Code auf der CPU-Seite und Shader-Code auf der GPU-Seite gemeinsam zu schreiben und beide über Grafik-APIs wie DirectX, Vulkan oder OpenGL zu verbinden.
  • Stand 2023 teilen sich die wichtigsten Optionen in Legacy-APIs wie OpenGL, DirectX 11 und WebGL sowie moderne explizite APIs wie Vulkan, DirectX 12, Metal und WebGPU.
  • Legacy-APIs sind leichter zu lernen, haben aber an Treiber- und Runtime-Komplexität zugenommen; moderne APIs verlangen mehr Code und GPU-Verständnis, geben dafür aber mehr Kontrolle.
  • Zu Beginn kann man mit einfacheren Umgebungen wie OpenGL, WebGL, Game Engines oder Shadertoy starten; wer C++ und die GPU-Pipeline ausreichend versteht, kann auch direkt mit Vulkan oder DirectX 12 einsteigen.

Grundstruktur der Grafikprogrammierung

  • Die kurze Antwort auf die Frage, welche Sprache Grafikprogrammierer hauptsächlich verwenden, lautet C++.
  • In der Praxis schreibt man sowohl Host-Code, der auf der CPU läuft, als auch Shader-Code, der auf der GPU ausgeführt wird.
    • Host-CPU-Code wird in der Regel in C++ geschrieben.
    • GPU-Code wird in einer High-Level-Shading-Language wie HLSL oder GLSL geschrieben.
  • Die Grafik-API ist die Schnittstelle, über die CPU-Code der GPU mithilfe von Shadern sowie den benötigten Daten und Metadaten Arbeit zuweist.

Mit welcher Grafik-API sollte man anfangen?

  • Stand 2023 lassen sich die in PC-Spielen und 3D-Anwendungen häufig verwendeten APIs grob in zwei Gruppen einteilen:
    • Legacy-APIs: OpenGL, DirectX 11, WebGL
    • Moderne explizite APIs: Vulkan, DirectX 12, Metal, WebGPU
  • OpenGL, DirectX 11 und WebGL basieren auf dem historischen Ansatz, GPUs zu programmieren, und sind aus Sicht von Programmierern einfacher und damit leichter zu lernen.
  • Diese Einfachheit hat ihren Preis.
    • Im Laufe der Zeit wurden die internen Implementierungen von Treibern und Runtimes komplexer.
    • Das führte zu Bottlenecks auf der Host-Seite und zu einer hohen Treiberkomplexität, die GPU-Anbieter bewältigen müssen.
  • AMDs Mantle erschien zwischen 2013 und 2016 auf dem PC und bot durch AMD-GPUs sowie die Zusammenarbeit mit EA DICE einen Low-Level-Zugriff auf die GPU und eine schlankere Abstraktion.
  • Metal erschien 2014 auf Apple-Plattformen; DirectX 12 und Vulkan folgten 2016 und behandeln GPU-Programmierung auf niedrigere und explizitere Weise.

Lern-Trade-offs zwischen einfachen APIs und expliziten APIs

  • Vulkan und DirectX 12 verlangen, dass Programmierer genauer angeben, welche Arbeit die GPU erledigen soll, wodurch die Einstiegshürde höher ist.
  • Dafür erhält man mehr Kontrolle und größere Chancen, Performance und Effizienz von GPU-Arbeit zu verbessern.
  • Schon am Beispiel des ersten Dreiecks werden die Unterschiede zwischen APIs sichtbar.
    • Mit OpenGL oder DirectX 11 lässt sich das erste Dreieck mit ungefähr 10 Zeilen zeichnen.
    • Vulkan und DirectX 12 benötigen deutlich mehr Code.
  • OpenGL und DirectX 11 verbergen viele Details und ermöglichen einen schnellen Einstieg in produktive Grafikarbeit, können die Funktionsweise der GPU aber wie eine magische Black Box erscheinen lassen.
  • Vulkan und DirectX 12 verlangen von Anfang an Low-Level-Wissen und GPU-Verständnis, machen dafür aber klarer sichtbar, was jede Codezeile auf der GPU bewirken wird.

Optionen für den Einstieg

  • Auch innerhalb des AMD Game Engineering Teams gibt es sowohl die Ansicht, dass DX12 oder Vulkan für Jugendliche oder Anfänger als Startpunkt hart sind, als auch die Ansicht, dass es unter passenden Bedingungen möglich ist.
  • OpenGL hat zwar an Aktualität und Relevanz verloren, gilt aber weiterhin als ausreichend, um die Grundlagen zu lernen.
  • WebGL kann ein guter Ausgangspunkt sein, um die Grafik-Pipeline zu verstehen.
    • Im Web kann man Echtzeitgrafik mit JavaScript statt C++ bearbeiten.
    • Mit WebAssembly ist es auch möglich, Grafik im Browser mit C++ auszuführen.
  • WebGPU bietet Konzepte, die modernen Grafik-APIs näherkommen, kann aber weniger Low-Level-Details verlangen.
    • Sobald man beginnt, komplexeren Code zu schreiben, kann man allerdings noch auf verschiedene Probleme stoßen.
    • Als API für Prototyping, Lernen und Lehre ist es vielversprechend.
  • Auch der Einstieg über eine Game Engine ist möglich.
    • Unreal Engine hat einen großen Anteil im PC-Gaming.
    • Unity ist ebenfalls eine gängige Alternative.
    • Es gibt auch kleinere und einfachere Open-Source-Engines wie Godot.
  • Manche Hochschulen führen erste Rendering-Kurse mit Unity durch, doch dabei besteht das Risiko, dass Studierende nicht verstehen, warum sie Low-Level-Wissen lernen sollten.
  • Wer mit einer expliziten API beginnen will, sollte den modernen Grafik-Pipeline-Ansatz und die groben Abläufe, wie GPU-Hardware ihn implementiert, gut kennen – oder bereit sein, dieses Verständnis parallel aufzubauen.

Empfohlene Lernressourcen und nächste Schritte

  • LearnOpenGL: Eine einsteigerfreundliche Website, um Grafikprogrammierung mit einer echten API in C++ zu lernen.
  • Scratchapixel: Ermöglicht den Fokus darauf, wie Konzepte wie Ray Tracing funktionieren, ohne viel Code schreiben zu müssen.
  • Udemy: Kann als Ort dienen, um Kurse für Einsteiger zu finden.
  • Rastertek: Tutorials zu OpenGL und DirectX 11.
  • Ray Tracing in One Weekend: Geeignet für einen Ansatz, bei dem man durch eigenes Implementieren lernt, sofern man bereits etwas programmieren kann.
  • A trip through the graphics pipeline: Zwar ein Text von 2011 und damit aus der Zeit vor expliziten APIs, doch die Hardware- und Softwarekonzepte aus GPU-Sicht gelten weiterhin.
  • learn wgpu: Eine WebGPU-Lernseite in einem ähnlichen Stil wie LearnOpenGL, die noch Work-in-Progress-Charakter hat.
  • Your first WebGPU app: Kann als Einstiegsmaterial für WebGPU betrachtet werden.
  • Shadertoy: Ein einfacherer Startpunkt, weil man Shader schreiben kann, ohne direkt mit einer Grafik-API zu arbeiten.
  • Vulkan Tutorial: Wird im Kontext dazu genannt, dass es beim Lernen von Vulkan oder DirectX 12 auch wichtig ist, keine Angst vor Copy & Paste zu haben.
  • Wenn man sich noch nicht für eine Sprache oder ein API-Ökosystem entschieden hat, kann man mehrere Ansätze ausprobieren und dann den Weg weiterverfolgen, der am besten passt.

1 Kommentare

 
GN⁺ 2023-11-24
Meinungen auf Hacker News
  • Anfänger sollten nicht mit „Welche Tools soll ich nutzen?“ anfangen, sondern einen Schritt zurücktreten und zuerst fragen: „Was möchte ich bauen?“
    Auch beim ersten Lernen sollte man das Endergebnis nicht aus den Augen verlieren. In der heutigen Computergrafik gibt es so viele Tools, die die vielen Schritte zum Zeichnen von Pixeln auf dem Bildschirm abstrahieren, dass man sich anfangs mit Low-Level-Code abmüht und erst später merkt, dass in dem Bereich, in den man eigentlich will, nur Unity, TouchDesigner, threejs oder After Effects verwendet werden und C++ kaum eine Rolle spielt.
    Natürlich ist es enorm wertvoll zu lernen, wie die Dinge ganz unten funktionieren, aber das als Erstes zu tun halte ich für einen langsamen Ansatz. Man lernt schneller, wenn man in die Branche einsteigt und sich über Abstraktionstools wie Game Engines oder visuelle Programmierung ein Verständnis für die internen Abläufe erarbeitet.
    Das sage ich aus der Perspektive von jemandem, der Jahre damit verbracht hat, sich mühsam C++ und OpenGL beizubringen, und lange mit den versunkenen Kosten gekämpft hat, die es schwer machten, No-Code-Ansätze zu akzeptieren. Wenn dieser Weg am Ende nicht dabei hilft, das zu bauen, was man bauen möchte, sollte man keine Zeit damit verschwenden.

    • Diesen Rat sollte man beherzigen. Zu Beginn meiner Karriere hatte ich mir vorgenommen, OpenGL-Experte zu werden, und ich denke, das ist mir bis zu einem gewissen Grad auch gelungen.
      Ich habe zwar kein Lehrbuch wie Mark Kilgard geschrieben, aber ich habe viele Schichten der API intensiv behandelt: von der Treiberebene über Konformitätstests und Performance-Tuning bis hin zu Game- und Anwendungscode sowie den großen Desktop- und Mobilplattformen.
      Und wohin hat das geführt? Ehrlich gesagt nicht besonders weit. Heute interessiert sich kaum noch jemand für OpenGL, und nachdem zwei große OS-Anbieter es letztlich aufgegeben haben, ist es praktisch eine nahezu tote Technologie. Eine Suche nach OpenGL in „HN Who's Hiring“ zeigt das recht deutlich.
      Ich hätte andere Grafik-APIs wie Direct3D, Vulkan oder Metal neu lernen können, aber Low-Level-Grafikcode wird heute von Engines abstrahiert, sodass es nicht viele Stellen gibt, die solche Leute brauchen. Auch Unternehmen, die Low-Level-Grafiktreiber-Personal benötigen, gibt es weltweit höchstens fünf oder sechs; das wird zu einer Nische, die die Karriere einschränkt.
      Je stärker man sich auf einen kleineren Teil der Maschine konzentriert, desto eher muss man darin ein Weltklasse-Experte werden, wenn man daraus eine ganze Karriere machen will. Wenn dein Plan nicht ist, der nächste John Carmack zu werden, würde ich empfehlen, eher breit als tief zu gehen.
    • Das ist eine klassische Falle, in die neue Entwickler ständig tappen. Und sie betrifft nicht nur Grafikprogrammierung.
      YouTube ist voll von Anfänger-Videos zum Programmieren, die einen endlosen Tech-Stack lehren, statt sich darauf zu konzentrieren, etwas Interessantes zu bauen. Das Ergebnis ist, dass man für den Lebenslauf selbst zum Rendern von ein paar Textzeilen auf einer Webseite cargo-kultartig eine komplizierte Rube-Goldberg-Maschine baut.
      An der Uni habe ich ein Semester lang ein wenig Grafikprogrammierung gemacht, und sie war komplex genug, dass eine vernünftige Antwort auf „Was möchtest du bauen?“ etwa „ein grünes Dreieck auf schwarzem Hintergrund rendern“ war. Von dort aus zu Rechtecken, Würfeln, Kugeln, animierten Kugeln und einem springenden Ball zu gehen ist eine natürliche Entwicklung und hält den Fokus auf dem Ziel. Man sollte also auch den Fehler vermeiden, auf die obige Frage mit „ein First-Person-Shooter mit Raytracing-Beleuchtung und Subsurface Scattering“ zu antworten.
      Der Code für die erste Version des springenden Balls wird wirklich furchtbar sein. Das ist in Ordnung. Mit der Zeit lernt man, ihn zu optimieren und zu verbessern. Und kaum etwas ist so aufregend, wie Design Patterns selbst zu entdecken. Man liest ein Buch zu einem neuen Thema und denkt: „Moment, das mache ich ja schon!“
    • Aus der Sicht von jemandem, der in dieses Feld einsteigen will, fällt es mir etwas schwer, dem zuzustimmen. Viele, vielleicht sogar alle Stellenausschreibungen für Grafikprogrammierung verlangen im Voraus C++-Kenntnisse.
      Natürlich kann man auch über eine andere Rolle wie Gameplay-Programmierer einsteigen und dann langsam in Richtung Grafik wechseln, und das kann sogar einfacher sein. Aber am Ende braucht man für eine Rolle als Grafikprogrammierer C++.
      Das oben Gesagte trifft eher auf Leute zu, die schnell produktiv an grafikbezogenen Aufgaben arbeiten wollen, nicht auf Grafikprogrammierung selbst.
    • Guter Rat. Das ist auch eine häufige Falle bei Fragen wie „Welche Sprache soll ich lernen?“ oder „Welche Sprache ist die beste?“, weil dabei „Was möchte ich bauen?“ übersprungen wird.
      Tools ändern sich mit der Zeit, und meiner Erfahrung nach können hervorragende Engineers oft mehrere Tools mit unterschiedlichem Kompetenzniveau einsetzen, statt nur eines sehr tief zu beherrschen.
    • Ich denke, es ist weiterhin wertvoll, solche Low-Level-Programmierung wie Sortieralgorithmen an Universitäten zu lehren.
      Selbst wenn man diese Arbeit später im Beruf nicht macht, nimmt man viel theoretisches Wissen und Training mit komplexen Algorithmen mit.
      Grafik vermittelt außerdem viel Erfahrung mit angewandter Mathematik. Es gibt wirklich viele Bereiche, die händeringend Leute suchen, die Mathematik beherrschen. In meinem früheren Job an Software für CNC-Maschinen brauchten wir jemanden, der die Mathematik programmieren konnte, die nötig war, um Bohrer so zu steuern, dass bestimmte Formen in einen Metallblock gebracht werden. Das war extrem schwer zu finden. Cloud-DevOps-Engineers waren dagegen zwar teuer, aber relativ leicht zu bekommen.
  • Als Grafikprogrammierer sollte man meiner Meinung nach ein ausgewogenes Gesamtverständnis davon haben, wie Grafik funktioniert. Über einfache Programmierung und API-Wissen hinaus sollte ein guter Grafikprogrammierer Rotations-, View- und Projektionsmatrizen, allgemeine Vektormathematik, Shader-Programmierung, prozedurale Primitive wie Voronoi, SDF und Perlin, Bildkomposition, Forward- und Deferred-Rendering, verschiedene Sampling-Verfahren sowie Schatten- und Beleuchtungstechniken kennen.
    Außerdem braucht man ein Verständnis dafür, wie Art-Pipelines funktionieren und wie man Daten aus 3D-Apps herausbekommt, sollte mit Profilern und Debuggern bequem umgehen können, SIGGRAPH-Papers lesen können, räumliche Unterteilung und Volumenhierarchien kennen, einen einfachen Raytracer implementieren können, Primitive wie Sprites, Dreiecke und n-Ecke verstehen sowie Erfahrung mit Partikeln und Simulationen haben.

    • Mich würde interessieren, ob du „wie Art-Pipelines funktionieren und wie man Daten aus 3D-Apps herausbekommt“ etwas näher ausführen kannst.
      Den sehr grundlegenden Ablauf, wie ein Modell entsteht — also etwa Modellierung → Skinning/Rigging → Animation → Texturierung — und grob, wie man das in Dateien schreibt, kenne ich. Aber in diesem Bereich ist es besonders schwierig, echte Praxiserfahrung zu bekommen, wenn man nicht mit Artists zusammenarbeitet.
    • Wenn man den Großteil dieser Liste kennt, frage ich mich, wie man als Grafikentwickler einen Job bekommen kann.
      Ich mache Grafikprogrammierung als Hobby und habe viele der hier genannten Dinge gelernt, aber weil mir Berufserfahrung fehlt, bekomme ich kaum Interview-Gelegenheiten.
    • Wo kann man solche Dinge lernen?
  • Ich empfehle den Kurs Graphics From Scratch von Pikuma. Als Erstes schreibt man mit SDL eine set_pixel-Funktion, danach implementiert man alles selbst im Code
    Man schreibt alle Matrixoperationen, alle Vertex-Transformationen und die gesamte Dreiecks-Rasterisierung selbst und berechnet, welche Farbe jedes Pixel haben soll
    https://pikuma.com/courses/learn-3d-computer-graphics-progra...

    • Meine Website/mein Buch/mein Kurs behandeln denselben Ansatz und sind kostenlos
      https://www.gabrielgambetta.com/computer-graphics-from-scrat...
    • Dafür gebe ich ebenfalls eine Stimme ab. Ich habe diesen Kurs vor ein paar Monaten gemacht, als ich von Graphics Programming fast nichts wusste und nur ein paar Jahre Erfahrung als allgemeiner Software Engineer hatte, und danach habe ich ziemlich gut verstanden, wie 3D-Formen auf den Bildschirm gezeichnet werden
      Danach konnte ich mir WebGPU in wenigen Tagen aneignen; ohne das Verständnis aus dem Kurs wäre das vermutlich unmöglich gewesen
      Falls ihr Motivation braucht: Ich habe eine Demo gebaut, bei der der Renderer, den man am Ende des Kurses erstellt, nach Wasm kompiliert ist: https://rmshin.github.io/3d-renderer-wasm
    • Ein interessanter Punkt. Ich habe darüber nachgedacht, wie ich selbst einen Einführungskurs in Graphics entwerfen würde
      Sollte man wie in den 90ern mit SDL-Code im putpixel-Stil anfangen oder mit Shadertoy? Die grundlegende Matrixmathematik ist natürlich immer wichtig. Aber wie sollte man Dreiecks-Rasterisierung lehren? Kann man Scanlines überspringen und direkt zu homogenen Koordinaten und Quadtrees übergehen?
      Sollte man wirklich Phong-Shading lehren, oder kann man direkt zu BRDFs springen? Bei manchen Themen vermittelt man vielleicht eher „alte Tricks“ als wirklich nützliche Techniken
      Heute sind Statistik und Sampling viel wichtiger. Ich glaube, Graphics wird von Jahr zu Jahr mathematischer. Also sollte man Mathematik lernen und Mathematik lehren
    • Es gibt einige gute Ressourcen, um 3D-Rendering von Grund auf zu implementieren
      Dieses GitHub-Repository kann ich besonders stark empfehlen: https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting...
      Wenn ihr eher visuell lernt, ist auch dieser Kanal eine echte Fundgrube: https://www.youtube.com/watch?v=ih20l3pJoeU
    • „Keine GPU, kein OpenGL, kein DirectX!“ ist genau das Gegenteil von dem, was man erwartet, wenn man Graphics Programming lernen will
  • Auf Shadertoy kann man Graphics über das Schreiben von Shadern lernen. Viele Graphics Programmer haben dort angefangen
    Ein bisschen Eigenwerbung: Ich habe mehr als zehn Tutorials erstellt, die Shader-Programmierung in VS Code, SDFs, Ray Marching, Noise-Funktionen, fraktale Brownsche Bewegung und mehr behandeln
    https://github.com/suboptimaleng/shader-tutorials
    Natürlich stehe ich dabei auf den Schultern von Giganten wie Inigo Quilez, The Art of Code, SimonDev und Acerola

  • Es gibt wirklich viele Wege, Graphics Programmer zu werden, ohne mit DX/VK/OGL anzufangen. Man muss auch nicht zwingend C++ verwenden. Man muss sich nur die erstaunliche 3D-Grafik ansehen, die 3Blue1Brown mit Python macht
    Wenn ihr eine Game Engine verwenden wollt, lernt DirectX oder Vulkan; wenn ihr Browser-Anwendungen bauen wollt, lernt WebGL
    Allerdings sind diese APIs schwergewichtig und bringen einem für sich genommen auch nicht besonders viel über Graphics bei. Wenn ihr Graphics-Konzepte lernen wollt, ist es eine gute Idee, in der Sprache eurer Wahl sowohl einen Rasterizer als auch einen Raytracer selbst zu bauen
    Es gibt viele Graphics Libraries und Coding-Umgebungen, die deutlich mehr Spaß machen, als sich mühsam durch Vulkan oder DirectX zu arbeiten. Processing ist hervorragend, und auch das Python-basierte PlotDevice.io sowie dessen Vorgänger NodeBox und DrawBot sind einen Blick wert. ShaderToy ist ein weiterer Ort, an dem man viel über Shader-Programmierung und Rendering lernen kann, und der Einstieg ist einfach. Auch in JavaScript gibt es viele Optionen und Libraries. All das ist für Anfänger viel zugänglicher und motivierender und bietet zugleich genug Leistungsfähigkeit und Flexibilität, damit neugierige Lernende so tief einsteigen können, wie sie möchten

  • Da dieser Artikel auf der ersten Seite gelandet ist, poste ich mal eine Ressource, die in der Graphics-Programming-Branche tatsächlich verwendet wird. Zur Einordnung: Ich bin einer der Autoren: https://raytracing.github.io/
    Sie ist auch im Abschnitt „Useful Websites“ des obigen Artikels enthalten
    Graphics ist inzwischen so breit, dass es den einen Lernweg, der für alle passt, nicht mehr gibt. Wenn ihr Graphics lernen wollt, empfehle ich, euch einen Mentor zu suchen

    • Gute Ressource. Ich stimme besonders dem Ansatz zu, Mathematik zuerst über Raytracing statt über APIs zu vermitteln
  • Ich bin Spieleentwickler, aber kein professioneller Graphics Programmer. Beruflich verwende ich moderne Graphics APIs und GLSL-Shader, aber als ein 13-jähriges Kind vor Kurzem von Scratch oder Python aus C++ lernen wollte, hielt ich es für das Beste, eine alte OpenGL-1.2-DLL hervorzuholen, die seit 1999 auf meinem Computer lag, und es zuerst Immediate-Mode-Code im Stil von glut und glbegin/glvertex/glend schreiben zu lassen
    Das macht viel mehr Spaß, als all die Konfiguration zu ertragen, die moderne APIs verlangen. Das Kind interessiert sich eher für algorithmische Geometrie wie Voronoi-Diagramme, daher ist die Graphics API nur ein Mittel zum Zweck, und schicke Shader oder Beleuchtung sind im Moment nicht wichtig. Die Performance von C++ und altem OpenGL ist ungefähr tausendmal schneller als Scratch, also scheint das ein guter Sweet Spot für den aktuellen Lernstand zu sein
    Selbst mit der vereinfachten OpenGL-1.2-API ist es ziemlich ambitioniert, C++ und OpenGL gleichzeitig verstehen zu wollen; die Einfachheit macht es mental handhabbar. Bisher läuft es gut: Das Kind hat eine ordentliche Marching-Squares-Demo gebaut, und ich habe geholfen, ein IMgui-Menü anzubinden, mit dem man Parameter zur Laufzeit anpassen kann. Das hat ziemlich Spaß gemacht

  • Ich bin mir nicht ganz sicher, wonach diese Website genau fragt. Will man Rigging machen? Texturing? Modeling? Treiber schreiben? GUIs bauen? Website-Animationen? Grafik-Tools? Shader? 2D-Foto-Engines? 2D-Spiele? 3D-Spiele? Prozedurale Skripte? Grafikcode optimieren?
    Unter „Computergrafik“ gibt es Hunderte von Bereichen. Diese Website konzentriert sich aber auf eine sehr kleine Ecke davon: Programmierung von Grafik-SDKs

    • Grafikprogrammierer ist eine ziemlich klar definierte Kategorie von Programmierern. Vieles von dem oben Genannten, etwa Rigging, Texturing oder Modeling, ist keine Grafikprogrammierung.
      Von einem Grafikprogrammierer erwartet man, dass er sich übergreifend mit Spielen, 3D, 2D, Tools, Shadern und Optimierung befassen kann.
    • Es kann verwirrend sein, aber normalerweise meint „Grafikprogrammierer“ jemanden, der an einer Grafik-Rendering-Engine arbeitet, egal ob für Echtzeit- oder Offline-Rendering.
  • Ich bin ebenfalls auf diesem Weg. Vor zwei Jahren habe ich anhand verschiedener Tutorials und YouTube-Videos meine erste 3D-Engine gebaut.
    Sie ist sehr simpel, aber ich mag simple Dinge. Derzeit entwickle ich mit dieser Engine ein Städtebau-Spiel. Es macht wirklich Spaß zu lernen, wie man Elemente mithilfe von Matrizen und Kreuzprodukten manipuliert.
    https://www.youtube.com/watch?v=cvyrfPUpyp0