Apa yang Perlu Dipelajari untuk Menjadi Programmer Grafis

• Kompetensi perekrutan untuk grafis real-time menuntut kombinasi API grafis eksplisit di sisi CPU dan pencahayaan serta shading di sisi GPU, dan sulit untuk mempelajari keduanya secara mendalam pada saat yang sama
• Sisi CPU mencakup API modern seperti DirectX12, Vulkan, dan Metal, serta pemuatan aset dan pekerjaan pendukung engine; sisi GPU mencakup bayangan, ambient occlusion, post-processing, dan karakteristik performa GPU
• Fokus pembelajaran GPU adalah menulis path tracer dan memahami PBR; Ray Tracing in One Weekend, LearnOpenGL PBR, dokumentasi Filament, dan PBRT bisa menjadi titik awal
• Portofolio yang ideal menunjukkan pengetahuan melalui renderer real-time berbasis C++, path tracer yang menghasilkan gambar fotorealistis, serta kode yang membandingkan dan memverifikasi hasil kedua rendering tersebut
• Matematika yang dibutuhkan terutama aljabar linear, trigonometri dasar, dan sedikit kalkulus; bahasa sisi CPU untuk pengembangan game adalah C++, dan bahasa shader yang paling umum adalah HLSL

---

Grafis real-time mencakup dua area: CPU dan GPU

• Rendering modern pada dasarnya lebih mirip gabungan dua jenis pekerjaan
  • Pembelajaran sisi CPU: API eksplisit modern seperti DirectX12, Vulkan, dan Metal, serta pemrograman engine untuk pemuatan aset dan pekerjaan pendukung lainnya
  • Pembelajaran sisi GPU: matematika pencahayaan dan shading modern, bayangan, ambient occlusion, efek post-processing, serta perbedaan antara pekerjaan yang cepat dan lambat di GPU
• Sangat sulit mempelajari kedua area ini secara bersamaan
  • Jika ingin fokus pada sisi GPU, Anda bisa memakai alat dengan beban sisi CPU lebih rendah seperti OpenGL, WebGL, DirectX11, atau engine yang sudah ada
  • Jika ingin fokus pada sisi CPU, mulailah dengan menampilkan segitiga di layar, lalu lanjutkan dengan menampilkan mesh, tanpa perlu terlalu memikirkan apakah hasilnya terlihat indah

Path tracing dan PBR

• Pembelajaran sisi GPU mencakup penulisan path tracer
  • Path tracing adalah metode yang digunakan dalam rendering film, dan menjadi target yang berusaha didekati oleh teknik rendering real-time modern
  • Sebagai materi awal, buku online gratis Ray Tracing in One Weekend cocok digunakan; materinya mudah didekati dan menunjukkan proses membuat rendering yang tampak seperti foto
• Physically Based Rendering(PBR) adalah cara penerapan pencahayaan, khususnya specular
  • PBR adalah pendekatan berbasis prinsip: jika aturannya diikuti, hasilnya akan bagus
  • Sebelum PBR, pencahayaan banyak menggunakan rumus, penyesuaian, dan hack yang arbitrer, sehingga aset yang terlihat bagus di satu lingkungan pencahayaan bisa terlihat terlalu gelap atau terlalu mengilap di lingkungan lain
  • Akibatnya, perlu dibuat versi aset yang berbeda untuk tiap kondisi pencahayaan, yang memakan banyak waktu dan usaha
• PBR membuat aset tampak lebih konsisten di berbagai kondisi pencahayaan, serta mengurangi waktu dan usaha untuk membuat aset per versi
  • Meski begitu, waktu, biaya, dan usaha pembuatan aset masih menjadi bottleneck besar dalam pengembangan game

Materi belajar yang direkomendasikan

• Untuk pengantar PBR, bagian PBR Theory dari LearnOpenGL beserta subbagiannya cocok digunakan
• Untuk masuk lebih dalam, dokumentasi Filament bisa menjadi langkah berikutnya
  • Semakin mendalam mempelajari PBR, semakin banyak kalkulus dan statistik yang muncul
• Lebih jauh lagi, ada buku online gratis Physically Based Rendering: From Theory To Implementation
• Machine learning saat ini dipandang belum akan memberikan hasil sebesar hype-nya, tetapi tetap berharga untuk mempelajari teknik fitting dan optimisasi sebagai bagian dari perangkat ilmu komputer
  • Sebagai materi terkait, Anda bisa merujuk video Machine Learning For Game Developers

Kode yang layak ditampilkan sebagai portofolio

• Untuk membuktikan pengetahuan kepada perekrut, idealnya sediakan source code yang bisa dibagikan di tempat seperti GitHub dan tautkan dari CV
• Contoh portofolio:
  • Renderer bergaya engine yang memuat aset seperti model dan tekstur, lalu merendernya secara real-time di layar
    • Mencakup beberapa efek seperti pencahayaan dan bayangan, depth of field, area lights, tone mapping, dan ray traced shadows
    • Jika memungkinkan, gunakan pencahayaan berbasis PBR, kamera yang bisa dikendalikan pengguna, API seperti DX12 atau Vulkan, dan C++
  • Path tracer yang menghasilkan gambar seperti foto
    • Jika memungkinkan, C++ lebih baik, tetapi program tanpa jendela yang hanya menghasilkan PNG juga tidak masalah
    • Tidak perlu berjalan real-time
  • Akan lebih baik jika path tracer menjadi mode terpisah dari renderer bergaya engine
    • Anda dapat membandingkan hasil path traced dengan rendering PBR real-time untuk memverifikasi akurasinya
    • Jika Anda bisa menunjukkan titik di mana kedua rendering tidak cocok, menjelaskan alasannya, dan memikirkan cara membuatnya lebih mendekati sambil tetap mempertahankan real-time, nilainya akan lebih tinggi

Matematika, algoritme, dan pilihan bahasa

• Jika mencoba langsung hal-hal di atas, Anda akan secara alami bertemu matematika yang dibutuhkan
  • Pada dasarnya yang diperlukan adalah perkalian matriks dalam aljabar linear, cross product, dot product, trigonometri dasar, dan sedikit kalkulus
  • Dalam grafis dan pengembangan game, kebutuhan minimum matematikanya relatif kecil, tetapi ruang lingkup matematika yang bisa dimanfaatkan pada dasarnya tidak terbatas
• Algoritme juga serupa
  • Anda perlu memahami tipe data abstrak dan algoritme dasar seperti linked list, hash table, sorting, dan searching
  • Algoritme tercepat sering kali sederhana, dan array jauh lebih cepat daripada linked list
  • Konsep algoritme yang lebih lanjut akan membantu ketika benar-benar diperlukan sesuatu yang baru dan khusus
• Bahasa yang perlu dipelajari untuk pengembangan game adalah C++
  • Ada orang yang memakai Rust dan ada sebagian pangsanya, tetapi itu bukan bahasa standar yang diharapkan orang
  • WebGPU memiliki banyak fitur yang tidak ada di WebGL dan sedang menjadi platform yang lebih serius, serta memungkinkan pekerjaan sisi CPU dilakukan dengan JavaScript
  • Namun, belum banyak terlihat lowongan WebGPU dan konten WebGPU di web
• Bahasa shader yang paling umum adalah HLSL
  • Sebagian menggunakan GLSL
  • Dalam game multiplatform, shader sering dikonversi ke bahasa shader lain

Ruang lingkup penggunaan LLM dan ML

• Teknologi ML saat ini dipandang belum cukup baik untuk sebagian besar penggunaan yang dijual kepadanya
• Claude berguna untuk membicarakan matematika, makalah, dan algoritme yang belum familier
  • Dalam situasi seperti ini, lebih mudah memeriksa apakah ia mengarang, dan juga lebih mudah memeriksa validitasnya dengan sumber lain
• Untuk pemrograman, tidak terlalu berguna
  • Bahkan jika menghasilkan kode yang berjalan sesuai keinginan, tetap perlu meluangkan waktu untuk memahami kode tersebut
  • Jika begitu, lebih baik menulisnya sendiri
• Penggunaan kecil bisa berguna
  • Misalnya, jika bertanya “apakah terlihat ada bug di file ini?”, saat jawabannya ya Anda bisa menyelidikinya, dan kalau jawabannya tidak biaya untuk bertanya hampir nol
• Diyakini bahwa suatu hari umat manusia akan membuat kecerdasan buatan setingkat manusia dan melampauinya, tetapi tidak diketahui apakah momen itu akan terjadi semasa hidup kita
  • Era LLM saat ini lebih mirip latihan awal untuk saat ketika yang “sebenarnya” nanti hadir

[GN⁺]

Pendapat Hacker News

• Pertama-tama harus dibedakan dulu apakah yang ingin dilakukan adalah membuat game, atau melakukan pemrograman engine 3D
  Jika ingin membuat game, lebih baik memakai engine yang sudah ada seperti Unreal Engine, Unity, Godot, atau Bevy, dan yang dipelajari pun akan lebih ke persoalan grafis tingkat tinggi daripada cara mendorong piksel secara langsung. Bagian yang benar-benar sulit adalah membuatnya menjadi menyenangkan
  Jika ingin membuat engine 3D, perlu disadari bahwa sudah terlalu banyak game engine buruk di luar sana. Bahkan di ekosistem Rust saja, proyek utamanya adalah 3 renderer yang gagal, 1 renderer yang belum selesai, dan renderer di dalam Bevy, sementara proyek dengan slogan “akan membuat game engine” jauh lebih banyak. Bahkan untuk mencapai level “renderer pertama” saja butuh sekitar 2 tahun, dan untuk sampai ke adegan yang besar, detail, dan dinamis, skalanya jauh lebih besar lagi
  Jika tujuannya mencari kerja, industri game punya gaji dan jam kerja yang kurang baik, dan ketika proyek selesai, pekerjaannya juga sering ikut selesai, sementara seperti Hollywood, jumlah orang yang ingin masuk sangat banyak. Ditambah lagi, setelah runtuhnya Metaverse, sekarang bahkan tenaga berpengalaman pun berlebih
  Mobile adalah pekerjaan kompresi serba terbatas: layar, daya komputasi, GPU, dan baterai semuanya kurang, jadi kebanyakan game indie belakangan ini adalah 2D. Itu yang paling memungkinkan, dan sering juga dibuat dengan HTML/JavaScript

  • Tampaknya ada asumsi bahwa kebanyakan orang mencoba bersaing secara visual dengan Unreal, dan itu jelas hampir mustahil
    Tetapi membuat renderer dasar dan game loop sebenarnya tidak sesulit itu, dan kemungkinan besar juga bukan menjadi mayoritas kode game. Untuk game sederhana, cukup dengan for loop dan drawObject() saja pun bisa, dan kekhawatiran seperti streaming resource, optimasi binding, atau paralelisme bisa dipikirkan nanti saat memang diperlukan
    Saya penasaran titik awal dan syarat keberhasilan seperti apa yang diasumsikan oleh patokan “2 tahun sampai renderer pertama”. Sekitar setahun yang lalu, saya membuat deferred renderer dengan pencahayaan dinamis, shadow mapping, dan beberapa post-processing dalam waktu sekitar satu bulan waktu luang, atau bahkan kurang dari satu minggu jika dihitung sebagai kerja penuh waktu
    Tidak ada alasan untuk memandang rendah 2D. Banyak pekerjaan serius justru dilakukan di antarmuka 2D, dan WebGL maupun canvas 2D lama pun sekarang cukup kuat. Banyak game indie yang sukses juga merupakan game 2D
    Benar bahwa industri game kurang bagus, tetapi sekarang hampir semua hal memakai GPU. Menulis dan men-debug pekerjaan machine learning, visualisasi data, HUD, maupun antarmuka pengguna umum juga sering membutuhkan pemahaman grafis
  • Rata-rata industri game mungkin kurang bagus, tetapi menurut saya ceruk pemrograman grafis tidak demikian
    Selain game, ada jauh lebih banyak bidang yang memakai grafis, seperti visualisasi dan simulasi, dan programmer grafis yang bagus sangat langka, jadi ini justru karier yang lumayan baik secara tak terduga. Ini cukup kontras dengan kesan bahwa jauh lebih sulit bagi game developer atau artis untuk mendapatkan pekerjaan yang bagus. Hanya saja, karena baik permintaan maupun pasokannya kecil, pindah kerja mungkin tidak semudah itu
    Jika dilihat dari stabilitas karier semata, saya tidak ingin menyarankan pengembangan game sebagai karier, tetapi pemrograman grafis berbeda
  • Saya menyayangkan terlalu banyak game yang sebenarnya bagus malah mengalami masalah performa karena Unity atau Unreal Engine. Rasanya saya tidak ingin merekomendasikan ini, dan saya juga belum tahu apakah Godot dan Bevy lebih baik
    Dalam beberapa tahun terakhir, game yang saya mainkan dengan masalah performa berat antara lain Core Keeper (Unity), WORMHOLE (Unity, terutama lag di mode tak terbatas), dan Crab Champions (UE4, harus memakai upscaling yang membuat tampilannya jelek agar tetap 60fps di 1920x1200)
    Sebaliknya, Terraria, Necesse, dan Barony memakai engine buatan sendiri dan berjalan sangat baik, bahkan terasa makin bagus seiring usia
    Agar adil, Tiny Rogues (Unity) setidaknya dalam ingatan saya kebanyakan berjalan baik, tetapi developernya sedang berupaya keluar dari Unity ke depannya, jadi tampaknya mereka sendiri juga menemukan masalah
    Saya paham perbedaan antara membuat game dan membuat engine, serta pentingnya benar-benar menyelesaikan dan merilis sesuatu, tetapi kalau yang dirilis adalah sampah, sulit meninggalkan warisan yang baik. Menurut saya lebih baik mengambil jalan memutar sejauh apa pun asalkan kualitas pada tingkat tertentu bisa terjamin. Game kadang dimainkan sampai puluhan tahun setelah rilis, dan jika ada bug atau lag, orang-orang akan terus mengalaminya
  • Begitu mulai membuat engine, apalagi sambil belajar, besar kemungkinan game-nya justru tidak akan pernah selesai. Secara teknis memang mungkin berhasil melakukan keduanya, tetapi dari pengalaman pribadi dulu dan melihat puluhan orang di komunitas pengembang game hobi Polandia, peluang suksesnya terasa mendekati kurang dari 5%
    “Saya akan membuat engine untuk game saya sendiri dulu agar game berikutnya lebih mudah dibuat” adalah jebakan yang luar biasa kuat. Soalnya kita benar-benar belajar hal penting dan mendapat kemenangan kecil setiap hari. Menambah satu unroll lagi agar adegan tampak mulus, menambah satu lapisan logika lagi pada format konfigurasi agar adegan lebih mudah dibuat, lalu membaca satu makalah SIGGRAPH lagi
    Selalu ada hal penting yang bisa diperbaiki, tetapi semua itu tidak pernah benar-benar menyatu menjadi game yang selesai. Kalau dipikir-pikir, memakai engine buatan sendiri adalah cara sempurna bagi orang teknis untuk menunda bagian sulit namun perlu dari game impiannya, yaitu “membuatnya menyenangkan”. Kita memang belajar keterampilan untuk mengoding video game yang mengesankan, tetapi tidak belajar cara membuat game
    Ada juga jebakan turunannya. Kita bisa belajar seratus cara membuat efek visual indah yang berjalan mulus secara real-time, tetapi tidak belajar cara memakainya sebagai seni
    Ini juga sangat mirip dengan jebakan “Enterprise Java”. Hanya saja, karena berurusan dengan istilah yang konkret, jebakannya lebih licik. Kita mungkin merasa sudah lolos dari peluru itu karena Scene Graph tidak punya Factory Factory Interface, tetapi justru luput melihat bahwa untuk sekadar menampilkan bitmap di layar dan membuatnya merespons tombol, semua itu sebenarnya tidak perlu
  • Saya tidak sepenuhnya setuju bahwa kalau ingin membuat game maka harus selalu memakai engine yang sudah ada. Dalam kebanyakan kasus itu memang nasihat yang bagus, tetapi engine yang ada terlalu serbaguna dan memuat terlalu banyak asumsi tentang game. Bisa saja game yang dibuat membutuhkan batasan yang berbeda
    Terutama di 2D, hal ini terasa benar. Misalnya saya sedang membuat game dengan engine buatan sendiri, dengan fokus pada performa dan kompresi, serta arsitektur tanpa server atau database
    Engine ini memiliki struktur dan asumsi yang sangat spesifik tentang struktur game demi mencapai performa dan kompresi ekstrem di dalam batasan yang saya tetapkan. Saya berencana menulis posting Hacker News terkait ini sebentar lagi, semoga minggu depan
    Sebelumnya saya juga beberapa kali mencoba membuat game browser dengan Unity, Godot, dan React, tetapi mempelajari API-nya terasa menyiksa, dan engine-engine itu tidak memenuhi batasan ekstrem yang saya butuhkan. Tentu saja mungkin itu juga karena saya kurang mahir memakainya, tetapi kalau melihat kembali, saya rasa apa yang berhasil saya capai secara internal memang mustahil tanpa engine kustom yang dibuat dari nol
    Dengan membuat engine dan game sendiri, saya belajar sangat banyak, dan khususnya sekarang, berkat LLM, saya merasa bagi developer berpengalaman, membuat game engine yang benar-benar disesuaikan sendiri tiba-tiba menjadi sesuatu yang realistis untuk dijangkau oleh kebanyakan developer

• Kalau sekarang, saya tidak akan merekomendasikan siapa pun untuk masuk ke pemrograman grafis
  Saya mulai saat GeForce 1 pertama dari Nvidia, yang disebut “Gigatexel shader card”, diumumkan pada 2001, dan sejak itu kecepatan perkembangan serta inovasi di bidang ini benar-benar mencengangkan. Dibandingkan 25 tahun lalu, teknologi sekarang benar-benar luar biasa
  Tapi ada satu “tetapi” besar dalam kekaguman itu. Bidang ini berkembang dengan kecepatan yang nyaris menakutkan. Nvidia bahkan sudah merilis efek berbasis AI yang memengaruhi adegan dan aset, dan dulu saya sama sekali tidak membayangkan hal seperti ini bisa dilakukan secara real-time
  Sekarang saya bahkan tidak tahu apakah masih mungkin menjadi “ahli yang lumayan” di bidang ini. Dengan kata lain, pertanyaannya adalah “di mana John Carmack zaman sekarang?” Dia terkenal karena memeras kemampuan hardware sampai batasnya dan memakai ide-ide yang tersembunyi di komunitas, tetapi sekarang tampaknya tidak ada parit pertahanan kompetitif bagi orang seperti itu. Bidangnya terlalu luas dan berubah terlalu cepat, sehingga tidak ada kesempatan untuk menjadi Carmack berikutnya

  • Saya benar-benar tidak suka sikap orang yang sudah masuk ke suatu bidang lalu melarang orang lain ikut masuk. “Jangan jadi seperti saya, saya membuang hidup saya” terdengar seperti omong kosong dari orang yang sudah kehilangan gairah dan kelelahan, dan menyuruh orang menjauhi pemrograman grafis bukanlah cara untuk menarik John Carmack masa depan
    Ada sudut pandang lain juga. Kalau sejauh ini Anda hanya pernah mengerjakan web app dan Kubernetes, justru bagus mencoba pemrograman grafis. Feedback loop-nya sangat memacu adrenalin, dan Anda jadi benar-benar merasakan betapa tidak masuk akalnya cepatnya komputer biasa. Pada akhirnya Anda mungkin tetap melakukan optimisasi yang sebenarnya tidak penting, tetapi itu tetap bernilai karena Anda belum pernah belajar seberapa cepat benda-benda bekerja di level rendah
    Materinya juga banyak, dan matematikanya tidak terlalu sulit. Pemodelan 3D juga bisa menjadi jalur kreatif yang sebelumnya tidak Anda sadari. Meskipun sama sekali tidak terpakai di pekerjaan utama, Anda akan mengapresiasi kembali seni pemrograman komputer, dan mungkin memutuskan untuk tidak pernah menyentuh Kubernetes lagi lalu menghabiskan 5 tahun waktu luang untuk menulis game engine sendiri
    Orang-orang segila itu cukup banyak, dan komunitas pengembang hobi yang belum habis digerus oleh pengembangan game profesional lebih besar daripada yang dibayangkan. Graphics Programming Discord juga ruang yang ramah dan layak dicek. Coba saja
  • Grafika komputer pada dasarnya menarik dan memuaskan. Ia berada di persimpangan banyak bidang penting seperti ilmu komputer, matematika, fisika teoretis, dan pemrograman level rendah
    Bagi orang yang tidak peduli benar-benar mengerjakan apa dan hanya ingin pindah karier, saran untuk menghindarinya mungkin benar. Tapi hidup dengan cara seperti itu bukanlah pendekatan yang baik. Lebih baik mengikuti hal yang menurut Anda menarik dan bernilai, terus belajar hal-hal baru, dan menantang diri sendiri. Dengan begitu, keputusan apakah Anda perlu belajar grafika komputer atau tidak akan menjadi relatif jelas, dan bagi orang yang cocok itu akan memberi manfaat bersih. Walaupun tidak menjadi profesi, keterampilannya sangat mudah ditransfer ke banyak bidang lain
  • Ada satu sisi berguna dari pemrograman grafis yang saat ini nilainya secara eksponensial lebih tinggi. Pipeline aljabar matriks dan “berpikir dalam transformasi matriks” adalah cara yang sangat baik dan imersif secara visual untuk membangun fondasi matematika machine learning
  • Bagaimana dengan orang seperti Inigo Quilez? Menurut saya dia masih cukup menonjol bahkan sekarang. Dan sekarang memang ada jauh lebih banyak orang di seluruh bidang ini, jadi tidak semua orang bisa menjadi terkenal
    Tidak apa-apa kalau Anda tidak seterkenal salah satu orang paling dikenal di suatu bidang; Anda juga boleh melakukannya hanya karena menyenangkan. Matematika dan seni dalam pemrograman grafis serta game itu indah dengan sendirinya
  • Betul. Sebagian besar teknik cerdas yang membuat Carmack terkenal sudah berpindah dari software ke hardware
    Alasan saya untuk menyarankan agar tidak masuk ke pemrograman grafis berbeda. Apakah engine 3D dengan vertex dan tekstur masih akan ada beberapa tahun lagi? Atau akankah semuanya dirender langsung oleh model dunia AI? Akan ada berapa banyak kode di dalam game, atau apakah game akan hadir sebagai rangkaian prompt yang ditulis dengan cerdik?

• Jika Anda butuh tutorial singkat aljabar linear, Anda bisa melihat versi cetak 4 halaman yang saya tulis: https://minireference.com/static/tutorials/linear_algebra_in...
  Ada juga notebook dengan contoh kode SymPy di sini: https://github.com/minireference/noBSLAnotebooks

  • Jika butuh tutorial yang lebih panjang, saya sangat merekomendasikan seri 3b1b: https://youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFit...
    Berkat visualisasinya, hal-hal yang dulu tidak saya pahami di kelas Linear 101 jadi langsung terasa masuk akal
  • Secara estetika juga benar-benar indah. Saya selalu merasa sayang setiap kali matematika yang indah disajikan dengan tipografi yang buruk dan spasi yang jelek

• Agak mengejutkan bahwa tidak ada pembahasan tentang memahami prinsip desain dasar atau karakteristik persepsi manusia
  Kakak saya adalah production artist untuk game komputer terkenal pada era 90-an hingga 2000-an, dan dia terus mengeluhkan para programmer dan manajer yang tidak punya selera visual dan tidak punya rasa ingin tahu untuk memahami sisi artis
  Grafis bukan keahlian saya, tetapi sebagai musisi, sound designer, dan produser, para coder audio DSP paling efektif dan paling berpengaruh yang saya kenal memahami dasar-dasar musik, fisika suara dan akustik, pemrosesan digital diskret, serta jebakan antara cara kita mempersepsikan dan menafsirkan rangsangan

  • Sebenarnya ada peran terpisah yang lebih dekat dengan hal yang Anda sebutkan, yaitu technical artist. Itu juga pekerjaan saya
    Akan membantu jika programmer grafis punya pola pikir artistik, tetapi karena mereka biasanya bekerja di level yang cukup rendah, itu umumnya bukan syarat mutlak untuk sukses
  • Hal yang sama berlaku juga di luar industri kreatif. Bahkan di software B2B/enterprise, saya cukup sering melihat vendor yang sama sekali tidak paham bagaimana industri target mereka berjalan atau bagaimana pengguna berpikir
    AI mungkin sudah sedikit mengubah hitung-hitungan itu, atau setidaknya punya potensi untuk mengubahnya, tetapi saya rasa gelombang “ayo belajar coding” pada pertengahan 2000-an juga sebagian besar didorong alasan ini. Itu adalah gerakan untuk memperlakukan pengembangan software bukan sebagai “produk melainkan fitur” dari para pakar bidang yang sudah ada, sehingga orang-orang yang paling memahami domain bisa langsung membuat software sendiri alih-alih menerjemahkan kebutuhan kepada tim pengembang
  • 100% setuju. Programmer grafis yang baik bekerja bersama tech artist dan artist
    Sejujurnya, pemrograman grafis pada umumnya lebih mirip peran layanan untuk memungkinkan apa yang ingin mereka lakukan, atau membantu mereka mewujudkan apa yang mereka bayangkan
    Inigo Quilez sering disebut sebagai contoh orang yang sekaligus programmer grafis dan artis, dan dia memang sosok yang sangat kuat, nyaris seperti unicorn

Secara pribadi, saya lebih menyukai bermain musik dan pemrograman audio, dan itu menjadi dasar yang baik untuk mempelajari DSP. Misalnya, jika noise rendering didorong ke frekuensi tinggi, terkadang filter low-pass lebih efektif untuk menghilangkan noise

• Daftar yang saya buat dan pelihara ada di sini: https://legends2k.github.io/note/cg_resources/
  Jika Anda penasaran dan punya waktu, ini bagus untuk dipelajari. Benar-benar menyenangkan, Anda akan belajar banyak, dan itu juga membuat Anda menjadi engineer yang lebih baik di banyak bidang lain dalam ilmu komputer. Anda jadi memahami hardware, system programming, model mesin bagi programmer, dan sebagainya
  Tapi jika tujuan akhir Anda adalah uang, lebih baik jangan mempelajarinya. Di zaman sekarang, imbalannya fana, sementara, dan tidak terjamin
  • Saya juga memakai materi ini, dan mungkin berguna untuk orang lain juga: https://owlcat.games/learning
• Sepertinya perlu juga menambahkan “berusia di bawah 25 tahun dan akan punya banyak waktu untuk dicurahkan ke sini”
  Saya sudah lama tertarik pada pemrograman grafis dan mulai belajar Vulkan secara otodidak beberapa tahun lalu. Saya tidak tahu total berapa lama, tapi kira-kira enam bulan waktu luang di malam hari, mungkin sedikit kurang dari itu. Saya berhasil membuat sesuatu yang lebih mirip framework rendering
  Tapi ini jenis pekerjaan yang semakin didalami, semakin sadar betapa banyak hal yang belum diketahui. Saat Anda merasa strukturnya sudah lumayan, Anda menemukan bahwa itu bukan arsitektur yang benar
  Pada akhirnya, pekerjaan ini pada dasarnya adalah matematika pencahayaan terapan, dan sisanya adalah plumbing. Anda melihat “kenapa spotlight ini tidak menembus kubus begitu saja?” lalu sadar bahwa Anda harus menghitung bayangan, dan kemudian Anda menghabiskan beberapa minggu mendalami cara memasukkannya ke render pipeline. Tetap saja, kalau Anda menyukai hal seperti ini, ini cukup “menyenangkan”
  • Sayangnya, Vulkan benar-benar cara yang menyakitkan untuk belajar pemrograman grafis. Untuk melakukan hampir semua hal, Anda memerlukan sangat banyak boilerplate
    Misalnya, bahkan untuk membuat bayangan pun Anda harus menulis kode 10 kali lebih banyak daripada yang secara esensial dibutuhkan oleh teknik itu sendiri
    Kalau ingin belajar pemrograman grafis, menurut saya jauh lebih menyenangkan menulis software renderer. Kodenya lebih sedikit, dan kode yang Anda tulis menyentuh inti, bukan boilerplate. Kekurangannya, Anda kehilangan hardware acceleration sehingga menjadi lebih lambat
• Tergantung Anda ingin melakukan apa
  Kalau cuma ingin membuat game, gunakan saja game engine seperti Unity, Godot, atau Unreal
  Kalau ingin mengerjakan grafis seperti engine, simulasi, atau renderer, Anda perlu mempelajari bahasa tingkat rendah dan graphics API. Untuk bahasa, saya merekomendasikan C++, dan C atau Rust juga bisa dipakai, tetapi C agak sulit, dan graphics API sendiri sudah sulit, jadi Anda mungkin tidak ingin juga harus bertarung dengan bahasanya. Rust juga bisa menjadi pilihan bagus, tetapi secara pribadi saya merasa waktu kompilasinya sangat lambat dan sintaksnya jelek
  Untuk API, saya merekomendasikan OpenGL. Ini lintas platform, sudah tua, dan itu sekaligus kelebihan dan kekurangannya, serta yang paling mudah di antaranya
  learnopengl.com sejauh ini adalah tutorial OpenGL terbaik, jadi saya sarankan untuk mengikutinya
  Setelah memakai OpenGL selama beberapa waktu, Anda bisa meluas ke Vulkan atau library grafis yang mengimplementasikan beberapa API, dan kalau cocok, Anda juga bisa terus memakai OpenGL
  Jelas ini tidak mudah, tetapi menurut saya ini salah satu bidang paling memikat dalam ilmu komputer
• Saya membuat A-Frame(aframe.io) dan masih memeliharanya sampai sekarang. Selama 10 tahun terakhir, ini telah menjadi jalur masuk yang mulus untuk mempelajari grafis 3D
  Agak canggung mengatakan ini sendiri, tapi komunitasnya juga keren. Web adalah cara yang bagus untuk belajar sambil membagikan apa yang Anda buat, mengumpulkan umpan balik, dan mendapatkan visibilitas. Di dalam komunitas juga ada banyak contoh orang yang akhirnya menekuni grafis 3D secara profesional
  • Saya menulis tesis master dengan A-Frame. Waktu itu saya bukan programmer dan hampir tidak punya pengalaman, tetapi berkat A-Frame saya bisa mewujudkan ide saya dengan sangat intuitif
    Kadang saya melihat kembali repositorinya dan malu karena kode saya saat itu benar-benar berantakan, tetapi rasanya tanpa proyek itu saya tidak akan berada di posisi saya sekarang
  • Saya pasti bisa merekomendasikannya
    Mulailah dengan tag sederhana, tambahkan animasi, lalu kalau kurang tambahkan komponen komunitas. Kalau masih kurang, ubah dengan ThreeJS, dan Anda bahkan bisa sampai ke shader. A-Frame luar biasa
    Selain itu, Anda juga bisa membuat AR dan VR
• Terasa seolah kita sedang mencoba mengubah semua yang kita lakukan menjadi karier atau pekerjaan, bahkan sampai dibumbui sudut pandang machine learning yang aneh
  Daripada “menjadi programmer grafis”, bagaimana kalau sekadar melakukan pemrograman grafis? Coba mulai dari hal sederhana, lalu ketika mulai terasa masuk akal dan Anda melihat bahwa pada akhirnya ini adalah soal mengirim logistik ke GPU, Anda bisa menumpuk berbagai konsep rumit di atasnya
  Rasanya seperti mendaki bukit kecil lalu tiba-tiba semuanya pas dan Anda berpikir “wah…”. Anda mulai melihat berbagai kemungkinan dan hal-hal untuk dieksperimenkan
  • Saya tidak melihat ungkapan itu harus berarti karier atau pekerjaan. Justru lebih dekat ke makna identitas
    Kalimat seperti “saya pemanjat tebing”, “saya gamer”, “saya seniman”, “saya ibu”, “saya ayah”, “saya penghuni tetap gym”, “saya programmer grafis” tidak selalu berarti profesi, tetapi menyiratkan sesuatu yang lebih dalam daripada keterlibatan ringan yang sekilas lewat
• Saya sedang membuka tutorial ray tracing itu dan mengikutinya perlahan-lahan. Saya sudah lama tertarik, tetapi belum sempat mencobanya
  Hari ini saya belajar format gambar PPM, dan untuk kegunaan seperti ini format itu sangat mudah diakses. Menulis bitmap bukanlah ilmu roket yang luar biasa, tetapi PPM bahkan lebih mudah daripada itu