Grafik programcısı olmak için neler öğrenmek gerekir

• Gerçek zamanlı grafik alanındaki işe alım yetkinlikleri, CPU tarafındaki açık grafik API’leri ile GPU tarafındaki aydınlatma ve shading bilgisini birlikte gerektirir; iki alanda aynı anda derinleşmek zordur
• CPU tarafı DirectX12, Vulkan, Metal gibi modern API’ler ile asset yükleme ve motor destek işlerini kapsarken, GPU tarafı gölgeler, ambient occlusion, post-processing ve GPU performans özelliklerini kapsar
• GPU öğreniminin odağında bir path tracer yazmak ve PBR’yi anlamak yer alır; başlangıç için Ray Tracing in One Weekend, LearnOpenGL PBR, Filament dokümantasyonu ve PBRT kullanılabilir
• Portföyde C++ tabanlı gerçek zamanlı bir renderer, fotoğraf benzeri görüntüler üreten bir path tracer ve iki render çıktısını karşılaştırıp doğrulayan kod bulunması bilgiyi göstermek için idealdir
• Gerekli matematik ağırlıklı olarak lineer cebir, temel trigonometri ve biraz kalkülüstür; oyun geliştirmede CPU tarafının dili C++, shader dili olarak ise en yaygını HLSL’dir

---

Gerçek zamanlı grafik, CPU ve GPU olmak üzere iki alanı birlikte kapsar

• Modern rendering, fiilen iki ayrı işi birleştiren bir yapıya yakındır
  • CPU tarafı öğrenimi: DirectX12, Vulkan, Metal gibi modern açık API’ler ile asset yükleme ve diğer destek işleri için engine programlama
  • GPU tarafı öğrenimi: modern aydınlatma ve shading matematiği, gölgeler, ambient occlusion, post-processing efektleri ve GPU’da hangi işlerin hızlı ya da yavaş olduğunun farkı
• Bu iki alanı aynı anda öğrenmek çok zordur
  • GPU tarafına odaklanmak istiyorsanız OpenGL, WebGL, DirectX11 veya CPU tarafı yükü daha hafif olan mevcut engine’ler kullanılabilir
  • CPU tarafına odaklanmak istiyorsanız önce ekranda bir üçgen göstermek, sonra bir mesh göstermek şeklinde ilerleyebilirsiniz; sonucun güzel görünmesine çok takılmak gerekmez

Path tracing ve PBR

• GPU tarafı öğrenimine bir path tracer yazmak dahildir
  • Path tracing, film rendering’inde kullanılan yöntemdir ve modern gerçek zamanlı rendering tekniklerinin yaklaşmaya çalıştığı hedeftir
  • Başlangıç kaynağı olarak ücretsiz çevrimiçi kitap Ray Tracing in One Weekend uygundur; erişimi kolaydır ve fotoğraf benzeri rendering üretme sürecini gösterir
• Physically Based Rendering (PBR), aydınlatmanın özellikle de specular bileşeninin nasıl uygulandığıyla ilgilidir
  • PBR, kurallara uyulduğunda iyi sonuç veren, ilkelere dayalı bir yaklaşımdır
  • PBR öncesinde aydınlatma için çok sayıda rastgele formül, ince ayar ve hack kullanılıyordu; bu yüzden bir aydınlatma ortamında iyi görünen bir asset, başka bir ortamda fazla karanlık ya da aşırı parlak görünebiliyordu
  • Bunun sonucu olarak her aydınlatma koşulu için farklı asset sürümleri üretmek gerekiyordu ve bu da çok zaman ve emek istiyordu
• PBR, asset’lerin farklı aydınlatma koşullarında daha tutarlı görünmesini sağlar ve sürüme özel asset üretimi için gereken zaman ile emeği azaltır
  • Buna rağmen asset üretim süresi, maliyeti ve emeği oyun geliştirmede hâlâ büyük bir darboğazdır

Önerilen öğrenme kaynakları

• PBR’ye giriş için LearnOpenGL içindeki PBR Theory bölümü ve alt bölümleri uygundur
• Daha derine inmek için Filament documentation sonraki adım olabilir
  • PBR’yi daha derin öğrendikçe daha fazla kalkülüs ve istatistik karşınıza çıkar
• Daha da ileride ücretsiz çevrimiçi kitap Physically Based Rendering: From Theory To Implementation bulunur
• Makine öğrenmesinin bugün abartıldığı kadar sonuç üretmeyeceği düşünülse de, bilgisayar bilimi araç kutusunda fitting ve optimizasyon tekniklerini öğrenmek yine de değerlidir
  • İlgili kaynak olarak Machine Learning For Game Developers videosuna bakılabilir

Portföyde gösterilebilecek kodlar

• İşe alım yapan kişilere bilginizi kanıtlamak için GitHub gibi bir yerde paylaşılabilir kaynak kodu bulundurup özgeçmişten buna bağlantı vermek idealdir
• Örnek portföy:
  • Model ve texture gibi asset’leri yükleyip ekranda gerçek zamanlı olarak render eden engine tarzı bir renderer
    • Aydınlatma ve gölgeler, depth of field, area lights, tone mapping, ray traced shadows gibi birkaç efekt içermeli
    • Mümkünse PBR tabanlı aydınlatma, kullanıcının kontrol edebildiği bir kamera, DX12 veya Vulkan gibi API’ler ve C++ kullanılmalı
  • Fotoğraf benzeri görüntüler üreten bir path tracer
    • Mümkünse C++ ile olması iyi olur, ancak pencere açmadan yalnızca PNG üreten bir program da olabilir
    • Gerçek zamanlı olması gerekmez
  • Path tracer, engine tarzı renderer’ın ayrı bir moduysa daha da iyidir
    • Path traced sonuç ile gerçek zamanlı PBR rendering’i karşılaştırarak doğruluğu doğrulayabilirsiniz
    • İki rendering’in uyuşmadığı noktaları gösterebilir, neden farklı olduklarını açıklayabilir ve gerçek zamanlılığı koruyarak bunları birbirine nasıl daha çok yaklaştırabileceğinizi düşünebilirseniz daha yüksek değerlendirme alırsınız

Matematik, algoritmalar ve dil seçimi

• Yukarıdaki maddeleri bizzat yaparken ihtiyaç duyulan matematikle doğal olarak karşılaşırsınız
  • Temel olarak gerekenler lineer cebirde matris çarpımı, cross product, dot product, temel trigonometri ve biraz kalkülüstür
  • Grafik ve oyun geliştirmede gereken asgari matematik görece küçüktür, ancak faydalanılabilecek matematik alanının üst sınırı fiilen yoktur
• Algoritmalar için de benzer bir durum geçerlidir
  • linked list, hash table, sıralama ve arama gibi temel soyut veri yapıları ile algoritmalar bilinmelidir
  • En hızlı algoritma çoğu zaman basit olanıdır ve array’ler linked list’lerden çok daha hızlıdır
  • Daha ileri algoritma kavramları, gerçekten yeni ve özelleştirilmiş bir şeye ihtiyaç duyulduğunda yardımcı olur
• Oyun geliştirmede öğrenilmesi gereken dil C++’tır
  • Rust kullananlar da vardır ve belli bir payı vardır, ancak insanların beklediği standart dil değildir
  • WebGPU, WebGL’de olmayan pek çok özelliğe sahiptir ve daha ciddi bir platform hâline gelmektedir; CPU tarafı işlerini JavaScript ile yapmayı mümkün kılar
  • Ancak WebGPU işleri ve web üzerindeki WebGPU içeriği çok yaygın görünmemektedir
• Shader dili olarak HLSL en yaygın olandır
  • Bazıları GLSL kullanır
  • Çok platformlu oyunlarda shader’lar sıklıkla başka shader dillerine dönüştürülür

LLM ve ML’in kullanım alanı

• Mevcut ML teknolojisinin, satılan kullanım senaryolarının çoğu için henüz yeterli seviyede olmadığı düşünülüyor
• Claude ile matematik, makaleler ve aşina olunmayan algoritmalar hakkında konuşmak faydalı olabilir
  • Böyle durumlarda uydurma bir şey söylenip söylenmediğini fark etmek daha kolaydır ve başka kaynaklarla doğrulama yapmak da görece basittir
• Programlama için çok faydalı değildir
  • İstenen gibi çalışan kod üretse bile o kodu anlamak için yine zaman harcamak gerekir
  • Bu durumda doğrudan kendiniz yazmak daha mantıklı olabilir
• Küçük işler için yararlı olabilir
  • Örneğin “bu dosyada bir bug görünüyor mu?” diye sormak, yanıt yes ise inceleme yapmaya değer kılar; no olsa bile sormanın maliyeti neredeyse yoktur
• Bir gün insanlığın insan seviyesinde yapay zeka üretip bunun da ötesine geçeceğine inanılıyor, ancak bunun kendi yaşamı içinde olup olmayacağı bilinmiyor
  • Mevcut LLM dönemi, ileride “gerçek” olan geldiğinde ona hazırlanmak için bir prova niteliğinde görülüyor

[GN⁺]

Hacker News yorumları

• Önce oyun yapmak mı, yoksa 3D motor programlama mı yapmak istediğini ayırt etmek gerekiyor.
  Oyun yapmak istiyorsan Unreal Engine, Unity, Godot, Bevy gibi mevcut motorları kullanmak daha iyi; pikselleri doğrudan ekrana basmaktan çok grafiğin daha üst düzey sorunlarını öğrenirsin. Asıl zor olan, oyunu eğlenceli yapmak.
  3D motor yapmak istiyorsan, ortalıkta zaten fazlasıyla berbat oyun motoru olduğunu bilmelisin. Sadece Rust tarafına bakınca bile üç başarısız renderer, bir tamamlanmamış renderer ve Bevy’nin içindeki renderer başlıca projeler; “oyun motoru yapacağım” diyen proje sayısı ise çok daha fazla. “İlk renderer” seviyesine gelmek bile yaklaşık 2 yıl sürüyor; büyük, ayrıntılı ve dinamik sahnelere ulaşmak çok daha büyük bir iş.
  Amaç iş bulmaksa oyun sektöründe ne maaşlar ne de çalışma saatleri iyi; proje bitince iş de bitiyor ve Hollywood gibi içeri girmek isteyen adaylarla dolup taşıyor. Üstelik Metaverse çöküşü yüzünden şu anda deneyimli kişilerde de arz fazlası var.
  Mobil taraf ekran, hesaplama gücü, GPU ve pilin hepsinin yetersiz olduğu bir sıkıştırma işi; bu yüzden günümüzde indie oyunların çoğu 2D. En azından yapılabilir durumda ve sık sık HTML/JavaScript ile de yapılıyor.

  • Çoğu kişinin Unreal ile görsel rekabete girmeye çalıştığını varsaymışsın gibi görünüyor; bunun elbette neredeyse imkânsız olduğu doğru.
    Ama temel bir renderer ve oyun döngüsü yapmak o kadar zor değil; oyun kodunun büyük kısmını oluşturması da pek olası değil. Basit bir oyunda for döngüsünde drawObject() çağırmak bile yeterli olabilir; kaynak streaming’i, binding optimizasyonu, paralellik gibi dertler daha sonra gerektiğinde düşünülebilir.
    “İlk renderer’a 2 yıl” ölçütünün hangi başlangıç noktasını ve başarı koşulunu varsaydığını merak ediyorum. Yaklaşık bir yıl önce boş zamanımda bir ayda, tam zamanlı karşılığıyla bir haftadan az sürede dinamik aydınlatma, shadow mapping ve birkaç post-processing içeren deferred renderer yaptım.
    2D’yi küçümsemek için de bir neden yok. Ciddi işlerin önemli bir kısmı 2D arayüzlerde yapılıyor; WebGL ve eski 2D canvas bile bugün oldukça güçlü. Hit olmuş indie oyunlar arasında da çok sayıda 2D oyun var.
    Oyun sektörünün pek iyi olmadığı doğru, ama günümüzde neredeyse her şey GPU kullanıyor. Makine öğrenmesi işleri yazmak ve debug etmek, veri görselleştirme, HUD’lar ve genel kullanıcı arayüzleri de çoğu zaman grafik anlayışı gerektiriyor.
  • Oyun sektörünün ortalaması kötü olabilir, ama grafik programlama nişinin öyle olmadığını düşünüyorum.
    Oyunların dışında görselleştirme, simülasyon vb. grafik kullanan çok daha fazla alan var; iyi grafik programcıları son derece nadir olduğu için şaşırtıcı derecede iyi bir kariyer yolu. Oyun geliştiricilerinin veya sanatçıların iyi işler bulmasının daha zor görünmesiyle oldukça tezat. Yine de hem talep hem arz küçük olduğu için iş değiştirmek kolay olmayabilir.
    Sadece iş güvencesine bakarsak oyun geliştirmeyi kariyer olarak önermek istemem, ama grafik programlama farklı.
  • Unity ya da Unreal Engine yüzünden aslında iyi olabilecek oyunların performans sorunları yaşaması çok üzücü. Bunların önerilmemesini isterdim; Godot ve Bevy’nin daha iyi olup olmadığını ise henüz bilmiyorum.
    Son birkaç yılda oynadığım oyunlardan Core Keeper (Unity), WORMHOLE (Unity, özellikle sonsuz moddaki gecikme), Crab Champions (UE4; 1920x1200’de 60fps’i korumak için ekranı çirkinleştiren upscaling kullanmak gerekiyor) ciddi performans sorunları yaşadı.
    Buna karşılık Terraria, Necesse ve Barony kendi motorlarını kullanıyor ve harika çalışıyor; yaşlandıkça daha da iyi görünüyorlar.
    Adil olmak gerekirse Tiny Rogues (Unity) hatırladığım kadarıyla genel olarak iyi çalışıyordu, ama geliştirici ileride Unity’den çıkmak için çalışıyor; demek ki kendisi de bir sorun görmüş.
    Oyun yapmakla motor yapmak arasındaki farkı ve gerçekten tamamlayıp yayımlamanın önemini anlıyorum; ama çöp çıkarırsan iyi bir miras bırakmak zor. Dolambaçlı bir yol olsa bile belli bir kalite seviyesini garanti altına almak daha iyi bence. Oyunlar çıktıktan sonra onlarca yıl oynanabiliyor; bug ya da gecikme varsa insanlar bunları yaşamaya devam ediyor.
  • Motor yapmaya başlarsan, özellikle öğrenirken yapıyorsan, oyunu yapamama ihtimalin yüksek. İkisini birden başarmak teknik olarak mümkün ama geçmişte bunu bizzat yaşadığım ve Polonya’daki hobi oyun geliştirme topluluğunda onlarca kişiyi gördüğüm kadarıyla başarı olasılığı %5’in altında gibi.
    “Sonraki oyunu kolay yapmak için önce kendi oyun motorumu yapacağım” şaşırtıcı derecede güçlü bir tuzak. Çünkü gerçekten önemli şeyler öğreniyorsun ve her gün küçük zaferler elde ediyorsun. Sahne daha akıcı görünsün diye bir unroll daha yapıyorsun, sahne oluşturmayı kolaylaştırmak için yapılandırma formatına bir mantık katmanı daha ekliyorsun, bir SIGGRAPH makalesi daha okuyorsun.
    İyileştirilecek önemli şeyler hep var, ama bunlar tamamlanmış bir oyunda birleşmiyor. Geriye dönüp bakınca kendi motorunu kullanmak, teknik insanların hayalindeki oyunun zor ama gerekli kısmını, yani “eğlenceli yapmayı” ertelemenin mükemmel bir yolu. Etkileyici video oyunları kodlama becerisi kazanıyorsun, ama oyun yapmayı öğrenmiyorsun.
    Alt tuzaklar da var. Gerçek zamanlı ve akıcı çalışan güzel görsel efektler yapmanın yüzlerce yolunu öğreniyorsun, ama bunları sanat olarak kullanmayı öğrenmiyorsun.
    Bu, “Enterprise Java” tuzağına da çok benziyor. Sadece somut terimlerle uğraştığı için daha sinsi. Scene Graph’ta Factory Factory Interface olmadığı için o kurşundan kaçındığını sanıyorsun, ama aslında ekrana bitmap koyup tuşlara tepki vermesini sağlama işi için bunun başlı başına gereksiz olduğunu kaçırıyorsun.
  • Oyun yapmak istiyorsan her zaman mevcut motor kullan denmesine tamamen katılmıyorum. Çoğu durumda iyi tavsiye, ama mevcut motorlar fazla genel amaçlı ve oyun hakkında çok sayıda varsayım içeriyor. Oyunun farklı kısıtlamalara ihtiyaç duyabilir.
    Bu özellikle 2D’de geçerli. Örneğin kendi yaptığım oyun motoruyla bir oyun yapıyorum; performans ve sıkıştırmaya, ayrıca sunucu ya da veritabanı olmayan bir mimariye odaklanıyorum.
    Bu motor, belirlediğim kısıtlar içinde aşırı yüksek performans ve sıkıştırma elde etmek için oyun yapısı hakkında çok belirli yapılara ve varsayımlara sahip. İlgili Hacker News gönderisini yakında, mümkünse gelecek hafta paylaşmayı planlıyorum.
    Daha önce tarayıcı oyunlarını Unity, Godot ve React ile birkaç kez yapmaya çalıştım ama API’leri öğrenmek eziyetti; motorlar da benim aşırı kısıtlarımı karşılayamadı. Elbette bu motorları iyi kullanamamış olmam da mümkün, ama geriye dönüp baktığımda içeride elde ettiğim şeylerin sıfırdan yazılmış özel motor olmadan imkânsız olacağını düşünüyorum.
    Kendi motorumu ve oyunumu yaparken gerçekten çok şey öğrendim; özellikle bugünlerde LLM’ler sayesinde deneyimli bir geliştiricinin kendi özel oyun motorunu yapmayı denemesi, çoğu geliştirici için bir anda gerçekçi bir kapsama girdi diye düşünüyorum.

• Şu an olsa kimseye grafik programlamaya girmesini önermezdim.
  2001’de Nvidia’nın ilk GeForce 1’inin, yani “Gigatexel shader card”ın duyurulduğu dönemde başladım; o zamandan bu yana bu alanın gelişim hızı ve inovasyonu baş döndürücüydü. 25 yıl öncesiyle karşılaştırınca bugünkü teknoloji gerçekten inanılmaz.
  Ama bu hayranlık uyandıran durumun büyük bir “ama”sı var. Bu alan korkutucu derecede hızlı ilerliyor. Nvidia, sahneyi ve varlıkları etkileyen yapay zeka tabanlı efektler bile çıkardı; o zamanlar bunların gerçek zamanlı olarak mümkün olabileceğini hayal bile edemezdik.
  Artık bu alanda “iyi bir uzman” olmanın mümkün olup olmadığını bile bilmiyorum. Başka bir deyişle soru şu: “Günümüzün John Carmack’ı nerede?” O, donanımı sonuna kadar zorlaması ve toplulukta saklı kalmış fikirleri kullanmasıyla ünlendi; ama bugün böyle biri için rekabet hendeği var gibi görünmüyor. Çünkü alan o kadar geniş ve o kadar hızlı değişiyor ki sıradaki Carmack olma fırsatı yok.

  • Bir alana girdikten sonra başkalarını caydırma tavrından gerçekten hoşlanmıyorum. “Benim gibi olma, hayatımı boşa harcadım” demek, tutkusunu kaybetmiş ve tükenmiş birinin saçmalamasına daha yakın; grafik programlamadan uzak dur demek de yarının John Carmack’ını çekmenin yolu değil.
    Başka bir bakış açısı da var. Şimdiye kadar yalnızca web uygulamaları ve Kubernetes yaptıysan, tam tersine grafik programlamayı denemek iyi olabilir. Geri bildirim döngüsü heyecan verici ve sıradan bir bilgisayarın ne kadar akıl almaz derecede hızlı olduğunu hissettiriyor. Sonunda önemsiz optimizasyonlar yapacak olsan bile, düşük seviyede şeylerin ne kadar hızlı olabildiğini hiç öğrenmediğin için bunun değeri var.
    Kaynak da bol, matematik de aşırı zor değil. 3D modelleme, varlığını bilmediğin bir yaratıcı çıkış yolu olabilir. Asıl işine hiç uygulanmasa bile bilgisayar programlama sanatını yeniden takdir etmeye başlarsın; hatta Kubernetes’e bir daha dokunmayıp boş zamanının 5 yılını kendi oyun motorunu yazmaya ayırmaya karar verebilirsin.
    Böyle çılgın insan çok var ve profesyonel oyun geliştirme içinde yıpranmamış hobi geliştirici toplulukları düşündüğünden daha büyük. Graphics Programming Discord da bakmaya değer, sıcak karşılayan bir yer. Deneyip görmek yeter.
  • Bilgisayar grafikleri özünde ilginç ve tatmin edici. Bilgisayar bilimi, matematik, kuramsal fizik, düşük seviye programlama gibi birçok önemli alanın kesişiminde yer alıyor.
    Gerçekte ne yaptığını umursamayıp yalnızca kariyer değişikliği isteyen biri için uzak durma tavsiyesi doğru olabilir. Ama bu şekilde yaşamak iyi bir yol değil. İlginç ve değerli bulduğun şeylerin peşinden gitmek, sürekli yeni şeyler öğrenmek ve kendini zorlamak daha iyi. O zaman bilgisayar grafikleri öğrenip öğrenmeme kararı nispeten netleşir; doğru kişi için net kazançtır. İşe dönüşmese bile beceriler başka birçok alana iyi aktarılır.
  • Grafik programlamanın bugün katlanarak daha değerli hale gelen faydalı bir yönü var. Matris cebiri hattı ve “matris dönüşümleriyle düşünmek”, makine öğrenmesi matematiğinin temelini kurmak için harika ve görsel olarak da içine çeken bir yöntem.
  • Inigo Quilez gibi biri ne olacak? Bugün de yeterince dikkat çeken bir figür olduğunu düşünüyorum. Ayrıca artık alanda çok daha fazla insan var; herkesin ünlü olması mümkün değil.
    Bir alandaki en bilinen kişilerden biri kadar ünlü olmamak sorun değil; sırf keyifli olduğu için de yapılabilir. Grafiklerin ve oyun programlamanın matematiği ile sanatı kendi başına güzel.
  • Doğru. Carmack’ın ünlü olmasını sağlayan akıllıca tekniklerin çoğu yazılımdan donanıma taşındı.
    Grafik programlamaya girmeyelim dememin nedeni farklı. Köşeleri ve dokuları olan 3D motorlar birkaç yıl sonra da var olacak mı? Yoksa her şeyi doğrudan bir yapay zeka dünya modeli mi render edecek? Oyunlarda ne kadar kod olacak; yoksa akıllıca yazılmış prompt’lar dizisi olarak mı var olacaklar?

• Doğrusal cebir için hızlı bir öğreticiye ihtiyacınız varsa yazdığım, yazdırılabilir 4 sayfalık belgeye bakabilirsiniz: https://minireference.com/static/tutorials/linear_algebra_in...
  SymPy kod örnekleri içeren notebook da burada: https://github.com/minireference/noBSLAnotebooks

  • Daha uzun bir öğretici gerekiyorsa 3b1b’nin serisini şiddetle öneririm: https://youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFit...
    Görselleştirmeler sayesinde Linear 101 dersinde oturmayan şeyler bir anda yerine oturdu.
  • Estetik olarak da gerçekten güzel. Güzel matematiğin kötü tipografi ve çirkin aralıklarla sunulması her zaman içimi burkar.

• Temel tasarım ilkelerini ya da insan algısının özelliklerini anlamaktan söz edilmemesi beni biraz şaşırttı.
  Ağabeyim 90’lar ve 2000’lerde ünlü bilgisayar oyunlarında prodüksiyon sanatçısıydı; görsel sezgisi olmayan ve sanatçı tarafını anlamaya merakı bulunmayan programcılar ve yöneticilerden sürekli şikâyet ederdi.
  Grafik benim uzmanlık alanım değil ama bir müzisyen, ses tasarımcısı ve prodüktör olarak tanıdığım en etkili ve nüfuzlu audio DSP kodlayıcıları; müziğin temellerini, sesin fiziğini ve akustiği, ayrık dijital işleme ile uyarıcıları algılayıp yorumlama biçimimiz arasındaki tuzakları anlıyor.

  • Söylediğine daha yakın ayrı bir rol var; buna teknik sanatçı deniyor. Benim yaptığım iş de bu.
    Grafik programcısının sanatsal bir düşünce yapısına sahip olması yardımcı olur, ama genelde oldukça düşük seviyede çalıştıkları için başarı için şart değildir.
  • Yaratıcı endüstrilerin dışında da aynı şey geçerli. B2B/kurumsal yazılımda da satış yaptıkları sektörün nasıl işlediğini ve kullanıcıların nasıl düşündüğünü hiç bilmeyen epey tedarikçi gördüm.
    Yapay zeka hesabı biraz değiştirdi ya da en azından değiştirme potansiyeline sahip, ama 2000’lerin ortasındaki “kodlama öğrenelim” akımının da büyük ölçüde bu nedenle ortaya çıktığını düşünüyorum. Yazılım geliştirmeyi, mevcut alan uzmanının “ürün değil özellik” gibi ele alıp; alanı en iyi bilen kişilerin gereksinimleri geliştirici ekibe çevirip aktarması yerine yazılımı doğrudan kendilerinin yapmasını hedefleyen bir hareketti.
  • %100 katılıyorum. İyi bir grafik programcısı teknik sanatçılar ve sanatçılarla birlikte çalışır.
    Açıkçası grafik programlama çoğunlukla onların yapmak istediklerini mümkün kılan ya da hayal ettikleri şeyi oluşturmalarına yardım eden bir hizmet rolüne daha yakın.
    Inigo Quilez, hem grafik programcısı hem de sanatçı olan bir örnek olarak anılıyor; gerçekten çok güçlü ve unicorn gibi biri.

Kişisel olarak müzik icrası ve ses programlamayı daha çok seviyorum; DSP öğrenmek için de iyi bir temel oluyor. Örneğin render gürültüsünü yüksek frekans tarafına iterseniz, düşük geçiren filtrenin gürültü gidermede daha etkili olduğu zamanlar olabiliyor

• Benim hazırlayıp sürdürdüğüm liste burada: https://legends2k.github.io/note/cg_resources/
  Merakınız varsa ve zamanınız da varsa öğrenmeye değer. Gerçekten eğlenceli ve çok şey öğretiyor; bilgisayar biliminin başka birçok alanında da sizi daha iyi bir mühendis yapıyor. Donanımı, sistem programlamayı, programcının makine modelini vb. anlamanızı sağlıyor
  Ama nihai hedefiniz paraysa öğrenmeseniz daha iyi. Günümüzde bunun getirisi uçucu, geçici ve garanti değil
  • Ben de bu kaynağı kullanıyorum; başkalarına da faydalı olabilir: https://owlcat.games/learning
• “25 yaşın altında olmak ve buna ayıracak çok zamanı olmak” da eklenmeli gibi
  Eskiden beri grafik programlamaya ilgim vardı ve birkaç yıl önce Vulkan’ı kendi kendime öğrenmeye başladım. Toplam ne kadar zaman harcadığımı bilmiyorum ama yaklaşık 6 ay boyunca akşam boş vakitlerimi, belki ondan biraz daha azını harcadım. Render framework’üne yakın bir şey yaptım
  Ama ilerledikçe ne kadar çok şeyi bilmediğinizi fark ettiren türden bir iş. Artık yapının iyi olduğunu hissettiğiniz anda, bunun doğru mimari olmadığını keşfediyorsunuz
  Sonuçta yaptığınız iş temelde uygulamalı aydınlatma matematiği, geri kalanı da tesisat işi. “Spot ışık neden küpün içinden öylece geçiyor?” diye bakıyorsunuz; gölgeleri hesaplamanız gerektiğini görüp bunu render pipeline’a nasıl koyacağınızı haftalarca kurcalıyorsunuz. Yine de bu tür şeyleri seviyorsanız epey “eğlenceli”
  • Ne yazık ki Vulkan, grafik programlamayı öğrenmek için gerçekten acı verici bir yol. Neredeyse her şeyi yapmak için muazzam miktarda boilerplate kod gerekiyor
    Örneğin gölge yaparken bile, tekniğin özünde gerektirdiğinden 10 kat fazla kod yazmanız gerekiyor
    Grafik programlamayı öğrenmek için yazılım renderer’ı yazmanın çok daha keyifli olduğunu düşünüyorum. Daha az kod var ve yazdığınız kod boilerplate değil, işin özüne dokunuyor. Dezavantajı ise donanım hızlandırmayı kaybettiğiniz için yavaşlaması
• Ne yapmak istediğinize bağlı
  Sadece oyun yapmak istiyorsanız Unity, Godot, Unreal gibi oyun motorları kullanabilirsiniz
  Motor, simülasyon, renderer gibi grafik işleri yapmak istiyorsanız düşük seviyeli dilleri ve grafik API’lerini öğrenmeniz gerekir. Dil olarak C++ öneririm; C veya Rust da kullanılabilir ama C biraz zordur ve grafik API’nin kendisi zaten zor olduğu için bir de dille boğuşmak istemezsiniz. Rust da iyi bir seçenek olabilir ama şahsen derleme sürelerinin çok yavaş, sözdiziminin de çirkin olduğunu düşünüyorum
  API olarak OpenGL’i öneririm. Çapraz platformdur, eskidir; bu hem avantajı hem dezavantajıdır ve içlerinde en kolayıdır
  learnopengl.com, OpenGL eğitimleri arasında açık ara en iyisi; takip etmenizi öneririm
  OpenGL’i bir süre kullandıktan sonra Vulkan’a veya birden çok API’yi uygulayan grafik kütüphanelerine genişleyebilirsiniz; uygunsa OpenGL kullanmaya devam da edebilirsiniz
  Kesinlikle kolay değil ama bilgisayar bilimindeki en büyüleyici alanlardan biri olduğunu düşünüyorum
• A-Frame’i (aframe.io) ben yaptım ve hâlâ bakımını sürdürüyorum. Son 10 yılda 3D grafikler öğrenmek için yumuşak bir giriş yolu işlevi gördü
  Kendim söylemiş gibi olmayayım ama topluluğu da harika. Web, öğrenirken yaptıklarınızı paylaşmak, geri bildirim toplamak ve görünürlük kazanmak için iyi bir yol. Topluluk içinde 3D grafikleri profesyonel olarak yapmaya başlayan pek çok örnek de var
  • Yüksek lisans tezimi A-Frame ile yazdım. O zamanlar programcı değildim ve neredeyse hiç deneyimim yoktu ama A-Frame sayesinde fikirlerimi gerçekten sezgisel biçimde hayata geçirebildim
    Bazen repoya dönüp baktığımda o zamanki kodun çok dağınık olmasından utanıyorum ama o proje olmasaydı bugün bulunduğum yerde olamazdım diye düşünüyorum
  • Kesinlikle önerebilirim
    Basit etiketlerle başlayıp animasyon ekliyorsunuz; yetmezse topluluk bileşenlerini ekliyorsunuz. O da yetmezse ThreeJS ile düzenleyip shader’lara kadar gidebiliyorsunuz. A-Frame harika
    Üstelik AR ve VR da yapabiliyor
• Özellikle tuhaf bir makine öğrenmesi bakış açısı da eklenince, yaptığımız her şeyi kariyere ya da mesleğe dönüştürmeye çalışıyormuşuz gibi geliyor
  “Grafik programcısı olmak” yerine sadece grafik programlama yapmak nasıl olur? Basit şeylerden başlayıp hissini alın; sonunda bunun GPU’ya lojistik göndermek olduğunu görünce, üzerine türlü karmaşık kavramlar inşa edebilirsiniz
  Küçük bir dağa tırmanırken birden her şeyin yerine oturması ve “vay…” dedirtmesi gibi. Olasılıkları ve denenecek şeyleri görmeye başlıyorsunuz
  • Bu ifadenin illa kariyer ya da meslek anlamına geldiğini sanmıyorum. Daha çok kimliği ifade etmeye yakın
    “Ben kaya tırmanışçısıyım”, “oyuncuyum”, “sanatçıyım”, “anneyim”, “babayım”, “spor salonu müdavimiyim”, “grafik programcısıyım” gibi sözler illa meslek anlamına gelmez; ama gelip geçici, hafif bir ilgiden daha derin bir şeyi ima eder
• O ray tracing tutorial’ını açıp yavaş yavaş takip ediyorum. Eskiden beri ilgim vardı ama hiç denememiştim
  Bugün PPM görüntü biçimini öğrendim; bu tür kullanım için erişilebilirliği çok iyi. Bitmap yazmak büyük bir roket bilimi değil ama PPM ondan da kolay