Prosedürel oyun geliştirme için tercih edilen araçlar ve teknikler

 (cprimozic.net)
5 puan yazan GN⁺ 2024-07-29 | 1 yorum | WhatsApp'ta paylaş
  • Tarayıcıda çalışan 3D sahne ve seviye projeleri büyüdükçe, tüm dünyayı üretmektense seviyenin belirli öğelerine prosedürel·üretici teknikler uygulayan yeniden kullanılabilir araçlar birikti
  • Doku çalışmasının merkezinde Triplanar Mapping ve Hex Tiling var; bunlar UV olmadan doku kaplamak ya da tekrar eden desenleri gizlemek için kullanılıyor
  • Her iki teknikte de enterpolasyon ağırlıklarına pow() uygulanarak baskın eksenin veya örnekleme sonucunun payı artırılıyor ve bazı texture lookup işlemleri atlanarak performans yükü azaltılıyor
  • Maliyetli fragment shader'lar Depth Pre-Pass ile hafifletilebiliyor; overdraw'un fazla olduğu sahnelerde performans %30'dan fazla iyileşebiliyor
  • Mesh·geometri tarafında ise LoD terrain, çalışma zamanında mesh işleme hattı ve ileride Constructive Solid Geometry ile dekor·arka plan·hasar ifadesini genişletme yönünde bir akış var

Tarayıcı 3D sahnelerinde biriken prosedürel araçlar

  • Birkaç yıldır tarayıcıda çalışan 3D scenes and levels üretirken, özel shader merkezli bağımsız demolar birbirine bağlı, oyun benzeri yapılara dönüştü
  • Ortak yaklaşım, tamamen prosedürel üretilmiş dünyalardan çok seviyenin belirli bölümlerine prosedürel·üretici teknikler uygulamak oldu
  • Farklı seviyelerde tekrar tekrar kullanılan prosedürel ve yarı prosedürel araçlar ile efektler doğal biçimde birikti

Shader'lar ve dokular

  • Dokuların çoğu iki eksende kesintisiz döşenebilen seamless texture türünde; geniş alanlara yayıldıklarında tekrar eden desenler fark edilebilir hale gelebiliyor
  • Three.JS'nin MeshPhysicalMaterial yapısını genişleten özel shader'lara çeşitli özellikler eklenerek seamless texturing desteği geliştirildi

  • Triplanar Mapping

    • Triplanar Mapping, neredeyse tüm seviyelerde kullanılan temel doku kaplama aracı
    • Önceden tanımlı bir UV map olmadan seamless texture ile mesh'e doku uygulanabildiği için, prosedürel üretilmiş terrain gibi modelleyicinin UV mapping tanımlama şansı olmadığı durumlarda faydalı
    • Hem üretilmiş mesh'lerde hem de elle modellenmiş mesh'lerde iyi çalışıyor
    • Uygulaması hafif ve basit; referans implementasyon triplanarMapping.ts içinde yer alıyor

  • Triplanar Mapping iyileştirmeleri

    • Klasik Triplanar Mapping, fragment normal'ını temel alarak üç eksendeki doku örneklemelerini lineer olarak karıştırır
    • Normal'ın tek bir eksene yakın olmadığı bölgelerde doku katman katman görünür hale gelebilir
    • Ağırlıklara yüksek üs değerli pow() uygulanıp ardından yeniden normalize edildiğinde baskın eksenin payı artar ve geçiş bölgeleri küçülür
    • Bu dönüşümle mesh'in büyük bölümünde bir eksenin ağırlığı 1'e yaklaşırken diğer iki eksenin ağırlığı 0'a yaklaşır
    • Eşik değerinin altındaki ağırlıklara ait texture lookup işlemleri atlanarak, Triplanar Mapping'in performans maliyeti normal UV tabanlı doku kaplamadan yalnızca biraz daha yüksek bir seviyeye indirilebilir
    • normal map işleme, shader kodunda ayrıca ele alınmalıdır; bunun için GPU Gems yaklaşımı kullanılıyor
    • Uygulama ayrıntıları Normal Mapping for a Triplanar Shader yazısında görülebilir

  • Hex Tiling

    • Hex Tiling, seamless texture'lardaki belirgin döşeme ve tekrar hissini gizleyen bir algoritma
    • Materyale tek bir ayar seçeneği eklemek bile, sahnenin düşük kaliteli bir mockup gibi görünmesinden yarı gerçekçi bir görünüme yaklaşmasını sağlayabiliyor
    • İlk uygulama, Fabrice Neyret'nin Shadertoy çalışmasını temel alıyor; daha sonra Three.JS material system'a uyarlanıp projenin ana material shader'ına entegre edildi
    • Ardından izin alınarak, Hex Tiling'i Three.JS projesinin built-in material'larına ekleyebilen bağımsız three-hex-tiling kütüphanesine taşındı
    • Triplanar Mapping'den farklı olarak önceden tanımlı UV mapping gerektiriyor
    • İki teknik birlikte kullanıldığında, her map için fragment başına en fazla 27 texture fetch gerekebildiğinden pratik olmuyor
    • Hex Tiling de her fragment için üç örnekleme sonucunu lineer enterpolasyonla birleştirdiğinden, Triplanar Mapping'de kullanılan pow() ağırlık tekniği burada da hem performansı hem de sonuç kalitesini iyileştirebiliyor

  • Depth Pre-Pass

    • Gelişmiş doku kaplama teknikleri, büyük sahnelerde maliyetli fragment shader'lar oluşturabiliyor
    • Depth Pre-Pass, tüm sahneyi önce çok basit ve ucuz bir material ile render ederek her pikselin depth değerini kaydetme yöntemidir
    • Sahneyi iki kez render etme ek yükü vardır, ancak overdraw'un yüksek olduğu sahnelerde bu maliyetten genellikle daha büyük kazanç sağlar
    • Overdraw'un yüksek olduğu durumlarda Depth Pre-Pass eklemek performansı %30'dan fazla artırabilir
    • pre-pass ayarları değiştirilerek yalnızca occluded fragment'lar render edilebilir; böylece pre-pass kullanıldığında atlanan fragment'lar görselleştirilebilir
    • Three.JS uygulaması ve yapılandırma ayrıntıları dedicated article içinde yer alıyor

  • Yapay zeka tabanlı PBR doku sentezi

    • AI-generated texture'lar neredeyse tüm sahnelerde kullanılıyor
    • Ölçülü kullanıldığında sonuçlar oldukça iyi görünebiliyor; örnek sahnedeki tüm dokular AI-generated
    • Doku üretimi, PBR map oluşturma ve upscaling olmadan bunları seamless 4K texture olarak birleştirme süreci ayrı bir yazıda anlatılıyor
    • O yazıda PBR map üretimi için anılan web sitesi artık kullanılamıyor
    • Şu anda normal map üretimi için DeepBump, gerektiğinde diğer map'ler için ise Materialize gibi AI dışı araçlar kullanılıyor

  • Volumetric Fog/Clouds

    • volumetric rendering, sahnelere kendine özgü efektler katabildiği için ilgi duyulan bir alan oldu
    • Herhangi bir Three.JS sahnesine cloud veya fog ekleyebilen görece genel amaçlı bir shader geliştirildi
    • Inigo Quilez'in Shadertoy çalışmasından ilham alınarak benzer LoD noise lookup kullanan temel bir volumetric clouds shader'ı oluşturuldu, ardından daha genel ve yapılandırılabilir hale genişletildi
    • Bu shader, seyrek yerleştirilmiş seviyelerdeki boş alanları doldurmak ve hareketli cloud ya da fog ile statik seviyelere dinamik bir his katmak için yararlı
    • Ayrıca three-good-godrays projesinde n8programs tarafından geliştirilen kod ve yaklaşımın bir kısmı da kullanıldı
    • three-good-godrays de sık kullanılıyor ve seviyelere oldukça ayırt edici bir atmosfer katıyor

Mesh ve geometri

  • Çalışma zamanında mesh üretimi, giderek daha fazla ele alınan bir alan
  • Dünyanın bir yazılım seed'inden büyümesi fikri cazip gelse de, prosedürel üretimi öne çıkaran bazı oyunlardaki “sonsuz ama boş” hissinden kaçınılmak isteniyor
  • Bu yüzden odak, tüm çekirdek deneyimi prosedürel üretmekten çok seviyelere dekor, arka plan ve prosedürel süslemeler eklemek üzerinde

  • LoD Terrain

    • terrain generation, prosedürel oyun geliştirmenin en tipik alanlarından biri ve uygulamanın kendisi özel sayılmaz
    • Çoğu yaklaşımda olduğu gibi bir noise function ile terrain heightmap üretiliyor, ardından bu veri triangle'lara tessellate edilerek render ediliyor
    • Doku kaplama için Triplanar Mapping veya Hex Tiling kullanılıyor
    • Asıl önemli kısım LoD sistemi; terrain, tile birimleri halinde üretiliyor ve her tile birden fazla çözünürlükte hazırlanıyor
    • Tile ile camera arasındaki mesafeye göre farklı çözünürlükler dinamik olarak değiştiriliyor
    • Bu terrain generation system sık sık yeniden kullanılıyor; esnek ve verimli yapısı sayesinde az emekle birçok seviyeye uygulanabiliyor

  • Prosedürel mesh işleme·manipülasyon hattı

    • Son dönemde en çok çalışılan alan, procedural mesh processing hattı oldu
    • İlk hedef, dinamik olarak üretilen mesh'ler dahil olmak üzere low-poly mesh'leri prosedürel olarak subdivide etmek ve deformasyona uğratmaktı
    • Amaç, platform, kaya bloğu veya büyük yapılar gibi basit mesh'ler seviyeye eklendiğinde onların daha gerçekçi ya da daha ilgi çekici görünmesini sağlamaktı
    • Bu çalışma, tarayıcı çalışma zamanında ham geometri verisini alıp serbestçe değiştiren ve ardından tekrar render edilebilir formata aktaran bir yazılım hattına dönüştü
    • Bu süreçte özellikle normal işleme tarafında ayrıntılı dikkat gerekiyor
    • Uygulama ayrıntıları subdividing meshes for displacement yazısında bulunabilir

Sıradaki deney adayı: Constructive Solid Geometry

  • Burada listelenen araçların çoğu başlangıçta belirli bir kullanım senaryosu için tek seferlik implementasyonlar olarak ortaya çıktı, ancak daha sonra farklı seviyelerde ve bağlamlarda tekrar tekrar kullanıldı
  • Bundan sonra denenmek istenen başlıca fikir Constructive Solid Geometry
  • Constructive Solid Geometry, 3B uzayda boolean operator uygulayan bir sistemdir
    • Rastgele iki mesh birleştirilebilir
    • Bir mesh'ten parçalar kesilip çıkarılabilir
    • Benzer başka işlemler de gerçekleştirilebilir
  • csg.js, mesh primitive'leri, boolean operator'ları ve temiz bir API içeren CSG araç setini yaklaşık 500 satırlık, açıklamalı tek bir JavaScript dosyasında sunuyor
  • Bir gün bu kütüphaneyi Rust'a port ederek nasıl çalıştığını daha iyi anlamak planlanıyor
  • CSG, mevcut mesh processing pipeline ile birlikte kullanıldığında ilginç sonuçlar üretebilir
  • Özellikle mesh'lere prosedürel olarak hasar verme özelliği denenmek isteniyor
    • building veya bridge'lerden parçalar kesilerek çürüme ya da hava koşullarına bağlı yıpranma simüle edilebilir
    • wall veya road üzerinde çatlaklar üretilebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-29
Hacker News görüşleri

  • Daha önce biraz prosedürel üretim ile uğraştım; özellikle de güzel görünen ağaçlar yapmaya çalışıyordum, ama benim için eksik parça geometrileri kolayca birbirine bağlama yöntemiydi
    İki silindir oluşturmak kolay, ama bunları doğal görünecek şekilde birbirine eklemek çok zordu
    Teorik olarak CSG bu boşluğu doldurabilir, ancak problemi bu şekilde düşünmek kolay değildi. Çünkü bunu basitçe tepe noktası ekleyen bir döngü gibi göremiyorsunuz; her şeyi 3B şekiller olarak modellemeniz gerekiyor
    İki tepe noktası döngüsünü alıp bunları sezgisel olarak yüzeyler ekleyerek bağlayan bir rutin de yazdım, ama hangi tepe noktalarının birbirine bağlanacağını seçmek beklediğimden çok daha zordu ve kolayca kötü görünen bağlantılar ortaya çıkıyordu
    Bir gün, farklı modüler prosedürel üretim sistemlerinin doğaçlamayı koruyarak birlikte çalıştığı bir oyun yapmak istiyorum. Örneğin sistemler dünyanın bir bölümünü “işgal eder”, o bölümün bir kısmını başka sistemlere devreder ya da çevredeki unsurlarla doğal biçimde birleşir

    • Devam edin ama fazla karmaşık hale getirmeyin derim
      Yakın zamanda üretilmiş ağaçlar yapmaya dair bir video [0] vardı; çözüm, silindirlerin birbirinin içinden geçmesine izin vermekti. Böyle hileli yöntemler de gayet işe yarayabiliyor ve sonuçlar iyi görünebiliyor
      Dediğiniz gibi CSG de mümkün, ama gereğinden fazla karmaşık olabilir. Başka bir yöntem de ağacın iskeletini oluşturup ardından lofting yapmak, gerekirse de bunu CSG ile birleştirerek gövdeyi ve kabuğu oluşturmaktır
      İyi bir kütüphane yeni olasılıkların önünü açar. Silindir birleştirme veya geometri çıkarma gibi boolean işlemleri yapabilen bir 3B geometri kütüphanesi bulursanız pek çok yeni fikri deneyebilirsiniz. Birkaçını kullandım; içime sinen tek seçenek JSCAD [1] oldu
      [0] https://youtu.be/8zMbJmuwEUc?si=KQclrVPeSrIRmsbA
      [1] https://github.com/jscad/OpenJSCAD.org
    • İşaretli uzaklık alanlarına bakmanızı öneririm. Prosedürel geometrideki en zarif CSG çözümlerinden birine en yakın yaklaşım bu
      3B şekilleri işlevsel olarak tanımlayıp dönüştürmeye benziyor
      Demoseanede insanların bununla neler yaptığını görmek için YouTube’da Mercury Delight aratmanızı şiddetle tavsiye ederim. Shadertoy’da da çok örnek var ve gerçekten şaşırtıcı şeyler mevcut
    • Döngüyü açabiliyorsanız, bunu tepe noktası ekleyen bir döngü yaklaşımı olarak da görebilirsiniz
      https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Condition...
      Aşağıdaki örnek de faydalı olabilir
      https://github.com/MaxBondABE/batteries/blob/master/src/geom...

  • İyi arazi üretimi, ister dünya ölçeğinde ister göz hizasında olsun, hiç de önemsiz bir iş değil
    Basit yaklaşım, yazıda görüldüğü gibi engebeli bir heightmap üretmek olur; bu da gerçek dünyadaki arazilere pek benzemez ve keşfetmesi de çok ilgi çekici değildir
    Örneğin Dwarf Fortress, temel bir midpoint displacement ile başlar ama sonrasında bol miktarda özel son işleme uygular

    • Bence bu, tüm oyun sektörünün sorunu
      Bu yazıda geçen hiçbir şey, en belirsiz anlamıyla bile, önemsiz değil. Yazar, GPU shader render etme konusunda dünyadaki neredeyse herkese kıyasla açıkça bir 100x geliştiriciye daha yakın
      “Basit yaklaşım” mı, gerçekten basit mi?
      8 milyar insanın kaçta kaçı bu yazıya başlamak için gereken “Hello World” seviyesini bile hayata geçirebilir? Kaçı shader’ın ne olduğunu bilir? OpenGL işleri zaten o kadar yaygın değil. “OpenGL de ne, biz sadece Unity kullanıyoruz” denmesi de sık görülen bir şey
      Peki ya çevrimiçi oyuncular? 28 Temmuz 2024 saat 13:22 EST itibarıyla Counter Strike 2’de çevrimiçi olan 1,021,282 kişi [1] içinden, oynadıkları oyunda gereken shader’ın ilk adımını bile yazabilecek olanların oranı kaçtır?
      Kaç kişi basit bir komut satırı C++ programını derleyebilir ya da tarayıcıda bundan da basit bir JavaScript betiği yazabilir? Aslında bu biraz tuzak soru, çünkü çoğu insan e-postayı bile zar zor kullanıyor
      [1] https://steamdb.info/app/730/charts/
    • Engebeli bir heightmap oluşturup sonra erozyon simülasyonu ile arazi üreten yaklaşımlar gördüm
    • Bu yazıyı “yayınlanmaya hazır seviye”den çok iyi bir başlangıç noktası olarak gördüm
      Yapay zekada olduğu gibi, en iyi prosedürel içerik üretiminde bile nihai çıktı için özel son işleme yapılacaktır

  • Web’de kullanılan çeşitli prosedürel teknikleri iyi toparlayan bir yazı; gerçekten faydalı
    Üzerinde çalıştığınız prosedürel RPG seviye editörüyle ilgileniyorsanız https://github.com/gamedevgrunt/3D-Action-RPG-JavaScript bağlantısına da bakabilirsiniz

  • Derinlik ön geçişi ile deneyimlerim karışıktı
    Bunu birkaç kez denediğimde orta ve üst seviye masaüstü GPU’larda kayda değer bir performans artışı görmedim
    Bunun tam nedeninden emin değilim, ama erken Z elemesi piksel shader çağrılarını azalttığı için olabilir diye düşünüyorum. Genelde opak mesh’leri önden arkaya doğru render ederiz
    Ancak benim deneylerim oyun değil, CAD/CAM uygulamaları bağlamındaydı. Sahneler de tipik oyun ortamlarından oldukça farklıydı; az dokulu ama çok yüksek poligon sayılı geometri içeriyordu

    • Bu tür tekniklerin hepsi bağlama bağlıdır; yalnızca oyuna ve motora değil, belirli sanat varlıklarına ve sahne düzenine de bağlıdır
      Derinlik ön geçişi çoğu zaman gizlenme ayıklamanın ilk adımıdır, ama bu da aynı şekilde duruma göre değişir. CAD modellerinden çok karmaşık şehir manzaralarında çok daha faydalı olma ihtimali yüksektir
    • Eğer darboğazınız tepe noktası işleme tarafındaysa, derinlik ön geçişi yardımcı olmaz
      En çok, derinlik karmaşıklığı yüksekse ve fragment shader pahalıysa işe yarar. Adil olmak gerekirse oyunların çoğu bu kategoriye girer
      Deferred renderer’larda genelde zorunlu değildir, ama forward+ için çoğu zaman epey fayda sağlar