AAA – Analitik Kenar Yumuşatma Tekniği

 (blog.frost.kiwi)
1 puan yazan GN⁺ 2024-11-21 | 1 yorum | WhatsApp'ta paylaş
  • Rasterleştirmede oluşan jaggies ve pixel crawling, durağan görüntülerden çok hareket sırasında daha belirginleşir; yazı, WebGL daire demosu üzerinden çeşitli kenar yumuşatma yöntemlerini karşılaştırıyor
  • SSAA, MSAA ve FXAA; sırasıyla downsampling maliyeti, donanıma bağımlılık ve son işleme temelli şekil bozulması gibi farklı kısıtlamalara sahiptir
  • Analytical Anti-Aliasing, bir şeklin matematiksel sınırları bilindiğinde signed distance field ile sınıra olan mesafeyi hesaplar ve kenar çevresini 1 piksel genişliğinde alpha fade ile yumuşatır
  • Piksel boyutu 2D’de nesne ve render boyutundan doğrudan hesaplanabilir; 3D perspektif varsa dFdx, dFdy, fwidth gibi Screen Space derivatives gerekir
  • Ek buffer veya özel donanım olmadan WebGL 1.0/OpenGLES 2.0’da da uygulanabilir; ancak tüm şeklin SDF’si gerekir ve 1 pikselden küçük yüksek frekanslı formlarda sınırlamaları vardır

WebGL daire demosu üzerinden kenar yumuşatma

  • Yazının amacı, rasterization sırasında görülen jaggies sorununu azaltmaya yönelik çeşitli Anti-Aliasing tekniklerini inceledikten sonra, en sonda Analytical Anti-Aliasing uygulamasını tanıtmaktır
  • Karşılaştırma SSAA, MSAA, FXAA, MLAA/SMAA ailesi ve AAA şeklinde ilerler
  • Demo, WebGL canvas üzerinde hareket eden bir daire çizer; kenar yumuşatmanın durağan görüntüden çok hareket üzerinden anlaşılması gerektiği varsayımıyla kurgulanmıştır
  • Örnek canvas, cihazın native çözünürlüğünde render edilir; kırmızı kutu ise 4 kat büyütülmüş görünüm sağlar
  • Aliasing’in iyi fark edilmediği yüksek çözünürlüklü ekranlar için Native, 1/2, 1/4, 1/8 render çözünürlüğü geçişi sunulur ve integer scaling kullanılır

Temel daire render’ının yarattığı sorun

  • En basit daire render’ı, fragment shader’da length(uv) < 1.0 ise renk çıktısı verip değilse discard etme yöntemidir
  • Daire gerçek geometry çözünürlüğüne bağlı değildir; 4 vertex ile oluşturulmuş bir quad üzerinde shader, dairenin içini ve dışını belirleyerek çizer
  • varying vec2 uv, her fragment için interpolate edilir ve merkezi 0, aralığı -1 ile +1 olan koordinatlar sağlar
  • Bu yöntem Alpha testing kapsamına girer; length(uv) değeri, daha sonra AAA’da kullanılan signed distance field ile bağlantılıdır
  • Düşük çözünürlükte daire blocky görünür; hareket sırasında piksel satırlarının belirip kaybolduğu pixel crawling ve wobble etkisi güçlü biçimde ortaya çıkar
  • 1/4 ve 1/8 çözünürlükler yalnızca basit büyütme değildir; 3D’de küçük veya uzakta bulunan öğeleri temsil eden örnekler olarak da kullanılır

SSAA: Basit ama pahalı downsampling

  • SSAA, Super Sampling Anti-Aliasing ifadesinin kısaltmasıdır; daha büyük çözünürlükte çizip sonra küçülterek downsample etme yöntemidir
  • Örnek uygulama, daireyi (canvas.width / resDiv) * 2, (canvas.height / resDiv) * 2 boyutunda bir texture’a çizer; ardından standart çözünürlüklü framebuffer’a downsample eder ve ekrana blit eder
  • 2 kat çözünürlükte render, 1 çıktı pikseli başına 4 giriş pikseli kullandığı için bellek ve hesaplama miktarı 4 kat artar
  • Gerçek örnekte kenar yumuşatma gerçekleşir, ancak beklenenden daha zayıf görünür
    • Saydamlık basamaklarının 4 basamak olması gerekirken, gözlemde yalnızca 2 basamağın göründüğü bölümler vardır
    • Düşük çözünürlüklerde 4 basamaklı saydamlık çoğunlukla 45 derecelik diyagonal çevresinde ortaya çıkar
    • Eksen hizalı alt bölümde yalnızca tamamen opak ve %50 saydam görünür; %25 ve %75 basamakları eksiktir
  • Bunun nedeni, daire formunun kendisini 2 kat çözünürlükte örneklemek yerine, zaten quantized olmuş daire sonucunun yeniden örneklenmesidir
  • Örnek uygulama 2x resolution texture ve linear interpolation kullandığı için pratikte VRAM’i 5 kat kullanır
  • Doğru SSAA, ara buffer olmadan scene’i birden fazla kez örnekleyip sonuçları birleştiren bir yöntemdir; bu yüzden render pipeline ile derin entegrasyon gerektirir

MSAA: Donanım tabanlı örneklemenin artıları ve eksileri

  • MSAA, supersampling’in bir türüdür; ancak ağırlıklı olarak model silüetleri, üst üste binen geometry ve Alpha to Coverage etkinleştirilmiş texture kenarlarında uygulanır
  • Uygulama GPU donanımına ve grafik tedarikçisine bağlıdır; destek düzeyi donanıma ve sürücüye göre değişir
  • WebGL 1 MSAA desteklemediğinden örnek WebGL 2 context kullanır
  • Örnek UI, No MSAA, 2x, 4x, 8x, 16x, 32x, 64x ile Native, 1/2, 1/4, 1/8 render çözünürlüklerini karşılaştırır
  • gl.MAX_SAMPLES ile desteklenen en yüksek sample sayısı okunur ve yalnızca seçilebilir seçenekler etkinleştirilir
  • Mobil GPU’larda renderbufferStorageMultisample() çağrısı pratikte 4x MSAA’ya zorlanabilir
    • Android, 2x seçimine izin verse de sürücü bunu 4x’e zorlar
    • iPhone ve iPad’de 2x seçildiğinde 4x olur; saydamlık %50 katlarına yakın değerlere yuvarlandığı için örnekte çift kenar oluşur
  • MSAA donanıma bırakılan bir yöntem olduğundan kullanıcının cihazı gereken özelliği desteklemeyebilir
  • Örnekleme deseni beklenmeyen sonuçlar üretebilir ve donanıma bağlı olarak daire kenarındaki saydamlık basamakları “yanlış sırada” görünebilir
  • Belirli koşullarda hâlâ güçlüdür
    • forward rendering
    • aşırı yoğun olmayan geometry
    • tile-based rendering architecture’a sahip GPU
  • Rahul Prasad, mobilde MSAA’nın masaüstü kadar pahalı olmadığını ve bazı mobil GPU’larda 4x MSAA’nın ücretsiz olabileceğini açıklar
  • Ek kaynak olarak KhronosGroup Vulkan-Samples içindeki MSAA color resolve deep-dive anılır

MLAA, SMAA ve FXAA’ya uzanan son işleme akışı

  • Alexander Reshetov’un 2009 tarihli makalesi, blocky aliasing içeren görüntülerde kenarları bulup piksel formuna göre filtreleme kurallarıyla bloklu kenarları azaltan bir yaklaşım sundu
  • Morfoloji temelli bu yaklaşım MLAA’ya dönüştü; ardından sub-pixel artifact gidermeye daha fazla odaklanan SMAA ile iyileştirildi
  • Bazı kullanıcılar MLAA/SMAA ailesini fazla bulanık buldu ve “vaseline on the screen” ifadesi ortaya çıktı
  • Son işleme kenar yumuşatma, dalgalı donanım desteğinden uzaklaşıp AA’nın shader tabanlı hale gelme akışını gösterir

FXAA 3.11: Hızlı son işleme AA’nın yapısı ve sınırları

  • FXAA, Timothy Lottes’in Fast approximate anti-aliasing algoritmasıdır ve MLAA’dan ilham alır
  • Yayımlanan son sürüm FXAA 3.11’dir; demo 12 Ağustos 2011’de yayımlanan sürümü temel alır
  • Demo, dairesel sahneyi Native, 1/2, 1/4, 1/8 çözünürlüklerde karşılaştırır
  • Varsayılan ayarlar FXAA_PC 1, FXAA_QUALITY_PRESET 12, fxaaQualitySubpix 0.75, fxaaQualityEdgeThreshold 0.166, fxaaQualityEdgeThresholdMin 0.0833 kullanır
  • FXAA önce merkez piksel ile üst, alt, sol ve sağdaki luminance değerlerini sample eder; local contrast eşik değerin altındaysa orijinal pikseli döndürür
  • Early exit değilse diyagonal luminance değerlerini de sample eder; yatay ve dikey edge yönünü hesapladıktan sonra iki yönde arama yaparak edge uçlarını bulur
  • Son aşamada piksel koordinatlarını kaydırıp texture2D sample eder; resmi whitepaper’a göre bu, basitçe edge blur yapan bir yöntem değildir
  • Daire demosunda durağan durumdaki kenar pürüzsüz görünür, ancak daire hareket ettiğinde form bozulur
    • Eksen hizalı üst ve alt kısımlarda küçük çıkıntılar belirip kaybolur
    • Düşük çözünürlükte daire yuvarlak formunu kaybeder ve PlayStation 1 grafikleri gibi titrer
  • Her piksel için yalnızca 3x3 çevre dikkate alındığından, bu bölgenin büyük bir dairenin parçası olduğu bilinemez
  • FXAA daha karmaşık sahnelerde kenar yumuşatma yapmak için tasarlanmıştır ve çok sayıda ayar ile preset sunar
  • NeoTokyo° sahnesini kullanan full demo, aliased output’tan luminance channel hesaplayıp FXAA uygular; tüm preset ve setting’lerin değiştirilebileceği şekilde yapılandırılmıştır

FXAA girdisi ve parametre koşulları

  • FXAA_GREEN_AS_LUMA 1 olarak ayarlanırsa luma yerine yeşil kanal kullanılır; bu durumda RGB girdisi doğrusal olmayan bir renk uzayında olmalıdır
  • FXAA girdi RGB’si LDR olmalıdır; daha açık söylemek gerekirse FXAA tonemapping sonrasında uygulanmalıdır
  • FXAA_GREEN_AS_LUMA kullanılmıyorsa FXAA çalıştırılmadan önce alpha kanalına perceptual space’teki luma kaydedilmelidir
  • Luma doğru hesaplanmalıdır ki FXAA düzgün çalışsın
  • FXAA_QUALITY_PRESET, performans ile kaliteyi takas eden bir ayardır
    • 12 varsayılandır
    • 15 ve 29 en yüksek kalitedir
    • 39 EXTREME QUALITY’dir
  • fxaaQualitySubpix, sub-pixel aliasing giderme miktarını ayarlar
    • Varsayılan değer 0.75tir
    • 1.00 daha yumuşaktır, 0.50 ise daha keskindir ancak sub-pixel aliasing giderimi daha azdır
    • 0.00 kapalı durumdur
  • fxaaQualityEdgeThreshold, algoritmanın uygulanması için gereken minimum local contrast değerini belirler
  • fxaaQualityEdgeThresholdMin, karanlık bölgeleri işleme hedefinden dışarıda bırakır
  • FXAA, hâlihazırda bir post-processing pipeline varsa veya deferred shading kullanılıyorsa düşük performans maliyetine sahip olabilir
  • Mobil grafiklerde bellek erişimi pahalı olduğundan, FXAA için yeni bir render-to-texture yapılandırması oluşturmak gerekiyorsa maliyet avantajı zayıflar

Analytical Anti-Aliasing’in özü

  • Analytical Anti-Aliasing, gerekli şekli bildiğiniz durumda pikselleri zaten anti-aliased biçimde çizme yöntemidir
  • 2D veya 3D şekiller çizerken şeklin sınırı tam olarak 1 piksel kadar fade edilir
  • Örnek, bir daireyi Native, 1/2, 1/4 ve 1/8 çözünürlükte karşılaştırır; düşük çözünürlükte bile edge smoothing ve shape korunumunu gösterir
  • circle-analytical.fs, dist = length(uv) ile dairenin signed distance field’ını hesaplar
  • Daire sınırına yakın pikselleri 1 piksel genişliğinde fade etmek için alpha = (1.0 - dist) / pixelSizeAdjusted kullanılır
  • Bu yöntem artifact oluşturmadan pürüzsüzdür, filtering miktarı ayarlanabilir ve ek buffer ya da ek donanım gereksinimi yoktur
  • Extension olmadan temel WebGL 1.0 veya OpenGLES 2.0 üzerinde de çalışır
  • 1 piksellik smoothing keskindir; ancak ekran çözünürlüğü, boyut ve daire konumu kombinasyonuna bağlı olarak eksene hizalı 90 derece yanlar hâlâ flat algılanabilir
  • Diyagonal piksel boyutu olan √2 px = 1.4142... temel alınarak filtering yapılırsa flat hissi azaltılabilir, ancak şekil çok az daha bulanıklaşır

“Analytical”ın anlamı ve SDF tabanlı uygulama

  • Grafik programlamada “Analytical”, amaçlanan shape’in yapısını önceden bilip bunun matematiksel tanımı üzerinde hesaplama yaparak oluşturulan etki anlamına gelir
  • Bu terim computer graphics alanında gevşek biçimde kullanılır ve bağlama göre birden fazla anlama gelebilir
  • Uygulama signed distance field tabanlıdır ve örneklenen her point’te istenen shape’e olan mesafenin bilindiğini varsayar
  • Bu bilgi, SDF text rendering’de olduğu gibi texture’a bake edilebilir veya basit shape’lerde matematiksel formülle per-pixel türetilebilir
  • Signed distance’a göre shape border fade out edilir ve fade mesafesi 1 piksel boyutu olarak ayarlanırsa smooth edge elde edilir
  • Temel uygulama sorusu, shader’ın piksel boyutunu nasıl bildiği ve distance’a göre nasıl blend yaptığıdır
  • Bu yaklaşım motion-stable pixel-perfection sağlar; ancak traditional rasterization ile uyumlu değildir ve tüm shape için signed distance field gerektirir

Piksel boyutu hesaplama: önceden hesaplama, dFdx/dFdy, fwidth

  • Sınır fade genişliği, daire yarıçapının %95’i gibi sabit bir değer olarak ayarlanırsa belirli boyut ve çözünürlüklerde iyi görünebilir; ancak boyut değiştiğinde aşırı yumuşayabilir veya aliasing oluşabilir
  • Piksel boyutu, Screen Space derivatives’ın çözdüğü problemlerden biridir
  • dFdx, dFdy, fwidth, belirli bir değerin ekran pikseli biriminde ne kadar değiştiğini bulmayı sağlar
  • Örnekte mesafe değişim miktarı pixelSize = fwidth(dist) veya pixelSize = length(vec2(dFdx(dist), dFdy(dist))) ile bulunur
  • Screen Space derivatives, 3D perspektifi de içeren dönüşümleri doğru biçimde yansıtır; ancak WebGL 1 standardına dahil değildir, bu yüzden GL_OES_standard_derivatives extension’ı veya WebGL 2 gerekir
  • length() yöntemi dFdx ve dFdy’nin oluşturduğu vektör uzunluğunu bulur; fwidth() ise abs(dFdx()) + abs(dFdy()) yaklaşık değerini kullanır
  • fwidth() yaklaşımı diyagonal yönde fazla büyük ölçeklendiği için fade diyagonallerde daha fazla uygulanabilir
  • Unity extension’ı Shapes, fwidth() tabanlı AAA’yı “Fast Local Anti-Aliasing”, length() tabanlı yöntemi ise “Corrected Local Anti-Aliasing” olarak adlandırır
  • 2D’de context render boyutu ve quad boyutu bilindiği için piksel boyutu her nesne için doğrudan hesaplanabilir
  • Örnek, gl.uniform1f(pixelSizeCircle, (2.0 / (canvas.height / resDiv))) gibi yükseklik tabanlı piksel boyutunu iletir; bu yöntem WebGL 2 veya extension olmadan eski donanımlarda da çalışır

Alpha blending ve step fonksiyonu seçimi

  • Fade genişliği bulunduktan sonra opaklık ayarlanmalıdır
  • 2D’de Alpha blending basit bir seçenektir
  • Diğer seçenek MSAA ile Alpha to Coverage’ı birlikte kullanmaktır; 3D sahnelerde doğru blending için depth-buffer write gerektiğinde kullanılabilir
  • Alfa, mesafe tabanlı olarak fade edilmelidir ve genellikle start ile end arasında interpolasyon yapan step fonksiyonu kullanılır
  • GLSL anti-aliasing uygulamalarında smoothstep() sık kullanılır; ancak bu bağlamda 1–2 piksel içindeki bir fonksiyon olduğu için gözlemlenebilir bir eğri neredeyse yoktur
  • smoothstep()te Hermite interpolation kaldırılırsa clamp edilmiş doğrusal interpolasyon olan linearstep() elde edilir
  • Bir quad üzerinde yalnızca bir şekil varsa clamp de kaldırılabilir
  • Nihai alfa, float alpha = (1.0 - dist) / (pixelSize * smoothingAmount); gibi basit bir bölme işlemiyle hesaplanabilir
  • Performans açısından pahalı kısım hâlâ her pikselde yapılan bölme işlemidir; modern GPU’lar Hermite interpolasyonun çarpma ve toplama işlemlerini Fused Multiply-Add ile optimize edebilir

Quad sınırı, MSAA, 0.5 piksel düzeltmesi

  • MSAA + Alpha to Coverage ile rasterizer arasında yalnızca bazı donanımlarda ortaya çıkan bir etkileşim vardır
  • MSAA + Alpha to Coverage kullanılırken örnek sayısından bağımsız olarak quad’ın bir tarafında tam 0.5 pikselin kaybolduğu durumlar oluşabilir
  • Örnek, buna karşılık SDF’ye dist += pixelSizeAdjusted * 0.5 biçiminde 0.5 piksellik pay ekler
  • 2D’de NV_conservative_raster_dilate benzeri bir işlem doğrudan uygulanabilir
    • vertex shader’da quad 0.5 piksel büyütülür
    • fragment shader’da signed distance field 0.5 piksel küçültülür
  • Sayfadaki 2D demolar bu yöntemle çalışır ve vertex *= size + pixelSize bu rolü üstlenir
  • Gamma ve premultiplied alpha sorunları da her AA biçiminde önemlidir, ancak AAA’ya odaklanmak için ele alınmaz

Birden Fazla Şekil ve 3D Genişletme

  • Tek bir quad içinde birden fazla şekil çizilebilir ve her biri için kenar yumuşatma uygulanabilir
  • Birden fazla şekil olduğunda, kesişim noktalarında da kenar yumuşatmanın korunması için iki şeklin de her pikselde değerlendirilmesi, sonucun clamp·weight·sum edilmesi gerekir
  • Renk bindirmesini ayrı bir pass olarak çizmektense, gereken şekil çıktısında tek seferde renklendirmek daha düşük maliyetlidir
  • 3D örneği, hareketli kamera ve perspektif içinde yer alan 2D rounded square kullanır
  • 3D fragment shader, roundedBoxSDF ile rounded box SDF’ini hesaplar ve length(vec2(dFdx(dist), dFdy(dist))) ile piksel boyutunu bulur
  • Kamera ve perspektif matrisi çarpımı varsa, piksel boyutunu elde etmek için Screen Space derivatives kullanmak güvenilirdir
  • Teorik olarak derivatives olmadan fragment coordinates’e her pikselde ters perspektif matrisi çarpılabilir, ancak bunun performans maliyeti yüksektir
  • Fade’i sınırın merkezine koymak, küçük boyutlarda veya güçlü perspektifte şekil deformasyonunu azaltabilir; ancak kenar quad’ın dışına taşarak hard edge veya clipping oluşturabilir
  • NVIDIA, sınırda ek pikseller sağlayan NV_conservative_raster_dilate genişletmesini tanıttı; ancak WebGL’de kullanılamaz ve NVIDIA donanımıyla sınırlıdır

Gerçek Uygulama Örnekleri

  • Freya Holmér’in Unity eklentisi Shapes, bu yaklaşımın işlevsel olarak en eksiksiz uygulaması kabul edilir
    • SDF’i MSAA ile yumuşatır veya AAA yöntemiyle blending uygular
    • motion blur, shape-respecting color gradients ve 1 pikselin altındaki çizgileri opacity fade etme özelliklerini içerir
    • 1 pikselin altındaki çizgilere yönelik teknik Line Thinness Fading olarak adlandırılır
  • Valve Software, Orange Box geliştirilirken Source engine’e signed distance field rendering’i yaygın biçimde ekledi
    • Team Fortress 2’nin HUD’ında yumuşak ama keskin UI öğeleri oluşturmak için özellikle kullanıldı
    • Sabit çözünürlüklü görüntüler yüksek çözünürlüğe büyütülse bile yumuşak silüetler üreten bir line art shader system geliştirdi
    • outline ve drop-shadow’u da işler; 3D uzaydaki tabela gibi world element’lara da uygulanabilir
  • Valve, SIGGRAPH 2007 makalesiyle uygulamasını yayımladı; makalede 3D oyun dünyası örnekleri de yer alır
  • Viktor Chlumský’nin “Shape Decomposition for Multi-channel Distance Fields” çalışması, Valve makalesinin dipnotundaki tekniği geliştiren bir örnektir
    • İlgili çalışmalar arasında msdfgen ve msdf-atlas-gen bulunur
  • Multi-channel distance field yöntemi, keskin metin oluşturmak için RGB ve median term kullanır; alpha channel’a ise glow ve drop shadow gibi efektleri işlemek için klasik SDF koyar
  • CJK karakterleri ince detaylar nedeniyle daha büyük texture gerektirir; büyük bir texture’ı küçültmek de kendi artifact’lerini oluşturabilir
  • Google Maps’in yol segmentlerinde capsule shape tabanlı AAA kullandığını Hacker News kullanıcısı aappleby belirtti
    • aappleby bunu yaklaşık 10 yıl önce kendisinin yazdığını söyledi
    • Spector.js WebGL debugger ile kontrol ettiğinde, streets draw call’unun shader code’unun şekle bağlı blended alpha gösteriyor gibi göründüğünü açıkladı

SDF Yönteminin Sınırları ve TAA Tartışması

  • Yakov Galka, SDF yaklaşımının SDF’i belirli bir noktada örneklediği için, SDF’de yüksek frekanslı bileşenler varsa aliasing oluşabileceğine dikkat çekti
  • 1 pikselden küçük bir daire rasterize edildiğinde, bu yazıdaki yaklaşım tek başına aliasing’i tamamen ortadan kaldırmayabilir
  • Yakov Galka, polygonal ve bezier shape’leri kenar yumuşatmalı biçimde rasterize eden gerçek bir analitik yöntem olarak J. Manson ve S. Schaefer’in Wavelet Rasterization çalışmasına değindi
  • Yazı yayımlandıktan sonra yorumlarda TAA eleştirisinin sert olduğu yönünde geri bildirim geldi ve TAA’nın çözmeye çalıştığı sorunları ve başka tekniklerle çözülmesi zor problemleri yeterince ele almadığını kabul etti
  • Timothy Lottes, TAA’yı açık bir teknik evrim olarak görse de motion clarity konusunda sınırları olduğunu söyledi
  • FXAA 4, 2-frame blender’dı ve TXAA’dan temelden farklıydı; TXAA’da MLAA yoktur ve MSAA tabanlıdır
  • TAA’yı daha doğru anlamak için Inside geliştiricisi Lasse Jon Fuglsang Pedersen’in GDC sunumu Temporal Reprojection Anti-Aliasing in INSIDE önerilir
  • AAA, native çözünürlükte farklı boyutlardaki şekilleri yumuşak, keskin ve motion-stable biçimde çizebilen bir teknik olarak değerlendirilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-21
Hacker News yorumları

  • Yazarı benim, sorusu olan varsa yanıtlayabilirim

    • Google Maps, tüm yol segmentlerinde kapsül biçimli AAA kullanıyor. Bunu yaklaşık 10 yıl önce ben yazmıştım :D
    • Harika bir yazı. MSDF fontlarının anti-aliasing’ini anlamaya çalışırken bazı iddialara rastladım
      Anti-aliasing’in sRGB uzayında değil doğrusal RGB uzayında yapılması gerektiği söyleniyor [1] [2], ama onlarca yıldır böyle yapılmadığı için fontların buna göre ayarlandığı ve bu yüzden bazen sRGB’nin daha iyi olduğu da söyleniyor [3] [4]. Doğrusal ve sRGB uzayında anti-aliasing konusunda bir önerin olup olmadığını merak ediyorum
      [1] https://www.puredevsoftware.com/blog/2019/01/22/sub-pixel-ga...
      [2] http://hikogui.org/2022/10/24/the-trouble-with-anti-aliasing...
      [3] https://news.ycombinator.com/item?id=12023985
      [4] http://hikogui.org/2022/10/24/the-trouble-with-anti-aliasing...
    • Küçük bir düzeltme olarak, WebGL, WebGL1’den beri MSAA desteği sunuyor. Ancak WebGL1’de bu yalnızca canvas üzerinde mümkün ve örnek sayısını kontrol edemiyorsun; sadece anti-aliasing’i açıp kapatabiliyorsun
      WebGL2’de de hâlâ MSAA texture nesneleri yok, yalnızca MSAA render buffer destekleniyor; bu yüzden shader içinde tek tek örnekleri doğrudan okuyamıyorsun. Bu, özel bir resolve render pass için faydalı bir özellik ve şu an bunu yalnızca WebGPU yapabiliyor
    • Upscaler’lara dayanan son eğilimin fazla ileri gidip birçok AAA oyunda bulanık ve artifact’li sonuçlar ürettiğine katılıyorum. Ama Digital Foundry’nin bu derinlemesine incelemesini [1] izledikten sonra, DLSS gibi teknolojilerin sağlayabildiği hareket kararlılığı ve netliğin olduğu, hatta bunun SSAA’dan bile daha iyi olabileceği argümanı bana oldukça ikna edici geldi
      Bu yüzden artık “TAA == bulanıklık” diye düşünmek yerine, “TAA + makine öğrenimini düzgün kullanırsan günümüz 3D oyunlarında mümkün olan en iyi anti-aliasing” görüşüne daha yakınım; sen buna nasıl bakıyorsun merak ediyorum
      [1] https://youtu.be/WG8w9Yg5B3g
    • Bu yazıyı yazmanın ne kadar sürdüğünü merak ediyorum
      Ben de gerçek zamanlı görselleştirme tabanlı birkaç blog yazısı yazdım ve inanılmaz uzun sürmüştü. Yine de bunun doğru yön olduğunu düşünüyorum. İçeriğin taştığı bir çağda, daha uzun sürse bile daha az ama yüksek kaliteli içerik üretmek herkes için daha faydalı gibi geliyor

  • Asıl büyük sorun anti-aliasing’in kendisinden çok etrafındaki meseleler. Oyun ayarlarında seçebildiğin çeşitli kısaltmaların birbirinden ne farkı olduğu neredeyse hiç açıklanmıyor ve bunların yarısını hiç bilmiyorum
    Elbette araştırılabilir ama biraz daha kullanıcı dostu olunmasını isterdim. Bu yazı, ileride başvurmak için faydalı olacak gibi duruyor

    • Oyun/grafik gerçekten de çok fazla teknik terim içeren bir alan. Büyücü olmak istemiyorsan ayarları değiştirip sonuca bakmak yeterli. Dolphin’deki gibi ayarlara ayrıntılı tooltip eklenmesi hoşuma gidiyor ama yine de her zaman bir miktar örtük bilgi kalacaktır
      Daha üst düzeyden bakınca, son zamanlarda kısaltma karşıtı havayı sık görür oldum. Ama bana göre şimdiye kadar hiçbir dönem bunları araştırmak bu kadar kolay olmamıştı. Öğrenmeyi zorlaştıran ya da bir tür kapı bekçiliği işlevi gören kısaltmalar elbette var, ama işleri yapabilmek için kavramlara kullanışlı bir düzeyde isim vermek gerekiyor; bu yüzden oyunlardaki grafik ayarı kısaltmalarını oldukça makul buluyorum

  • WebGL örnekleriyle grafik programlamayı analiz etme yaklaşımı dahiyane. Ortamın güçlü yanlarını gerçekten kullanan bir hiper metin. https://pudding.cool/ üzerinde görebileceğin türden bir yazıyı hatırlatıyor ama çok daha derine iniyor
    Bir süredir render motorunda MSAAx4 kullanıyordum ve yakın zamanda FXAA/TAA uygulamasına geçmeyi düşünüyordum ama artık gerçekten değiştirir miyim emin değilim. Buradan çok şey öğrendim ve UI öğelerinde analitik yaklaşımı deneyeceğim gibi görünüyor. Grafik programlama yazıları HN’de çok sık çıkmıyor, ama daha fazla ilgisi olanlara frame analizi yazılarından oluşan şu kaynağı öneririm:
    https://www.adriancourreges.com/blog/

    • Steve Wittens da https://acko.net/ üzerinde WebGL karışımlı matematik illüstrasyonları gibi bu tür yazılardan çok yazıyor
      Özellikle sevdiğim yazı https://acko.net/blog/how-to-fold-a-julia-fractal/ . Trigonometri ile karmaşık sayılar arasındaki ilişkiyi anlamamda bana bundan daha çok yardımcı olan başka bir kaynak görmedim
    • TAA’dan gerçekten nefret ediyorum. Özellikle düşük kare hızlarında ghosting çok ağır oluyor. Ghosting’den kaçınmak için bilerek daha yavaş algoritmalara geçtiğim oluyor

  • Daire ve yakınlaştırılmış bölümlerin olduğu karelerin mesajı iletme biçimi harika. Yazının tamamı çok akıcı okunuyor

  • SDF veya mSDF gelecek değil, zaten yeterince iyi bir klasik.
    “Her piksel için tüm Bézier eğrisi segmentlerini çözmek gerektiği için performans büyük ölçüde düşüyor” kısmının ise daha çok gelecek ya da bugün olduğunu düşünüyorum. Slug ve DirectWrite zaten iyi performansla kullanılıyor.
    https://sluglibrary.com/
    https://learn.microsoft.com/en-us/windows/win32/directwrite/...

    • Örtük eğri render etmeyi de unutmamak gerek [0]. Patentin süresi yakında dolacak [1].
      [0]: https://www.microsoft.com/en-us/research/wp-content/uploads/...
      [1]: https://patents.google.com/patent/US20070097123A1/en
    • Yaklaşık 20 yıl önce Microsoft Game Studios için Loop/Blinn makalesinin bir uygulamasını yazmıştım; hâlâ kullanılıyor mu merak ediyorum.
      Bunu prodüksiyon seviyesine getirmek için gerçekten çok çalışmak gerekmişti. O makaledeki Voronoi tabanlı tessellation, birçok Asya karakterinde patolojik derecede kötüydü.
    • Tamamen yanlış hatırlıyor olabilirim ama Slug'ın kullandığı algoritma patentli değil miydi?

  • Yazıyı kaydırırken NeoTokyo ekran görüntüsü hemen gözüme çarptı. O koridorda binlerce kez koştum. Yıllarca o modun sunucusunu yönettim ve küçük ama yetenekli, iyi bir toplulukla gerçekten çok keyifli zaman geçirdim.

    • Daha da şaşırtıcı olan, hâlâ aktif olarak oynanıyor olması. Her cuma gecesi bir sunucu doluyor, bazen cumartesi/pazar da öyle oluyor. Oldukça adanmış bir hayran kitlesi var ve bu kadar eski bir çok oyunculu oyunda böyle bir bağlılık görmedim.

  • Hem 2D hem de 3D render motorları yazmış biri olarak küçük bir ipucu ekleyeyim: ikisi gerçekten farklı. Sadece bir boyut fazlası değil; hedefleri, kullanım senaryoları ve beklentileri tamamen farklı.
    Bu yüzden “burada anlatılan her şey 3D'ye de genişletilebilir” demektense, bu yazının tamamının 2D render etme değil, çoğunlukla 3D render etme hakkında olduğunu söylemek isterim. Bu konuyu 2D render etme açısından ele alan iyi bir yazı olarak https://ciechanow.ski/alpha-compositing/ var.
    3D'de kimsenin önemsemediği ama 2D'de çok önemli olan anti-aliasing ölçütü doğruluk ve yanlılık. Örneğin AAA çok yanlı olduğu için doğru değil. Aynı şekli aynı konumda birkaç kez çizerseniz daha opak ya da daha koyu hale gelir. MSAA'da aynı şey olmaz; hata sınırlıdır ve yanlılık yoktur.

    • JS/TS'de WebGPU tabanlı bir 3D vektör renderlayıcı tasarlarken dün sizin projenizi [0] gördüm.
      Kalın çizgi çizimi özellikle ilginç, çünkü zor [1]. Yakın zamanda şuna da [2] baktım ve tüm şekilleri ikinci dereceden Bézier eğrisi segmentlerine dönüştürüp bu tekniği kullanmanın mümkün olup olmayacağını merak etmeye başladım. İzlemeye değer bir yol olduğunu düşünüyor musunuz?
      [0] https://github.com/Lichtso/contrast_renderer
      [1] https://mattdesl.svbtle.com/drawing-lines-is-hard
      [2] https://scribe.rip/@evanwallace/easy-scalable-text-rendering...
    • Bu yazının 3D'ye doğrudan genellendiğini söylemek zor.
      Sunulan çözüm signed distance field'a dayanıyor ama kritik kısım olan “neyin mesafesi?” sorusunu geçiştiriyor. 2D'de bu açık: nesne ile arka plan arasındaki sınırın, yani silüete olan mesafeyi ölçersiniz.
      3D'de nesne dönerken self-occlusion oluşabildiği için iş karmaşıklaşıyor. SDF'yi neye göre ölçeceksiniz? 3D nesnenin 2D projeksiyon silüeti sürekli değişir ve bunu basitçe önceden hesaplayamazsınız.

  • Captain Disillusion bağlantısını görmek güzeldi. Onu tanımıyordum ama işleri harika. Görsel efektlerle ilgilenenler için doğrudan bağlantı: https://www.youtube.com/@CaptainDisillusion

  • Yazı iyi kurgulanmış ama TAA'ya saldıran kısım bence kafa karıştırabilir. SDF anti-aliasing hiçbir açıdan TAA'nın alternatifi değil.
    TAA her tür aliasing ile ilgilenirken, burada yalnızca kenar aliasing'i ele alınıyor. Birçok modern oyun dolaylı aydınlatma ve diğer efektler için Monte Carlo tabanlı yaklaşımlar kullanıyor ve bunlar fiilen TAA gerektiriyor.

  • “Mobil çipler tam olarak MSAAx4 destekliyor ve durum garip. Android'de 2x seçebiliyorsunuz ama sürücü ne olursa olsun bunu 4x'e zorluyor” kısmı biraz tuhaf geldi.
    Benim Android telefonumda 2x ile 4x arasındaki fark kesinlikle görülüyor ama iPhone tarafındaki gibi “yuvarlatılmış” görünmüyor.