Neden 'Cities: Skylines 2' düşük performans veriyor

 (blog.paavo.me)
2 puan yazan GN⁺ 2023-11-06 | 1 yorum | WhatsApp'ta paylaş
  • Cities: Skylines 2, simülasyon odaklı bir türde olmasına rağmen çoğu durumda GPU darboğazı belirgin şekilde öne çıkıyor; kıyaslamalara göre 1080p 60FPS’yi minimumun üzerindeki ayarlarda hedeflemek için yaklaşık 1000~2000 euro seviyesinde bir ekran kartı gerekiyor
  • Renderdoc ile yakalanan örnek bir kare, 87.8ms, 6705 draw call, 5 binden fazla değil 5 0 binden fazla API call ve yaklaşık 6.7GB GPU buffer/doku kullanımı gösteriyor; bu da 60FPS için gereken 16.7ms’nin çok üzerinde
  • Darboğazın temelinde, çok sayıdaki mesh için LOD eksikliği ve basit culling nedeniyle ekrana neredeyse hiç katkı yapmayan yüksek poligonlu geometrinin tekrar tekrar render edilmesi yatıyor; sadece gölge geçişi bile 40ms sürüyor ve toplam draw call’ların %72’sini oluşturuyor
  • Tartışma yaratan vatandaş dişleri gerçekten render ediliyor, ancak tek başına asıl neden bu değil; vatandaş modelleri, sahne objeleri ve dekorasyonların genelindeki aşırı vertex sayısı ve verimsiz render yaklaşımının birikmesi daha büyük sorun
  • Unity DOTS ile HDRP entegrasyonu olgunlaşmamış göründüğünden, Colossal Order’ın ECS ile renderer bağlantısı, culling, sanal dokulama gibi parçaları doğrudan kendisinin uyguladığı anlaşılıyor; CPU darboğazı azaltılmış olsa da grafik pipeline yeterince rafine edilmemiş görünüyor

Çıkış öncesi ve sonrasında ortaya çıkan performans sorunları

  • Cities: Skylines 2 için daha çıkmadan önce önerilen sistem gereksinimlerinin yükseltilmesi, konsol sürümünün 2024’e ertelenmesi ve performansla ilgili konuşma kısıtlamaları gündeme gelmişti
  • Çıkıştan bir hafta önce Colossal Order, performans sorunlarına ön açıklama niteliğinde bir duyuru yaptı; çıkıştan sonra da performans neredeyse herkesin eleştirdiği bir konu oldu
  • Şehir kurma oyunlarında yüksek kare hızına ulaşmak zor olabilir, ancak bu oyunda türde sık görülen CPU darboğazından çok GPU darboğazı öne çıkıyor
  • PC Games Hardware ve Gamers Nexus kıyaslamalarına göre, 1080p 60FPS için “very low” ve üzeri ayarlarda yaklaşık 1000~2000 euro seviyesinde bir GPU gerekiyor
  • RTX 3080, Ryzen 7 5800X ve 5120×1440 monitörlü bir sistemde ilk açılışta ana menü 10FPS’nin altındaydı; geliştiricinin önerdiği gibi depth of field, motion blur ve volumetric effects kapatılınca bu değer yaklaşık 90FPS’ye çıktı
  • Boş haritada yaklaşık 30~40FPS alındı ve yaklaşık bir saatlik oynanış sonrasında da benzer seviye ile ara sıra takılmalar devam etti

Motor ve render yapısı

  • Cities: Skylines 2, Unity 2022.3.7 tabanlı ve Unity’nin DOTS, ECS ve Burst compiler teknolojilerini kullanıyor
  • DOTS sayesinde oyunun, ilk oyuna kıyasla çok sayıda CPU çekirdeğini çok daha verimli kullandığı görülüyor
  • Oyun mantığı kod tarafında yaklaşık 1200 sistemden oluşuyor ve pratikte oyun mantığının büyük kısmı ECS yapısının üzerine kurulmuş görünüyor
  • Arayüz için Unity UI Toolkit yerine HTML, CSS ve JavaScript tabanlı Coherent Gameface kullanılıyor
    • JS bundle içinde React ve Webpack kullanımına dair izler var
    • Bu yapı bakım ve değişiklik açısından avantaj sağlayabilir, ancak incelenen verilere göre ana darboğaz bu değil
  • Grafik tarafında Direct3D 11 ve Unity HDRP kullanılıyor
  • DOTS/ECS ile yazılmış bir oyunu mevcut Unity render sistemiyle bağlamak için ayrı bir katman gerekiyor, ancak Cities: Skylines 2’nin Unity Entities Graphics kullanmadığı anlaşılıyor
    • Entities Graphics içindeki skinning ve occlusion culling deneysel olarak işaretlenmiş durumda
    • virtual texturing desteği yok
    • Bunun yerine BatchRendererGroup ve düşük seviyeli kod kullanılarak özel bir bağlantı katmanı uygulanmış görünüyor

Renderdoc analiz ortamı ve sınırlamalar

  • Render analizi için Renderdoc kullanıldı
  • Game Pass sürümü, sandbox veya dosya izinleri nedeniyle Renderdoc ve NVidia Nsight Graphics’in çalıştırılabilir dosyaya erişmesine izin vermedi
  • Steam sürümünde de Paradox Launcher ve Steam doğrulama akışı nedeniyle normal yöntemlerle Renderdoc bağlamak zordu; sonunda Renderdoc’un Global Process Hook özelliğiyle yakalama yapılabildi
  • NVidia Nsight Graphics, Steam’i Nsight içinden açıp ardından oyunu çalıştırma yöntemiyle kullanılabildi; ancak D3D11’de birçok profiling özelliği desteklenmediği için Renderdoc’tan daha fazla bilgi sağlamadı
  • Analiz edilen kare yaklaşık 1000 nüfuslu bir şehirden alındı
    • Oyun sürümü 1.0.11f1
    • Daha yeni 1.0.12f1 yaması bazı iyileştirmeler içeriyor, ancak tüm sorunları çözmüyor
    • Renderdoc’un ölçtüğü kare süresi 87.8ms, yani yaklaşık 11.4FPS
    • Gerçek oynanışta ortalama 30~40FPS görüldüğünden, bunun Renderdoc overhead’inden veya o kareye özgü bir aykırılıktan kaynaklanmış olabileceği düşünülüyor

Örnek karenin render metrikleri

  • Renderdoc’un raporladığı örnek kare istatistikleri şöyle
    • Draw calls: 6705
    • Dispatch calls: 191
    • API calls: 53361
    • Index/vertex bind calls: 8724
    • Constant bind calls: 25006
    • Resource update calls: 1679
    • Textures: 342 adet, yaklaşık 3926MB
    • Render targets: 180 adet, yaklaşık 2328MB
    • Buffers: 4144 adet, yaklaşık 447MB
    • GPU buffer ve doku toplamı: yaklaşık 6.7GB
  • 6.7GB VRAM kullanımı, nispeten basit bir sahne için yüksek ve güncel orta seviye GPU’lar arasında hâlâ 8GB VRAM’e sahip modeller bulunuyor
  • FAQ’ye eklenen analize göre bu karenin render edilmesi için 121 milyon input vertex ve yaklaşık 36 milyon rasterized triangle işlendi
    • Bu sayı ekranda gerçekten görülen toplam poligon miktarı değil, tüm render pass’leri boyunca işlenen toplam geometri miktarı
    • Reddit’te daha büyük şehirlerde yüz milyonlarca vertexe, bazı durumlarda kare başına 1 milyar vertexe kadar çıkıldığına dair raporlar da var

DOTS instancing ve GPU veri güncellemesi

  • Neredeyse tüm draw call’lar instancing kullanıyor
  • Oyun, tüm nesneleri render etmek için gereken instance verilerini tek büyük bir buffer içinde tutuyor
  • Normal oyun nesneleri instance başına yaklaşık 50 float kullanıyor; yollar ise daha fazla veri kullanıyor gibi görünüyor
  • Görünen tüm nesnelerin instance verileri her karede buffer’a yazılıyor ve GPU’ya yükleniyor
  • Buffer yaklaşık 60MB ile başlıyor ve gerekirse daha büyük boyuta yeniden tahsis ediliyor
  • Bu buffer neredeyse tüm draw call’larda kullanılıyor ve Renderdoc’a göre hem vertex shader hem de pixel shader tarafından erişilebilir durumda
  • Bu da her vertex için buffer sorgulama maliyeti doğurabilir ve yüksek poligonlu mesh sorunuyla birleşebilir

Simülasyon ve sanal dokulama

  • GPU compute shader’lar su, kar, partiküller ve iskelet animasyonu gibi grafikle ilgili simülasyonlar için kullanılıyor
  • Bu işler toplamda yaklaşık 1.5ms sürüyor; yani toplam kare süresinin %2’sinden az
  • Oyunun gerçek simülasyon yükünü büyük ölçüde GPU’ya offload ettiği yönündeki ilk tahminler, decompile edilen kod ve GPU call verileriyle doğrulanmıyor
  • Cities: Skylines 2’nin kendi sanal dokulama/doku akışı sistemini uyguladığı görülüyor
    • Unity’nin yerleşik Streaming Virtual Texturing sistemi hâlâ deneysel ve desteklenmeyen durumda
    • Oyun, arazi dışında kalan çoğu statik 3D nesnede sanal dokulama kullanıyor gibi görünüyor
  • Sanal dokulama yalnızca gerekli doku parçalarını yükleyerek bellek tasarrufu sağlayabilir, ancak mevcut uygulamada yakındaki yüzeylerde bile yüksek çözünürlüklü dokuların yüklenmemesi sorunu var
  • anisotropic texture filtering desteğinin olmaması da sanal dokulama kullanımıyla ilişkili olabilir
  • İlgili pass yaklaşık 0.5ms sürüyor

Başlıca render pass’lerinin maliyeti

  • Skybox generation

    • Unity HDRP’nin fizik tabanlı gökyüzü sistemiyle her karede bir cubemap üretiliyor
    • Bunun maliyeti yaklaşık 0.65ms; 60FPS hedefinde kare bütçesinin neredeyse %4’ü

  • Pre-pass

    • Deferred rendering’in ilk adımı olarak depth, normal ve smoothness tahmin bilgileri ayrı dokulara yazılıyor
    • Yaklaşık 8.2ms sürdüğü için oldukça ağır

  • Motion vectors

    • anti-aliasing ve motion blur için gereken piksel başına motion vector’ler ayrı bir pass’te render ediliyor
    • Yaklaşık 0.6ms sürüyor
    • motion vector’lerin kısmen bozuk göründüğü belirtiliyor; bu yüzden yazının yazıldığı tarihte DLSS veya FSR2 desteği bulunmuyor

  • Roads and decals

    • Yollar, çimler ve arazi yüzeyine oturan öğeler render ediliyor
    • Yaklaşık 1ms sürüyor

  • Main pass

    • Deferred rendering’in ana pass’i; önceki buffer’lar ve sanal doku önbelleği kullanılarak albedo, normal, PBR özellikleri, depth vb. üretiliyor
    • sanal doku visibility bilgisi de burada oluşturuluyor
    • Yatay çözünürlüğün yarısında render ediliyor gibi görünüyor; arazi ise sanal dokulama kullanmadan tam çözünürlükte render ediliyor
    • Yaklaşık 16.7ms sürüyor; yani tek başına 60FPS için tüm kareye ayrılan süre kadar

  • Ambient occlusion

    • shader debug name’e göre GTAO kullanılıyor
    • Yaklaşık 1.6ms sürüyor

  • SSR + SSGI

    • Unity HDRP’nin screen space reflections ve screen space global illumination çözümleri kullanılıyor
    • İki efekt birlikte yaklaşık 3ms sürüyor

  • Deferred lighting

    • Daha önce üretilen ara buffer’lar birleştirilerek neredeyse nihai görüntüye yakın sonuç elde ediliyor
    • Yaklaşık 2.1ms sürüyor

  • Water rendering

    • compute shader ön işlemesi ve küçültülmüş/bulanıklaştırılmış görüntü girdileri kullanılarak su yüzeyi render ediliyor
    • Yaklaşık 1ms sürüyor

  • Post-processing

    • temporal AA, bloom, tonemapping ve etkinse DOF ile motion blur kullanılıyor
    • Toplam maliyet yaklaşık 1~2ms

  • UI

    • Gameface tabanlı arayüz ve dünya içindeki metinler render ediliyor
    • Yol isimleri 2D signed distance fields ile çiziliyor ve depth buffer kullanılarak binaların arkasında kaldığında sahneyle harmanlanıyor
    • Nihai UI pass’inin süresi ihmal edilebilir düzeyde

Diş tartışması ve karakter modelleri

  • Vatandaş karakterlerde gerçekten tam bir diş modeli bulunuyor ve normal oyun kamerasında bu görünmüyor
  • Reddit kullanıcısı Hexcoder0’ın NVidia Nsight Graphics analiziyle, dişlerin her zaman en yüksek kalitede render edildiği ortaya çıktı
  • Daha önemli sorun, karakterle ilgili mesh’lerin genelinde LOD varyantı bulunmaması
  • Colossal Order bu sorunu kamuya açık şekilde kabul etti ve daha geniş kapsamlı LOD problemlerinden de söz etti
  • Vatandaş modelleri Didimo Popul8 tabanında üretiliyor; oyundaki diş/ağız modeli 6108 vertex ile Didimo’nun varsayılan 1060 vertexlik mesh’inden daha yoğun
  • Saç, kıyafet ve aksesuarlar hariç tek bir karakter yaklaşık 56 bin vertex içeriyor
    • Ortalama düşük yoğunluklu bir konut binası, bahçe objeleri ve küçük detaylar hariç tutulduğunda 10 bin vertex’in altında kalıyor
  • Örnek karede 13 diş seti render ediliyor, ancak nihai görüntüde tek bir pikseli bile etkilemiyorlar
  • Dişler, performans düşüşünün tek başına nedeni olmaktan çok, gereksiz yüksek poligonlu geometrinin ne kadar yaygın olduğunun bir göstergesi

Yüksek poligonlu sahne objeleri ve culling sorunu

  • Oyun, nihai görüntüye çok az ya da hiç katkı yapmayan nesneleri gereğinden fazla sayıda ve çok yüksek poligonla render ediyor
  • Bunun iki temel nedeni var
    • Bazı modellerde LOD varyantı yok
    • Özel culling sistemi basit; yalnızca frustum culling uygulanmış görünüyor ve occlusion culling’e dair iz yok
  • Mesafeye dayalı culling var, ancak agresif olmadığı için pop-in azalırken performans olumsuz etkileniyor
  • İncelenen yüksek poligonlu sahne objelerinden bazıları şunlar
    • Gaz tüpü paleti: 17 bin vertex üzeri
    • Çamaşır ipi objesi: adet başına 25 bin vertex, daha yoğun varyantta 30 bin vertex üzeri
    • Otopark kulübesi: 40 bin vertex üzeri, LOD yok; monitör ve klavyeyi bağlayan kablolar bile ayrı ayrı modellenmiş
    • Kütük yığını: 100 bin vertex üzeri
  • Bina ve iç mekân objelerinin tek mesh’te birleştirilmesi draw call sayısını azaltabilir, ancak iç objelerin ayrı ayrı culling yapılmasını engeller
  • Şehir kurma oyunlarında aynı verimsiz model bir kare içinde yüzlerce kez render edilebildiğinden, küçük israf kalemleri zamanla büyük maliyete dönüşüyor
  • Sorun tek başına yüksek çözünürlüklü modeller değil; asıl sorun oyunun bu detay seviyesini kaldıramaması ve poligon kullanımının verimsiz, tutarsız olması

Gölge pass’i en büyük darboğaz

  • Cities: Skylines 2, cascaded shadow mapping kullanıyor
  • Gölgelere ait artifact ve flickering sık görülüyor; özellikle güneş veya yapraklar hareket ettiğinde bu daha belirgin hale geliyor
  • Oyun 4 cascade kullanıyor ve her cascade’in çözünürlüğü 2048×2048
  • Gelişmiş grafik ayarlarında directional shadow map resolution seçeneği var, ancak yazının yazıldığı tarihte koddaki karşılığı çalışmıyor
    • Tekil ayarlar veya genel shadow quality ayarı, shadow map resolution’ı değiştirmiyor
    • medium ve high shadow preset’leri fiilen aynı
    • low preset yalnızca arazinin oluşturduğu gölgeleri kapatıyor
  • Kalite düşük olmasına rağmen shadow mapping yaklaşık 40ms ile en yavaş render pass’i
  • Örnek karedeki 6705 draw call’ın 4828 tanesi, yani %72’si, shadow mapping için kullanılıyor
  • Oyun, tüm 3D nesneleri boyut ve mesafeden bağımsız olarak tüm kalite ayarlarında potansiyel shadow caster gibi ele alıyor görünümünde
  • Renderdoc performans sayaçlarında birçok draw call’ın shadow map üzerinde yalnızca 0~100 pikselden az alana etki ettiği görülüyor; dişler de gölge pass’inde yeniden ortaya çıkıyor
  • LOD ve culling iyileştirmeleri, shadow mapping performansını da ciddi biçimde etkileyebilir
  • Olumlu bir ayrıntı olarak oyun, güneş ve ayın konumunu şehrin güncel tarih, saat ve koordinatlarına göre hesaplıyor

Ana menüdeki performans sorunu

  • Ana menü yalnızca statik bir arka plan görseli ve butonlardan oluşuyormuş gibi görünse de, gerçekte sürekli var olan bir 3D sahne bulunuyor
  • Menü arkasında arazi, su ve skybox içeren bir sahne render ediliyor; ardından arayüz bunun tamamını kapatıyor
  • Görünmeyen bu sahne için de tüm render pipeline çalıştığından, grafik ayarları ana menü performansını da anında etkiliyor
  • Çıkış sırasında çoğu ayar varsayılan olarak neredeyse en yükseğe yakındı ve geliştiricinin kapatılmasını önerdiği ağır efektler de açıktı
  • Yine de ilk açılışta performansın 7FPS seviyesine kadar düşmesinin nedeni tam olarak açıklanabilmiş değil
    • Aynı seviyedeki düşüş daha sonra tekrar üretilemedi
    • İlk açılışta sanal doku önbelleğiyle ilgili işlemler yapılıyor, ancak bunların GPU kullanıp kullanmadığı doğrulanmadı
  • Ana menü sahnesinin tamamı yaklaşık 400 draw calls, 563 bin input vertex ve 745 bin rasterized triangle içeriyor

FAQ’de netleştirilen yorumlar

  • Oyunun Unreal Engine 5 ile yapılmış olması gerekip gerekmediği konusunda kesin bir yargıya varmak zor
    • UE5; Nanite, Lumen ve Virtual Shadow Maps ile C:S2’nin yaşadığı bazı sorunlara çözüm sunabilirdi
    • Buna karşılık Unity ECS’ye denk, büyük ölçekli oyun mantığı ve simülasyon için üretim seviyesinde özellikleri eksik; ayrıca C++ ağırlıklı yapı, modlama esnekliği ve erişilebilirlik açısından dezavantajlı olabilir
  • Oyunda hiç LOD yok demek doğru değil
    • Birçok binada uygun LOD bulunduğu görülüyor
    • Borular, bahçe objeleri ve dekoratif öğeler gibi unsurlarda ise LOD’nin olmadığı veya seçilmediği birçok örnek var
  • InstaLOD’un oyunun asset pipeline’ında, özellikle mod araçlarıyla yeni asset içe aktarılırken kullanıldığı; runtime render tarafında ise kullanılmadığı anlaşılıyor
  • JavaScript tabanlı arayüz, incelenen verilere göre ana darboğaz değil
    • Gameface, Electron gibi tam teşekküllü bir tarayıcı motoru tabanlı değil; oyun arayüzü için özelleştirilmiş bir framework
    • Chromium/Blink veya WebKit tabanlı çözümlere göre bellek kullanımı ve performansta daha avantajlı olması bekleniyor
  • Renderdoc’un hassas benchmark aracı olarak sınırlamaları var, ancak “oyun neden yavaş” sorusunu anlamak için yeterli kanıt sunuyor

Sonuç: CPU darboğazı azaltılmış, ancak GPU pipeline neredeyse tamamlanmamış durumda

  • Cities: Skylines 2’nin GPU üzerinde bu kadar ağır olmasının doğrudan nedeni, ekran kartına gereksiz geometriyi fazlasıyla göndermesi
  • Bu geometri israfı, birçok mesh’te LOD eksikliğinden ve basit, yeterince ayarlanmamış culling uygulamasından kaynaklanıyor
  • Özel culling ve render bağlantı katmanının uygulanma nedeni, Unity DOTS ile HDRP entegrasyonunun hâlâ gelişim aşamasında olması ve gerçek bir oyunda kullanmak için ciddi sınırlara sahip görünmesi olabilir
  • Unity’nin sanal dokulama sistemi de deneysel durumda olduğundan, Colossal Order kendi çözümünü geliştirmiş; ancak bu sistem de henüz tam olgunlaşmış görünmüyor
  • Muhtemel tablo şu: Colossal Order, Unity’nin yeni teknolojisi DOTS’a yatırım yaparak CPU darboğazı ve simülasyon ölçeği tarafında kazanım elde etti, ancak grafik tarafında culling, animasyon ve doku akışı gibi sistemleri kendisinin kurması gerekti
  • Geliştiricinin oyunun en baştan 30FPS hedefiyle tasarlandığı yönündeki açıklaması ikna edici bulunmuyor; bunun, salt PC oyunu olması ve grafik kalitesi düşünüldüğünde performans hedefi olarak haklı gösterilmesi zor görülüyor
  • Çözüm potansiyeli en yüksek alanlar; LOD eklenmesi, culling’in iyileştirilmesi, shadow caster seçiminde optimizasyon ve sahne objesi bazında asset temizliği; ancak çok sayıda asset’in tek tek elden geçirilmesi gerekebileceğinden bunun zaman alması bekleniyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-06
Hacker News görüşleri

  • İlginç bir yazı; tartışmanın özellikle neyin ilginç olduğuna odaklanmasını isterim.
    Bu tür başlıklar kolayca $THINGin kendisi, burada genel olarak oyun, ya da $RELATED, burada framework, ya da benzer konuların geneline dair genel geçer tartışmalara kayabiliyor.
    İlkesel olarak kötü değil ama genellemeye doğru atılan her adımda tartışma sığlaşıyor ve daha az ilginç hale geliyor. Bu yüzden site yönergelerinde de “genel yan tartışmalardan kaçının” maddesi var - https://news.ycombinator.com/newsguidelines.html

  • “Colossal Order’ın Unity’nin yerleşik culling’ini kullanmayıp kendi uygulamasını bulundurmasının nedeni, DOTS ve HDRP’nin Unity entegrasyonunun hâlâ yoğun biçimde geliştirilmekte olması ve gerçek oyunların çoğu için uygunsuz sayılabilmesi; bu yüzden grafik tarafının önemli bir bölümünü kendilerinin uygulamak zorunda kalmaları” kısmı, Unity araçlarıyla ilgili deneyimimle üzücü biçimde örtüşüyor.
    DOTS yayımlandı ama Unity’nin satın aldığı diğer araçlar gibi uygulaması sahipsiz bırakılmış gibi hissettiriyor. Şirketin yönetiminde ciddi bir yanlışlık var; birkaç hafta önce kamuoyuna açık biçimde patlayan fiyatlandırma olayı da motoru iyileştirmekten çok kullanıcılardan daha fazla para koparmanın yollarına odaklandıklarını düşündürüyor.
    Bevy’nin ECS uygulaması gerçekten iyi; Godex ile birlikte bu alanda başarılı olmasını isterim.

    • Unity her yıl 1 milyar dolara kadar gelir yakıyor gibi görünmesine rağmen motorun hâlâ yarı pişmiş, bitmemiş bir ürün gibi hissettirmesini anlayamıyorum. Bütün o para nereye gidiyor?
    • Godex sonuçta domuza ruj sürmek gibi. Performansı biraz iyileştirebilir ama ECS, eklenti gibi sonradan eklenince çalışan sihirli bir optimizasyon değil.
      Oynanış katmanındaki cache tutarlılığı, motor düzeyindeki darboğazları düzeltemez.
    • Açıkçası yüksek performanslı oyun çıkarmanın birçok yolu var; ECS ne şart ne de mutlaka modern yöntem. Oyun kurmak için kullanılabilecek birçok mimari desenden biri ve pek çok artısı da eksisi de var.
      Örneğin Godot, ECS merkezli değil; render ve fizik gibi uzmanlık alanlarının çoğunu bağımsız ele alan, otonom oyun alt sistemleri olan “server” kavramı etrafında dönüyor ve genel oyun mantığıyla gevşek bağlı.
      ECS mimarisi, CPU’ların berbat olduğu PS2/PS3 dönemlerinden doğdu. Küçük cache’ler, yüksek branch prediction hatası maliyeti, yavaş bellek, parçalanmış bellek alanı ve rastgele erişimli depolamanın yokluğu yüzünden geliştiriciler oyunları öngörülebilir bellek erişim desenlerine göre yapmak zorundaydı; bunun sonucunda oyun verilerini küçük parçalar halinde stream ederek işleyen yapı yaygınlaştı.
      Bu yaklaşım bugün de genel olarak iyi bir pratik ama çok hızlı CPU’lar, gelişmiş speculative execution, iyi branch predictor’lar ve onlarca MB cache ortaya çıkınca artık katı bir zorunluluk değil. Özellikle modern oyunların ekranda olup bitenlerin ölçeğini 10–20 yıl öncesine göre o kadar da büyütmediği düşünülürse. Aksiyon oyunlarında oyuncunun aynı anda bir düzineden fazla düşmanla savaştığı durumlar hâlâ nadir.
      Ekranda aynı anda binlerce öğenin göründüğü oyunlarda genellikle ayrı, uzmanlaşmış mantık ve işleme gerekir.
    • DOTS, Unity içinde yapılmadı mı?

  • Bu oyunu deneyecek olanlara ipucu: çözünürlük ölçeklendirmeyi dinamikten sabite alın.
    3080’de ana menü “oynanamaz 10fps” seviyesindeyken, oyun içinde orta-yüksek ayarlarda “sorunsuz gayet iyi çalışıyor” seviyesine geldi.

    • Tamamen kapatabilirsiniz de. Benim 3080’imde çok sayıda render artefaktı üretiyor gibi.
    • Çözüm bu değil. Motion blur ve alan derinliğini kapatmak gerekiyor. Özellikle alan derinliği menü performansını öldürüyor.

  • Not olarak, Crysis’te benchmark sahnesinde bir karede yaklaşık 300 bin vertex ya da triangle olduğunu hatırlıyorum. Bu durumda hafızamın hangi yönde yanıldığına ve her modelin vertex/triangle oranının ne kadar kötü olduğuna bağlı olarak 3–10 kütük yığını seviyesinde oluyor.

    • Yazının sahibiyim: RenderDoc’ta kare başına toplam vertex sayısını saymanın kolay bir yolunu bulamadığım için kendim saymadım. Ancak Reddit’te biri ReShade ile toplam vertex sayısını ölçmüş; büyük bir şehrin yakın çekim sahnelerinde yüz milyonlardan 1 milyar vertexe kadar çıkabildiğini söylüyor.
      Düzenleme: RenderDoc ile vertex ve polygon sayılarını kontrol ettim. Yazıdaki örnek sahne 121 milyon vertex ve 40 milyondan fazla triangle işliyor.
    • Doğru gibi. Performans HUD’ında “1M Triangles” gördüğümü ve bir milyon triangle’ın delilik olduğunu düşündüğümü hatırlıyorum. Kenar ayrımı, billboard’lar vb. düşünülürse paylaşılan vertex’in de neredeyse hiç olmaması muhtemel.

  • Yazım tarzı gerçekten hoşuma gitti:
    “Bu pass yaklaşık 8,2 milisaniye, yani kabaca saçma derecede uzun sürdüğü için şaşırtıcı derecede ağır…” gibi cümleler.

    • Biraz ciddi yazılarda bile bu şekilde küçük mizah serpiştiren daha fazla insan olmasını isterdim.

  • “Bu kütük yığını mesh’i de yalnızca gölge render pass’inde kullanılıyor ama 100 binden fazla vertex içeriyor” ha… Ama neden?

    • Çünkü oyun geliştirmede dikkat edilmesi gereken yaklaşık 1 milyon şey var. Birinin ya da bir yazılımın LOD ayarlarında hata yapmış olması muhtemel. Ya da dinamik LOD kodu LOD0 mesh’ini düzgün cull edememiş olabilir, o kodu zamanında tamamlayamamış olabilirler ya da bambaşka bir nedeni olabilir.
      AAA bir oyunda bazı eksik ve optimize edilmemiş unsurların bulunması tamamen normal. Bütçe hep sınırlı, geliştirme süresi kısa. Üstelik sonuçları garanti olmayan, hit olmaya bağımlı bir sektör. Bir oyunun başarı ihtimalini artırmanın bazı yolları var ama bunlar genellikle geliştirmeden çok yönetime yakın ve beklenen ön sipariş geliri pek tutarlı tahmin edilemiyor. Bu yüzden riski azaltmak için tavizler vermek, mümkün olan yerlerde maliyeti kısmak ve en pahalı geliştirme önceliklerini aşağı çekmek gerekiyor. Bu tavizler tek bir mesh’in optimize edilmemiş olmasından çok daha büyük. Tek bir mesh hiçbir şeydir.
      Bu mesh’in LOD0 olması ve diş mesh’inin de LOD0 olması ilginç bir gerçek. Ama tek başına oyunun performansını çökerten şey bu değil ve gerçek performans düzeltmeleri yerine bunu düzeltmeleri de pek olası görünmüyor. Bu başlıkta insanların böyle mesh’lere takılması biraz aşırı.
      Duygusal olarak hararetli çok yorum var; buna daha fazlasını eklemek istemiyorum, yalnızca daha fazla bağlam vermeye çalışıyorum.
    • Yaklaşık 100 vertex ve akıllı bir normal map ile halledilebilirdi; bu düpedüz akıl almaz bir seviye.
    • Bu oyunu yapan stüdyoda yaklaşık 30 geliştirici var.

  • Oyunun son derece ayrıntılı modeller kullanırken, gerçek pikseller olarak görünmeyecek şeyleri akıllıca soyutlayacak ya da cull edecek bir yönteme sahip olmadığı özeti doğru mu?
    Eğer öyleyse bu kolayca düzeltilebilir mi, yoksa çözmek için tasarımdan başlayarak yeniden ele alınması gerekecek kadar çekirdek yapıya mı işlemiş?

    • Düzeltmenin zorluğu ancak tahmin edilebilir. Uzmanı değilim ama culling ve LOD’un motorda büyük eksenlerden biri olduğunu düşünüyorum. Mevcut uygulamayı kullanamıyor olmaları gerçekten kötü bir durum.
      “Yöntemler” muhtemelen iyi biliniyordur, ama uygulamasının kolay olduğunu sanmıyorum.

  • DOTS, Mike Action’ın fikrinden çıktı. 2014’teki CppCon sunumu “Data-Oriented Design and C++”a bakabilirsiniz [1]. Ancak Twitter’a göre Mike Unity’den ayrılmış.
    [1] https://www.youtube.com/watch?v=rX0ItVEVjHc

    • Orijinal yazı DOTS’un pürüzlü yanlarından söz etmiş olsa da, yazıda gerçekten nedenin DOTS olduğunu düşündürecek bir şey görmedim. Sorun DOTS olsaydı CPU overhead’i yaratırdı; burada ise daha çok inanılmaz derecede aşırı ayrıntılı geometriyi bolca kullanıp LOD sistemi uygulamamışlar gibi görünüyor.
      UE5’in Nanite’ı olsaydı belki bir şekilde idare edebilirdi, ama bu kadar aşırı geometri başka her şeyi çökertirdi.
    • Spor oyunları vb. hariç son derece şüpheli bir veri setiyle 30fps oyunların 60fps oyunlardan daha iyi sattığını söyleyen Mike Action’dan mı bahsediyoruz?

  • Proton Experimental’da 1080p’de boş bir haritada bile birkaç fps’in üstüne çıkarmak için 40 dakika harcadım, ama vazgeçip iade ettim. Berbat performansı düzeltirlerse tekrar denemeyi düşünüyorum.
    İlk oyundan gerçekten çok keyif almıştım; bu oyunu oynayamamak çok üzücü.

    • Çözüm tek bir tweet’e sığıyor -> https://twitter.com/ColossalOrder/status/1716883884724322795
      “Performans sorunları yaşıyorsanız, performansı etkileyen sorunları çözerken ekran çözünürlüğünü 1080p’ye düşürmenizi, alan derinliği ve volumetrics’i kapatmanızı, global illumination’ı düşürmenizi öneririz.”
      AMD Radeon RX 5700 XT’de akıcı performans almak için yaptığım tek şey buydu.
    • GeForce Now’da oldukça oynanabilir. Yine de biraz takılıyor, ama büyük sorun yaşamadan saatlerce oynayabildim. Ara sıra can sıkıcı takılmalar oluyor, fakat katlanılabilir düzeyde.