Was man lernen sollte, um Graphics Programmer zu werden

 (blog.demofox.org)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Kompetenzen für Jobs in Echtzeitgrafik erfordern sowohl explizite Grafik-APIs auf CPU-Seite als auch Beleuchtung und Shading auf GPU-Seite; beide Bereiche gleichzeitig in der Tiefe zu lernen, ist schwierig
  • Auf der CPU-Seite geht es um moderne APIs wie DirectX 12, Vulkan und Metal sowie um Asset-Loading und Engine-Support-Aufgaben; auf der GPU-Seite um Schatten, Ambient Occlusion, Postprocessing und GPU-Performance-Eigenschaften
  • Im Mittelpunkt des GPU-Lernens stehen das Schreiben eines Path Tracers und das Verständnis von PBR; Ray Tracing in One Weekend, LearnOpenGL PBR, die Filament-Dokumentation und PBRT können Ausgangspunkte sein
  • Ein ideales Portfolio zeigt das Wissen über einen C++-basierten Echtzeit-Renderer, einen Path Tracer für fotorealistische Bilder sowie Code, der beide Renderingergebnisse vergleicht und validiert
  • Die nötige Mathematik konzentriert sich auf lineare Algebra, grundlegende Trigonometrie und etwas Analysis; die CPU-seitige Sprache in der Spieleentwicklung ist C++, die häufigste Shader-Sprache ist HLSL

Echtzeitgrafik umfasst CPU- und GPU-Bereiche gemeinsam

  • Modernes Rendering ist im Grunde eine Kombination aus zwei Aufgaben
    • Lernen auf CPU-Seite: moderne explizite APIs wie DirectX 12, Vulkan und Metal sowie Engine-Programmierung für Asset-Loading und andere unterstützende Aufgaben
    • Lernen auf GPU-Seite: moderne Mathematik für Beleuchtung und Shading, Schatten, Ambient Occlusion, Postprocessing-Effekte sowie der Unterschied zwischen schnellen und langsamen Operationen auf der GPU
  • Beide Bereiche gleichzeitig zu lernen, ist sehr schwierig
    • Wer sich auf die GPU-Seite konzentrieren will, kann Tools mit geringer CPU-seitiger Belastung nutzen, etwa OpenGL, WebGL, DirectX 11 oder bestehende Engines
    • Wer sich auf die CPU-Seite konzentrieren will, sollte zunächst ein Dreieck auf den Bildschirm bringen und danach ein Mesh anzeigen; ob das Ergebnis hübsch aussieht, muss dabei nicht besonders wichtig sein

Path Tracing und PBR

  • Zum Lernen der GPU-Seite gehört das Schreiben eines Path Tracers
    • Path Tracing ist ein Verfahren, das beim Film-Rendering verwendet wird, und das Ziel, dem moderne Echtzeit-Rendering-Techniken nahezukommen versuchen
    • Als Einstieg eignet sich das kostenlose Online-Buch Ray Tracing in One Weekend; es ist zugänglich und zeigt den Prozess, fotorealistische Renderings zu erzeugen
  • Physically Based Rendering (PBR) bezeichnet die Art und Weise, wie Beleuchtung, insbesondere Specular, angewendet wird
    • PBR ist ein prinzipienbasierter Ansatz, der gute Ergebnisse liefert, wenn man die Regeln einhält
    • Vor PBR wurden für Beleuchtung viele beliebige Formeln, Anpassungen und Hacks verwendet, sodass Assets, die in einer Lichtumgebung gut aussahen, in einer anderen zu dunkel oder zu glänzend wirken konnten
    • Dadurch mussten für unterschiedliche Beleuchtungsbedingungen verschiedene Asset-Versionen erstellt werden, was viel Zeit und Aufwand kostete
  • PBR sorgt dafür, dass Assets unter verschiedenen Lichtbedingungen konsistenter aussehen, und reduziert Zeit und Aufwand für die Erstellung versionierter Assets
    • Trotzdem bleiben Zeit, Kosten und Aufwand für die Asset-Erstellung ein großer Engpass in der Spieleentwicklung

Empfohlene Lernressourcen

Code, der sich im Portfolio zeigen lässt

  • Um Recruitern das eigene Wissen zu belegen, ist es ideal, teilbaren Quellcode etwa auf GitHub bereitzustellen und im Lebenslauf darauf zu verlinken
  • Beispiel-Portfolio:
    • Ein Engine-artiger Renderer, der Assets wie Modelle und Texturen lädt und sie in Echtzeit auf dem Bildschirm rendert
      • Mit einigen Effekten wie Beleuchtung und Schatten, Depth of Field, Area Lights, Tone Mapping und Ray Traced Shadows
      • Wenn möglich mit PBR-basierter Beleuchtung, einer vom Nutzer steuerbaren Kamera, einer API wie DX12 oder Vulkan und C++
    • Ein Path Tracer, der fotorealistische Bilder erzeugt
      • Wenn möglich ist C++ gut, aber auch ein Programm ohne Fenster, das nur PNGs ausgibt, ist in Ordnung
      • Es muss nicht echtzeitfähig sein
    • Noch besser ist es, wenn der Path Tracer ein separater Modus des Engine-artigen Renderers ist
      • So lassen sich Path-Traced-Ergebnisse mit Echtzeit-PBR-Rendering vergleichen, um die Genauigkeit zu überprüfen
      • Wer benennen kann, wo die beiden Renderings nicht übereinstimmen, erklären kann, warum sie sich unterscheiden, und überlegen kann, wie man sie unter Beibehaltung der Echtzeitfähigkeit näher zusammenbringt, wird besser bewertet

Mathematik, Algorithmen und Sprachwahl

  • Wenn man die oben genannten Punkte selbst umsetzt, stößt man auf natürliche Weise auf die benötigte Mathematik
    • Grundsätzlich nötig sind lineare Algebra mit Matrixmultiplikation, Cross Product, Dot Product, grundlegende Trigonometrie und etwas Analysis
    • Bei Grafik und Spieleentwicklung ist das mathematische Minimum relativ klein, aber der Umfang der nutzbaren Mathematik ist praktisch unbegrenzt
  • Bei Algorithmen ist es ähnlich
    • Man sollte grundlegende abstrakte Datentypen und Algorithmen wie Linked Lists, Hash Tables, Sortieren und Suchen kennen
    • Die schnellsten Algorithmen sind oft einfach, und Arrays sind wesentlich schneller als Linked Lists
    • Fortgeschrittenere Algorithmuskonzepte helfen, wenn wirklich etwas Neues und Maßgeschneidertes benötigt wird
  • Die Sprache, die man für Spieleentwicklung lernen sollte, ist C++
    • Es gibt zwar Menschen, die Rust verwenden, und Rust hat einen gewissen Anteil, ist aber nicht die Standardsprache, die erwartet wird
    • WebGPU verfügt über viele Funktionen, die WebGL nicht hatte, entwickelt sich zu einer ernsthafteren Plattform und ermöglicht CPU-seitige Arbeit in JavaScript
    • Allerdings wurden nicht viele WebGPU-Jobs oder WebGPU-Inhalte im Web gesehen
  • Die häufigste Shader-Sprache ist HLSL
    • Manche verwenden GLSL
    • In Multiplattform-Spielen werden Shader häufig in andere Shader-Sprachen übersetzt

Einsatzbereich von LLMs und ML

  • Die derzeitige ML-Technologie wird als nicht ausreichend für die meisten Anwendungsfälle angesehen, für die sie verkauft wird
  • Claude ist hilfreich, um über Mathematik, Papers und ungewohnte Algorithmen zu sprechen
    • In solchen Situationen lässt sich leicht überprüfen, ob etwas Erfundenes gesagt wird, und die Plausibilität kann auch gut mit anderen Quellen geprüft werden
  • Für Programmierung ist es nicht besonders nützlich
    • Selbst wenn Code geliefert wird, der wie gewünscht funktioniert, muss man Zeit investieren, um diesen Code zu verstehen
    • Dann ist es besser, ihn selbst zu schreiben
  • Für kleine Einsatzzwecke kann es nützlich sein
    • Fragt man etwa „Siehst du in dieser Datei einen Bug?“, kann man bei einer Ja-Antwort nachforschen, und bei einer Nein-Antwort entstehen kaum Kosten durch die Frage
  • Es wird daran geglaubt, dass die Menschheit eines Tages künstliche Intelligenz auf menschlichem Niveau schaffen und darüber hinausgehen wird; ob dieser Zeitpunkt aber noch in die eigene Lebenszeit fällt, ist unklar
    • Die aktuelle LLM-Ära ist eher eine Generalprobe für den Zeitpunkt, an dem später das „Echte“ kommt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Man sollte zuerst unterscheiden, ob man ein Spiel machen oder 3D-Engine-Programmierung betreiben will.
    Wenn man ein Spiel machen will, ist es besser, eine bestehende Engine wie Unreal Engine, Unity, Godot oder Bevy zu verwenden; dabei lernt man eher die übergeordneten Probleme von Grafik, statt direkt Pixel herumzuschieben. Das wirklich Schwierige ist, es spaßig zu machen.
    Wenn man eine 3D-Engine bauen will, sollte man wissen, dass es schon viel zu viele miserable Game Engines gibt. Allein im Rust-Umfeld sind drei gescheiterte Renderer, ein unfertiger Renderer und der Renderer in Bevy die wichtigsten Projekte; Projekte mit dem Anspruch „Ich baue eine Game Engine“ gibt es noch viel mehr. Schon bis zum Niveau eines „ersten Renderers“ braucht man etwa zwei Jahre, und bis zu großen, detaillierten, dynamischen Szenen ist es noch eine deutlich größere Aufgabe.
    Wenn das Ziel ein Job ist: In der Games-Branche sind weder Bezahlung noch Arbeitszeiten gut, nach Projektende endet oft auch die Stelle, und wie in Hollywood gibt es einen Überschuss an Bewerbern, die hineinwollen. Außerdem gibt es wegen des Metaverse-Kollapses derzeit sogar zu viele erfahrene Leute.
    Mobile ist eine Übung in Kompression, weil Bildschirm, Rechenleistung, GPU und Akku allesamt knapp sind; deshalb sind die meisten Indie-Spiele heute 2D. Das ist immerhin machbar, und oft werden sie sogar mit HTML/JavaScript gebaut.

    • Es klingt, als würdest du annehmen, die meisten wollten mit Unreal in einen visuellen Wettbewerb treten; das ist natürlich nahezu unmöglich.
      Aber einen einfachen Renderer und eine Game Loop zu bauen, ist nicht so schwer und wird wahrscheinlich auch nicht den Großteil des Spielcodes ausmachen. Für ein simples Spiel kann in einer for-Schleife drawObject() völlig ausreichen; Sorgen wie Asset-Streaming, Binding-Optimierung oder Parallelität kann man später angehen, wenn sie nötig werden.
      Mich würde interessieren, von welchem Ausgangspunkt und welchen Erfolgskriterien die Aussage „zwei Jahre bis zum ersten Renderer“ ausgeht. Vor etwa einem Jahr habe ich in einem Monat Freizeit, also weniger als einer Woche Vollzeit, einen Deferred Renderer mit dynamischer Beleuchtung, Shadow Mapping und ein paar Post-Processing-Effekten gebaut.
      Es gibt auch keinen Grund, 2D geringzuschätzen. Ein großer Teil ernsthafter Arbeit passiert in 2D-Interfaces, und WebGL sowie das alte 2D-Canvas sind heute ziemlich leistungsfähig. Unter erfolgreichen Indie-Spielen gibt es ebenfalls viele 2D-Titel.
      Dass die Games-Branche nicht besonders attraktiv ist, stimmt, aber heute nutzt fast alles die GPU. Auch das Schreiben und Debuggen von Machine-Learning-Jobs, Datenvisualisierung, HUDs und allgemeine Benutzeroberflächen erfordern oft Grafikverständnis.
    • Der Durchschnitt der Games-Branche mag schlecht sein, aber die Nische Grafikprogrammierung sehe ich anders.
      Abseits von Spielen gibt es viel mehr Bereiche, die Grafik nutzen, etwa Visualisierung und Simulation, und gute Grafikprogrammierer sind extrem selten; dadurch ist es überraschend betrachtet eine ziemlich gute Karriere. Das steht in starkem Kontrast dazu, dass es für Game Developer oder Artists schwieriger wirkt, gute Jobs zu bekommen. Allerdings sind sowohl Nachfrage als auch Angebot klein, daher ist ein Jobwechsel nicht unbedingt einfach.
      Wenn es nur um Jobsicherheit geht, würde ich davon abraten, Spieleentwicklung zur Karriere zu machen; Grafikprogrammierung ist etwas anderes.
    • Es ist schade, dass eigentlich ordentliche Spiele wegen Unity oder Unreal Engine so oft Performance-Probleme haben. Ich wünschte, man würde sie nicht so empfehlen; ob Godot und Bevy besser sind, weiß ich noch nicht.
      Unter den Spielen, die ich in den letzten Jahren gespielt habe, hatten Core Keeper (Unity), WORMHOLE (Unity, besonders die Verzögerungen im Endless Mode) und Crab Champions (UE4; bei 1920x1200 muss man hässliches Upscaling verwenden, um 60 fps zu halten) starke Performance-Probleme.
      Dagegen nutzen Terraria, Necesse und Barony eigene Engines und laufen hervorragend; je älter sie werden, desto besser wirken sie.
      Fairerweise lief Tiny Rogues (Unity) meiner Erinnerung nach im Großen und Ganzen gut, aber der Entwickler arbeitet daran, künftig von Unity wegzukommen, also scheint er selbst Probleme gefunden zu haben.
      Ich verstehe den Unterschied zwischen Spielebauen und Enginebauen und wie wichtig tatsächliche Fertigstellung und Veröffentlichung sind, aber wenn man Müll ausliefert, hinterlässt man schwer ein gutes Vermächtnis. Ich denke, es ist besser, auch über Umwege ein bestimmtes Qualitätsniveau sicherzustellen. Spiele werden nach dem Release teils über Jahrzehnte gespielt, und wenn es Bugs oder Latenz gibt, werden die Leute sie immer wieder erleben.
    • Wenn man anfängt, eine Engine zu bauen, wird man wahrscheinlich kein Spiel fertigstellen, besonders wenn man dabei erst lernt. Beides erfolgreich zu schaffen ist technisch zwar möglich, aber nach meinen eigenen früheren Erfahrungen und nach Dutzenden Leuten in der polnischen Hobby-Game-Dev-Community lag die Erfolgswahrscheinlichkeit eher bei unter 5 %.
      „Ich baue zuerst meine eigene Engine für mein Spiel, damit das nächste Spiel einfacher wird“ ist eine erstaunlich starke Falle. Denn man lernt tatsächlich wichtige Dinge und bekommt jeden Tag kleine Erfolgserlebnisse. Man entrollt noch eine Schleife, damit die Szene flüssiger aussieht, fügt dem Konfigurationsformat noch eine Logikschicht hinzu, damit Szenen leichter zu erstellen sind, und liest noch ein SIGGRAPH-Paper.
      Es gibt immer etwas Wichtiges zu verbessern, aber diese Dinge fügen sich nicht zu einem fertigen Spiel zusammen. Rückblickend ist die eigene Engine die perfekte Methode für Techniker, den schwierigen, aber notwendigen Teil ihres Traumspiels aufzuschieben: „es spaßig machen“. Man erwirbt die Fähigkeit, beeindruckende Videospieltechnik zu coden, lernt aber nicht, ein Spiel zu machen.
      Es gibt auch eine untergeordnete Falle: Man lernt hundert Methoden, wunderschöne visuelle Effekte zu bauen, die in Echtzeit flüssig laufen, aber nicht, sie als Kunst einzusetzen.
      Das ähnelt stark der Falle von „Enterprise Java“. Nur ist es subtiler, weil man konkrete Begriffe bearbeitet. Man denkt, man sei dieser Kugel ausgewichen, weil der Scene Graph keine Factory Factory Interface hat, übersieht aber, dass all das für die eigentliche Aufgabe, eine Bitmap auf den Bildschirm zu bringen und auf Tasten zu reagieren, an sich unnötig ist.
    • Ich stimme nicht unbedingt zu, dass man immer eine bestehende Engine verwenden sollte, wenn man ein Spiel machen will. In den meisten Fällen ist das guter Rat, aber bestehende Engines sind zu allgemein und bringen viele Annahmen über Spiele mit. Vielleicht braucht das eigene Spiel andere Einschränkungen.
      Besonders in 2D gilt das. Ich entwickle zum Beispiel ein Spiel mit einer selbstgebauten Game Engine und konzentriere mich auf Performance, Kompression und eine Architektur ohne Server oder Datenbank.
      Diese Engine hat innerhalb der von mir gesetzten Einschränkungen sehr spezifische Strukturen und Annahmen über die Spielarchitektur, um extreme Performance und Kompression zu erreichen. Einen dazugehörigen Hacker-News-Beitrag werde ich bald veröffentlichen, wenn möglich nächste Woche.
      Früher habe ich mehrfach versucht, Browsergames mit Unity, Godot und React zu bauen, aber das Lernen der APIs war eine Qual, und die Engines erfüllten meine extremen Einschränkungen nicht. Natürlich lag es vielleicht auch daran, dass ich diese Engines nicht gut genug beherrschte, aber rückblickend glaube ich, dass das, was ich intern erreicht habe, ohne eine von Grund auf gebaute Custom Engine unmöglich gewesen wäre.
      Beim Bau meiner eigenen Engine und meines Spiels habe ich wirklich sehr viel gelernt, und besonders heute denke ich, dass es dank LLMs für erfahrene Entwickler plötzlich für die meisten Entwickler realistisch geworden ist, eine eigene maßgeschneiderte Game Engine auszuprobieren.

  • Stand heute würde ich niemandem empfehlen, in die Grafikprogrammierung einzusteigen.
    Ich habe 2001 angefangen, als Nvidias erste GeForce 1, die sogenannte „Gigatexel shader card“, vorgestellt wurde. Seitdem waren das Entwicklungstempo und die Innovation in diesem Bereich schwindelerregend. Verglichen mit vor 25 Jahren ist die heutige Technik wirklich enorm.
    Aber dieses Staunen hat ein großes „Aber“. Das Feld entwickelt sich erschreckend schnell. Nvidia hat sogar KI-basierte Effekte vorgestellt, die Szenen und Assets beeinflussen; damals hätte man sich nicht einmal vorstellen können, dass so etwas in Echtzeit möglich wäre.
    Ich weiß nicht einmal mehr, ob es in diesem Bereich noch möglich ist, ein „ordentlicher Experte“ zu werden. Anders gesagt: Die Frage lautet: „Wo ist der heutige John Carmack?“ Er wurde berühmt, weil er Hardware bis zum Letzten ausreizte und Ideen nutzte, die in der Community verborgen waren, aber heute scheint so jemand keinen Competitive Moat mehr zu haben. Das Feld ist zu breit und verändert sich zu schnell, als dass es noch die Chance gäbe, der nächste Carmack zu werden.

    • Ich hasse diese Haltung, in ein Feld einzusteigen und dann anderen davon abzuraten, wirklich. „Werde nicht wie ich, ich habe mein Leben verschwendet“ ist eher das Gerede von jemandem, der seine Leidenschaft verloren hat und ausgebrannt ist; und anderen zu sagen, sie sollten Grafikprogrammierung meiden, ist nicht der Weg, den John Carmack von morgen anzuziehen.
      Es gibt auch eine andere Perspektive. Wenn man bisher nur Web-Apps und Kubernetes gemacht hat, ist es eher eine gute Idee, Grafikprogrammierung auszuprobieren. Die Feedback-Loop ist berauschend, und man bekommt ein Gefühl dafür, wie absurd schnell ein gewöhnlicher Computer ist. Selbst wenn man am Ende Optimierungen vornimmt, die nicht wichtig sind, ist es wertvoll, weil man sonst nie gelernt hat, wie schnell Dinge auf niedriger Ebene sein können.
      Es gibt viele Materialien, und die Mathematik ist auch nicht übermäßig schwierig. 3D-Modellierung kann ein kreativer Ausweg sein, von dem man gar nicht wusste, dass man ihn hat. Selbst wenn es im Hauptberuf überhaupt nicht anwendbar ist, gewinnt man eine neue Wertschätzung für die Kunst des Computerprogrammierens, und vielleicht entscheidet man sich, Kubernetes nie wieder anzufassen und fünf Jahre Freizeit in die eigene Game Engine zu stecken.
      Von solchen Verrückten gibt es viele, und die Community der Hobbyentwickler, die nicht durch professionelle Spieleentwicklung aufgerieben wurde, ist größer, als man denkt. Auch der Graphics Programming Discord ist ein einladender Ort, den man sich ansehen kann. Einfach ausprobieren.
    • Computergrafik ist im Kern interessant und lohnend. Sie liegt an der Schnittstelle mehrerer wichtiger Bereiche wie Informatik, Mathematik, theoretische Physik und Low-Level-Programmierung.
      Für jemanden, dem es egal ist, was er konkret macht, und der nur einen Karrierewechsel will, kann der Rat, es zu meiden, richtig sein. Aber so zu leben ist kein guter Weg. Besser ist es, dem zu folgen, was man interessant und wertvoll findet, ständig Neues zu lernen und sich selbst herauszufordern. Dann wird relativ klar, ob man Computergrafik lernen sollte oder nicht, und für die passenden Leute ist es ein Nettogewinn. Selbst wenn daraus kein Beruf wird, lassen sich die Fähigkeiten gut auf viele andere Bereiche übertragen.
    • Grafikprogrammierung hat heute einen nützlichen Aspekt, der exponentiell wertvoller ist: Die Matrixalgebra-Pipeline und das „Denken in Matrixtransformationen“ sind eine hervorragende und visuell fesselnde Methode, um die Grundlagen der Mathematik für Machine Learning zu legen.
    • Was ist mit Leuten wie Inigo Quilez? Ich finde, er ist auch heute eine Person, die genügend Aufmerksamkeit bekommt. Und inzwischen gibt es im gesamten Feld viel mehr Menschen, sodass nicht alle berühmt werden können.
      Es ist okay, nicht so berühmt zu sein wie eine der bekanntesten Personen eines Fachgebiets; man kann es auch einfach machen, weil es Spaß macht. Die Mathematik und Kunst von Grafik- und Spieleprogrammierung sind an sich schön.
    • Stimmt. Die meisten der cleveren Techniken, durch die Carmack berühmt wurde, sind von Software in Hardware gewandert.
      Mein Grund, nicht in die Grafikprogrammierung einzusteigen, ist ein anderer. Werden 3D-Engines mit Vertices und Texturen in ein paar Jahren noch existieren? Oder wird alles direkt von KI-Weltmodellen gerendert werden? Wie viel Code wird in Spielen stecken, oder werden sie als Abfolge klug geschriebener Prompts existieren?

  • Wenn du ein schnelles Tutorial zu linearer Algebra brauchst, kannst du dir mein druckbares vierseitiges ansehen: https://minireference.com/static/tutorials/linear_algebra_in...
    Ein Notebook mit SymPy-Codebeispielen gibt es hier: https://github.com/minireference/noBSLAnotebooks

    • Wenn du ein längeres Tutorial brauchst, empfehle ich die Reihe von 3b1b sehr: https://youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFit...
      Durch die Visualisierungen haben Dinge, die mir im Linear-101-Kurs nicht klar wurden, plötzlich Klick gemacht.
    • Auch ästhetisch ist es wirklich schön. Es ist immer schade, wenn schöne Mathematik mit schlechter Typografie und hässlichen Abständen präsentiert wird.

  • Ich bin ein wenig überrascht, dass es keine Diskussion über grundlegende Designprinzipien oder Eigenschaften der menschlichen Wahrnehmung gibt.
    Mein Bruder war Production Artist bei bekannten Computerspielen der 90er- und 00er-Jahre und hat sich ständig über Programmierer und Manager beschwert, die kein visuelles Gespür hatten und keinerlei Neugier dafür zeigten, die Künstlerseite zu verstehen.
    Grafik ist nicht mein Fachgebiet, aber als Musiker, Sounddesigner und Produzent weiß ich: Die effektivsten und einflussreichsten Audio-DSP-Coder, die ich kenne, verstehen die Grundlagen von Musik, die Physik und Akustik von Klang sowie die Fallstricke zwischen diskreter digitaler Verarbeitung und der Art, wie wir Reize wahrnehmen und interpretieren.

    • Es gibt eine eigene Rolle, die näher an dem liegt, was du beschreibst; sie heißt Technical Artist. Das ist auch das, was ich mache.
      Es hilft, wenn Grafikprogrammierer eine künstlerische Denkweise haben, aber normalerweise arbeiten sie auf ziemlich niedriger Ebene, daher ist das für Erfolg nicht zwingend erforderlich.
    • Außerhalb der Kreativbranche gilt genau dasselbe. Auch bei B2B-/Enterprise-Software habe ich ziemlich viele Anbieter gesehen, die überhaupt nicht verstehen, wie die Branche funktioniert, an die sie verkaufen, oder wie die Nutzer denken.
      KI hat die Rechnung ein wenig verändert oder hat zumindest das Potenzial dazu, aber ich denke, dass auch die „Learn to code“-Welle Mitte der 2000er zu einem erheblichen Teil damit zu tun hatte. Es ging darum, Softwareentwicklung wie eine „Funktion, nicht ein Produkt“ bestehender Fachexperten zu behandeln, sodass die Leute, die die Domäne am besten kennen, Software direkt bauen, statt Anforderungen an ein Entwicklungsteam zu übersetzen.
    • Stimme zu 100 % zu. Gute Grafikprogrammierer arbeiten mit Tech Artists und Artists zusammen.
      Ehrlich gesagt ist Grafikprogrammierung meistens eher eine Service-Rolle, die es diesen Leuten ermöglicht, das zu tun, was sie tun wollen, oder ihnen hilft, das zu schaffen, was sie sich vorstellen.
      Inigo Quilez wird als Beispiel für jemanden genannt, der sowohl Grafikprogrammierer als auch Künstler ist; er ist wirklich eine starke, fast einhornartige Person.

Ich persönlich mag Musizieren und Audioprogrammierung lieber; das ist auch eine gute Grundlage, um DSP zu lernen. Wenn man zum Beispiel Rendering-Rauschen in den Hochfrequenzbereich verschiebt, kann ein Tiefpassfilter manchmal effektiver beim Entfernen des Rauschens sein.

  • Die Liste, die ich erstelle und pflege, ist hier: https://legends2k.github.io/note/cg_resources/
    Wenn du neugierig bist und Zeit hast, lohnt es sich, das zu lernen. Es macht wirklich Spaß, man lernt sehr viel, und es macht einen auch in vielen anderen Bereichen der Informatik zu einem besseren Engineer. Man versteht Hardware, Systemprogrammierung, das Maschinenmodell des Programmierers usw.
    Wenn Geld aber dein Endziel ist, lern es lieber nicht. In der heutigen Zeit ist die Belohnung dafür flüchtig, vorübergehend und nicht garantiert.
  • „Unter 25 sein und viel Zeit dafür haben“ sollte vermutlich auch dazugehören.
    Ich interessiere mich schon lange für Grafikprogrammierung und habe vor ein paar Jahren angefangen, mir Vulkan selbst beizubringen. Ich weiß nicht, wie viel Zeit ich insgesamt investiert habe, aber es waren ungefähr sechs Monate freie Abende, vielleicht etwas weniger. Ich habe etwas gebaut, das einem Rendering-Framework nahekam.
    Aber das ist so eine Sache, bei der man umso mehr merkt, wie viel man nicht weiß, je weiter man kommt. In dem Moment, in dem sich die Struktur endlich okay anfühlt, stellt man fest, dass es nicht die richtige Architektur ist.
    Am Ende ist das, was man tut, im Grunde angewandte Beleuchtungsmathematik, der Rest ist Klempnerarbeit. Man denkt: „Warum geht der Spot einfach durch den Würfel hindurch?“, merkt dann, dass man Schatten berechnen muss, und verbringt Wochen damit, herauszufinden, wie man das in die Render-Pipeline einbaut. Wenn man so etwas mag, ist es trotzdem ziemlich „spaßig“.
    • Leider ist Vulkan eine wirklich schmerzhafte Art, Grafikprogrammierung zu lernen. Für fast alles braucht man Unmengen an Boilerplate-Code.
      Selbst beim Erzeugen von Schatten muss man zum Beispiel zehnmal so viel Code schreiben, wie die Technik an sich eigentlich erfordern würde.
      Um Grafikprogrammierung zu lernen, halte ich es für deutlich angenehmer, einen Software-Renderer zu schreiben. Es ist weniger Code, und der Code, den man schreibt, ist keine Boilerplate, sondern geht an den Kern der Sache. Der Nachteil ist, dass man die Hardwarebeschleunigung verliert und es dadurch langsamer wird.
  • Es hängt davon ab, was du machen willst.
    Wenn du einfach nur Spiele machen möchtest, kannst du eine Game Engine wie Unity, Godot oder Unreal verwenden.
    Wenn du Grafik im Sinne von Engines, Simulationen oder Renderern machen willst, musst du Low-Level-Sprachen und Grafik-APIs lernen. Als Sprache würde ich C++ empfehlen; C oder Rust gehen auch, aber C ist etwas schwierig, und die Grafik-API selbst ist schon schwer genug, da will man nicht auch noch mit der Sprache kämpfen. Rust kann ebenfalls eine gute Wahl sein, aber persönlich empfinde ich die Kompilierzeiten als sehr langsam und die Syntax als hässlich.
    Als API empfehle ich OpenGL. Es ist plattformübergreifend und alt; das ist zugleich ein Vor- und Nachteil, und von ihnen ist es die einfachste.
    learnopengl.com ist mit Abstand das beste OpenGL-Tutorial, daher würde ich empfehlen, es durchzuarbeiten.
    Nachdem du eine Weile OpenGL verwendet hast, kannst du zu Vulkan oder zu Grafikbibliotheken übergehen, die mehrere APIs implementieren; wenn es für dich passt, kannst du auch einfach bei OpenGL bleiben.
    Leicht ist es definitiv nicht, aber ich halte es für eines der faszinierendsten Gebiete der Informatik.
  • Ich habe A-Frame (aframe.io) entwickelt und pflege es immer noch. In den letzten zehn Jahren war es ein sanfter Einstieg ins Lernen von 3D-Grafik.
    Es ist etwas unangenehm, das selbst zu sagen, aber die Community ist auch großartig. Das Web ist eine gute Möglichkeit, beim Lernen das zu teilen, was man gebaut hat, Feedback zu sammeln und Sichtbarkeit zu bekommen. Auch innerhalb der Community gibt es viele Fälle, in denen Leute beruflich in 3D-Grafik eingestiegen sind.
    • Ich habe meine Masterarbeit mit A-Frame geschrieben. Damals war ich kein Programmierer und hatte fast keine Erfahrung, aber dank A-Frame konnte ich meine Ideen wirklich intuitiv umsetzen.
      Wenn ich gelegentlich ins Repository schaue, ist mir der damalige Code so peinlich, weil er so chaotisch ist, aber ohne dieses Projekt wäre ich wohl nicht dort, wo ich heute bin.
    • Kann ich definitiv empfehlen.
      Man kann mit einfachen Tags anfangen, Animationen hinzufügen und, wenn das nicht reicht, Community-Komponenten ergänzen. Wenn das immer noch nicht reicht, kann man mit ThreeJS anpassen und bis zu Shadern gehen. A-Frame ist großartig.
      Außerdem kann man damit auch AR und VR machen.
  • Es fühlt sich so an, als wollten wir alles, was wir tun, in eine Karriere oder einen Beruf verwandeln, besonders wenn dann noch diese seltsame Machine-Learning-Perspektive dazukommt.
    Wie wäre es, statt „Grafikprogrammierer zu werden“ einfach Grafikprogrammierung zu machen? Man probiert mit einfachen Dingen herum, bekommt ein Gefühl dafür, und sobald man sieht, dass es letztlich darum geht, Logistik an die GPU zu schicken, kann man darauf alle möglichen komplexen Konzepte aufbauen.
    Es ist ein bisschen so, als würde man einen kleinen Berg erklimmen, und plötzlich passt alles zusammen und man denkt: „Wow …“. Dann sieht man die Möglichkeiten und all die Dinge, mit denen man experimentieren kann.
    • Ich sehe diese Formulierung nicht unbedingt als Karriere- oder Berufsbezeichnung. Eher geht es um Identität.
      Aussagen wie „Ich bin Kletterer“, „Gamer“, „Künstler“, „Mutter“, „Vater“, „Fitnessstudio-Dauergast“, „Grafikprogrammierer“ meinen nicht unbedingt einen Beruf, deuten aber auf etwas Tieferes hin als nur eine flüchtige, lockere Beschäftigung.
  • Ich habe dieses Raytracing-Tutorial geöffnet und arbeite es langsam durch. Ich hatte schon lange Interesse daran, bin aber nie dazu gekommen.
    Heute habe ich das PPM-Bildformat kennengelernt, und für solche Zwecke ist es sehr zugänglich. Eine Bitmap zu schreiben ist zwar auch keine Raketenwissenschaft, aber PPM ist noch einfacher.