Mengapa Performa 'Cities: Skylines 2' Buruk

 (blog.paavo.me)
2 poin oleh GN⁺ 2023-11-06 | 1 komentar | Bagikan ke WhatsApp
  • Meski Cities: Skylines 2 adalah genre yang berfokus pada simulasi, pada sebagian besar situasi bottleneck GPU sangat menonjol, dan ada benchmark yang menunjukkan bahwa untuk menargetkan 1080p 60FPS pada pengaturan di atas minimum dibutuhkan kartu grafis di kisaran sekitar 1.000–2.000 euro
  • Contoh frame yang ditangkap dengan Renderdoc menunjukkan 87,8 ms, 6.705 draw call, lebih dari 50 ribu API call, serta penggunaan buffer dan tekstur GPU sekitar 6,7 GB, jauh dari 16,7 ms yang menjadi acuan 60FPS
  • Inti bottleneck-nya adalah banyak mesh yang kekurangan LOD dan culling yang sederhana, sehingga geometri high-poly yang hampir tidak berkontribusi ke layar dirender berulang-ulang; shadow pass saja memakan 40 ms dan 72% dari total draw call
  • Gigi warga yang sempat menjadi kontroversi memang benar dirender, tetapi bukan penyebab tunggal; masalah yang lebih besar adalah akumulasi jumlah vertex berlebihan pada model warga, properti, dan dekorasi secara umum serta rendering yang tidak efisien
  • Integrasi Unity DOTS dan HDRP yang belum matang menunjukkan indikasi bahwa Colossal Order mengimplementasikan sendiri penghubung ECS dengan renderer, culling, virtual texturing, dan lainnya; bottleneck CPU memang berkurang, tetapi pipeline grafis tampaknya belum cukup dipoles

Masalah performa yang terungkap sebelum dan sesudah rilis

  • Cities: Skylines 2 sejak sebelum rilis sudah mengalami kenaikan spesifikasi rekomendasi, penundaan versi konsol ke 2024, dan pembatasan pembahasan terkait performa
  • Seminggu sebelum rilis, Colossal Order menerbitkan pengumuman yang mendekati klarifikasi awal tentang masalah performa, dan setelah rilis performanya menjadi sasaran kritik yang hampir universal
  • Game pembangunan kota memang bisa sulit mencapai frame rate tinggi, tetapi game ini lebih menonjol pada bottleneck GPU ketimbang bottleneck CPU yang umum di genre ini
  • Berdasarkan benchmark PC Games Hardware dan Gamers Nexus, ada hasil yang menunjukkan bahwa untuk mencapai 1080p 60FPS pada pengaturan di atas “very low” diperlukan GPU di kisaran sekitar 1.000–2.000 euro
  • Pada lingkungan RTX 3080, Ryzen 7 5800X, dan monitor 5120×1440, menu utama saat pertama kali dijalankan berada di bawah 10FPS; setelah menonaktifkan depth of field, motion blur, dan volumetric effects sesuai rekomendasi pengembang, naik hingga sekitar 90FPS
  • Di peta kosong didapat sekitar 30–40FPS, dan setelah bermain sekitar satu jam level yang mirip serta stutter sesekali tetap terjadi

Struktur engine dan rendering

  • Cities: Skylines 2 berbasis Unity 2022.3.7, serta memanfaatkan DOTS, ECS, dan Burst compiler dari Unity
  • Berkat DOTS, game ini tampaknya menggunakan banyak core CPU jauh lebih efisien dibanding pendahulunya
  • Logika game tersusun dari sekitar 1.200 sistem di kode, dan secara praktis sebagian besar logika game tampaknya berada di atas struktur ECS
  • UI tidak menggunakan Unity UI Toolkit, melainkan Coherent Gameface berbasis HTML, CSS, dan JavaScript
    • Di bundle JS ada jejak penggunaan React dan Webpack
    • UI mungkin punya kelebihan dalam hal pemeliharaan dan modifikasi, tetapi berdasarkan data yang dianalisis bukan bottleneck utama
  • Grafis menggunakan Direct3D 11 dan Unity HDRP
  • Untuk menghubungkan game yang dibuat dengan DOTS/ECS ke sistem rendering Unity yang ada diperlukan lapisan terpisah, tetapi Cities: Skylines 2 tampaknya tidak menggunakan Unity Entities Graphics
    • Skinning dan occlusion culling di Entities Graphics ditandai sebagai experimental
    • Virtual texturing tidak didukung
    • Sebagai gantinya, tampaknya mereka mengimplementasikan lapisan penghubung sendiri menggunakan BatchRendererGroup dan kode level rendah

Lingkungan dan batasan analisis Renderdoc

  • Analisis rendering menggunakan Renderdoc
  • Versi Game Pass tidak dapat diakses executable-nya oleh Renderdoc dan NVidia Nsight Graphics karena masalah sandboxing atau izin file
  • Versi Steam juga sulit disambungkan ke Renderdoc dengan cara umum karena Paradox Launcher dan alur autentikasi Steam, dan akhirnya capture berhasil dengan Global Process Hook milik Renderdoc
  • NVidia Nsight Graphics bekerja dengan membuka Steam dari Nsight lalu menjalankan game di dalamnya, tetapi karena banyak fitur profiling tidak didukung di D3D11, informasi yang diperoleh tidak lebih banyak dibanding Renderdoc
  • Frame yang dianalisis ditangkap dari kota dengan populasi sekitar 1.000 orang
    • Versi game adalah 1.0.11f1
    • Patch terbaru 1.0.12f1 mencakup beberapa perbaikan, tetapi tidak menyelesaikan semua masalah
    • Waktu frame yang diukur Renderdoc adalah 87,8 ms, setara sekitar 11,4FPS
    • Karena rata-rata saat bermain sebenarnya 30–40FPS, ada kemungkinan overhead Renderdoc atau frame tersebut merupakan outlier

Metrik rendering pada frame contoh

  • Statistik frame contoh yang dilaporkan Renderdoc adalah sebagai berikut
    • Draw calls: 6705
    • Dispatch calls: 191
    • API calls: 53361
    • Index/vertex bind calls: 8724
    • Constant bind calls: 25006
    • Resource update calls: 1679
    • Textures: 342 buah, sekitar 3926MB
    • Render targets: 180 buah, sekitar 2328MB
    • Buffers: 4144 buah, sekitar 447MB
    • Total buffer GPU dan tekstur: sekitar 6,7GB
  • Penggunaan VRAM 6,7GB terbilang tinggi untuk adegan yang relatif sederhana, dan GPU kelas menengah generasi sekarang dengan VRAM 8GB pun masih ada
  • Menurut analisis tambahan FAQ, rendering frame tersebut mencakup 121 juta input vertices dan sekitar 36 juta rasterized triangles
    • Ini bukan jumlah total poligon yang benar-benar terlihat di layar, melainkan jumlah geometri yang diproses di seluruh render pass
    • Di Reddit juga ada laporan bahwa pada kota yang lebih besar jumlahnya mencapai ratusan juta vertex, dan dalam situasi tertentu hingga maksimum 1 miliar vertex per frame

DOTS instancing dan pembaruan data GPU

  • Hampir semua draw call menggunakan instancing
  • Game memasukkan data instance yang diperlukan untuk rendering semua objek ke dalam satu buffer besar
  • Objek game biasa menggunakan sekitar 50 float per instance, dan jalan tampaknya menggunakan lebih banyak data
  • Data instance semua objek yang terlihat diperbarui di buffer dan diunggah ke GPU setiap frame
  • Buffer dimulai dari sekitar 60MB, dan jika perlu dialokasikan ulang ke ukuran lebih besar
  • Buffer ini digunakan di hampir semua draw call, dan berdasarkan Renderdoc dapat diakses dari vertex shader maupun pixel shader
  • Biaya lookup buffer dapat terjadi pada setiap vertex, sehingga berpotensi berpadu dengan masalah mesh high-poly

Simulasi dan virtual texturing

  • GPU compute shader digunakan untuk simulasi terkait grafis seperti air, salju, partikel, dan animasi skeleton
  • Semua pekerjaan ini totalnya sekitar 1,5 ms, kurang dari 2% waktu frame keseluruhan
  • Dugaan awal bahwa simulasi sebenarnya dari game dioffload besar-besaran ke GPU tidak sesuai berdasarkan kode hasil dekompilasi dan GPU call
  • Cities: Skylines 2 tampaknya mengimplementasikan sistem virtual texturing/texture streaming sendiri
    • Streaming Virtual Texturing bawaan Unity masih berstatus eksperimental dan tidak didukung
    • Game tampaknya menggunakan virtual texturing untuk sebagian besar objek 3D statis selain terrain
  • Virtual texturing dapat menghemat memori dengan hanya memuat tile tekstur yang diperlukan, tetapi pada implementasi saat ini ada masalah tekstur resolusi tinggi tidak dimuat bahkan pada permukaan yang dekat
  • Tidak didukungnya anisotropic texture filtering juga kemungkinan terkait penggunaan virtual texturing
  • Pass tersebut memakan sekitar 0,5 ms

Biaya per pass rendering utama

  • Skybox generation

    • Menggunakan sistem langit berbasis fisika dari Unity HDRP untuk membuat cubemap setiap frame
    • Memakan sekitar 0,65 ms, hampir 4% dari anggaran frame untuk 60FPS

  • Pre-pass

    • Sebagai tahap pertama deferred rendering, mencatat depth, normal, dan informasi estimasi smoothness ke tekstur terpisah
    • Memakan sekitar 8,2 ms, tergolong sangat berat

  • Motion vectors

    • Merender per-pixel motion vector yang digunakan untuk anti-aliasing dan motion blur sebagai pass terpisah
    • Memakan sekitar 0,6 ms
    • Motion vector tampaknya sebagian rusak, dan karena itu pada saat tulisan dibuat DLSS atau FSR2 belum didukung

  • Roads and decals

    • Merender jalan, rumput, dan elemen yang mengikuti permukaan terrain
    • Memakan sekitar 1 ms

  • Main pass

    • Pass inti deferred rendering, menggunakan buffer sejauh ini dan cache virtual texture untuk menghasilkan albedo, normal, properti PBR, depth, dan lainnya
    • Informasi visibility virtual texture juga dibuat di sini
    • Tampaknya dirender pada setengah resolusi horizontal, sedangkan terrain tidak menggunakan virtual texturing dan dirender pada resolusi penuh
    • Memakan sekitar 16,7 ms, sama dengan seluruh waktu yang diperbolehkan untuk satu frame pada 60FPS

  • Ambient occlusion

    • Berdasarkan shader debug name, tampaknya menggunakan GTAO
    • Memakan sekitar 1,6 ms

  • SSR + SSGI

    • Menggunakan screen space reflections dan screen space global illumination dari Unity HDRP
    • Kedua efek ini total memakan sekitar 3 ms

  • Deferred lighting

    • Menggabungkan buffer perantara yang dibuat sebelumnya untuk menghasilkan hasil yang hampir menjadi gambar final
    • Memakan sekitar 2,1 ms

  • Water rendering

    • Merender permukaan air menggunakan praproses compute shader dan input gambar yang diperkecil serta diblur
    • Memakan sekitar 1 ms

  • Post-processing

    • Menggunakan temporal AA, bloom, tonemapping, serta DOF dan motion blur saat diaktifkan
    • Total memakan sekitar 1–2 ms

  • UI

    • Merender UI berbasis Gameface dan teks di dalam dunia
    • Nama jalan dirender sebagai 2D signed distance fields, dan menggunakan depth buffer agar dibaurkan dengan adegan saat berada di belakang bangunan
    • Waktu pass UI final sangat kecil hingga dapat diabaikan

Kontroversi gigi dan model karakter

  • Karakter warga memang memiliki model gigi lengkap, yang tidak terlihat dari sudut pandang umum dalam game
  • Melalui analisis NVidia Nsight Graphics oleh pengguna Reddit Hexcoder0, diketahui bahwa gigi selalu dirender pada kualitas maksimum
  • Masalah yang lebih penting adalah secara umum mesh terkait karakter tidak memiliki LOD variant
  • Colossal Order secara terbuka mengakui masalah ini, dan juga menyebutkan masalah pemrosesan LOD yang lebih luas
  • Model warga dibuat berbasis Didimo Popul8, dan model gigi/mulut dalam game memiliki 6.108 vertices, lebih banyak daripada 1.060 vertices pada mesh bawaan Didimo
  • Satu karakter saja, tanpa rambut, pakaian, dan aksesori, mencapai sekitar 56.000 vertices
    • Rata-rata bangunan hunian kepadatan rendah memiliki kurang dari 10 ribu vertices jika tidak menghitung properti halaman dan elemen detail
  • Pada frame contoh, 13 set gigi dirender tetapi tidak satu piksel pun memengaruhi gambar final
  • Gigi lebih tepat dilihat bukan sebagai penyebab tunggal penurunan performa, melainkan bukti bahwa geometri high-poly yang tidak perlu tersebar luas

Properti high-poly dan masalah culling

  • Game merender terlalu banyak objek yang hampir tidak atau sama sekali tidak berkontribusi pada gambar final, dengan jumlah poligon yang terlalu tinggi
  • Ada dua penyebab utama
    • Sebagian model tidak memiliki LOD variant
    • Sistem culling internalnya sederhana, hanya mengimplementasikan frustum culling dan tidak terlihat jejak occlusion culling
  • Culling berbasis jarak memang ada tetapi tidak agresif, sehingga pop-in berkurang namun merugikan performa
  • Contoh properti high-poly yang teridentifikasi adalah sebagai berikut
    • Palet tabung gas: lebih dari 17.000 vertices
    • Properti jemuran: 25.000 vertices per item, variant yang lebih padat lebih dari 30.000 vertices
    • Booth parkir: lebih dari 40.000 vertices, tanpa LOD, bahkan kabel penghubung monitor dan keyboard dimodelkan terpisah
    • Tumpukan kayu gelondongan: lebih dari 100.000 vertices
  • Menggabungkan bangunan dan properti interior menjadi satu mesh mengurangi draw call, tetapi properti di dalamnya tidak dapat diculling secara individual
  • Dalam game pembangunan kota, model tidak efisien yang sama dapat dirender ratusan kali dalam satu frame, sehingga pemborosan kecil pun terakumulasi
  • Model resolusi tinggi itu sendiri bukan masalah; masalah saat ini adalah game tidak sanggup menanggung detail tinggi tersebut dan penggunaan poligonnya tidak efisien serta tidak konsisten

Shadow pass menjadi bottleneck terbesar

  • Cities: Skylines 2 menggunakan cascaded shadow mapping
  • Shadow memiliki banyak artifact dan flickering, terutama saat matahari atau dedaunan bergerak
  • Game menggunakan 4 cascade, dengan resolusi 2048×2048 per cascade
  • Di pengaturan grafis lanjutan ada opsi directional shadow map resolution, tetapi pada saat tulisan dibuat belum tersambung di kode
    • Pengaturan individual maupun pengaturan keseluruhan shadow quality tidak mengubah shadow map resolution
    • Preset shadow medium dan high pada dasarnya sama
    • Preset low mematikan bayangan yang dilempar terrain
  • Meski kualitasnya rendah, shadow mapping adalah render pass paling lambat dengan sekitar 40 ms
  • Dari 6.705 draw call pada frame contoh, 4.828, atau 72%, digunakan untuk shadow mapping
  • Game tampaknya memperlakukan semua objek 3D sebagai calon shadow caster pada semua pengaturan kualitas, terlepas dari ukuran atau jarak
  • Dalam performance counter Renderdoc, banyak draw call hanya memengaruhi kurang dari 0–100 piksel pada shadow map, dan gigi juga muncul lagi di shadow pass
  • Perbaikan LOD dan culling dapat berdampak besar pada performa shadow mapping
  • Sebagai detail positif, game menghitung posisi matahari dan bulan menggunakan tanggal, waktu, dan koordinat kota saat ini

Masalah performa menu utama

  • Menu utama tampak hanya berisi gambar latar statis dan tombol, tetapi sebenarnya adegan 3D selalu ada
  • Di belakang menu dirender adegan yang berisi terrain, air, dan skybox, lalu UI sepenuhnya menutupinya
  • Karena seluruh pipeline rendering digunakan bahkan untuk adegan yang tidak terlihat, pengaturan grafis langsung memengaruhi performa menu utama
  • Saat rilis, sebagian besar pengaturan secara default mendekati maksimum, termasuk efek berat yang direkomendasikan pengembang untuk dinonaktifkan
  • Namun, penyebab penurunan hingga sekitar 7FPS saat pertama kali dijalankan belum sepenuhnya teridentifikasi
    • Penurunan performa pada level yang sama tidak berhasil direproduksi setelahnya
    • Saat pertama kali dijalankan, ada pekerjaan pemrosesan cache virtual texture, tetapi belum dipastikan apakah menggunakan GPU
  • Keseluruhan adegan menu utama mencakup sekitar 400 draw calls, 563.000 input vertices, dan 745.000 rasterized triangles

Interpretasi yang dilengkapi di FAQ

  • Sulit menyimpulkan apakah seharusnya dibuat dengan Unreal Engine 5
    • UE5 memiliki Nanite, Lumen, dan Virtual Shadow Maps, yang dapat menangani sebagian masalah yang dialami C:S2
    • Di sisi lain, UE5 kekurangan fitur tingkat produksi untuk logika game dan simulasi skala besar yang setara dengan Unity ECS, sementara struktur yang berpusat pada C++ dapat merugikan fleksibilitas dan aksesibilitas modding
  • Bukan berarti game sama sekali tidak memiliki LOD
    • Banyak bangunan tampaknya memiliki LOD yang memadai
    • Pada elemen seperti pipa, properti halaman, dan dekorasi, sering ada kasus LOD tidak tersedia atau tidak dipilih
  • InstaLOD tampaknya digunakan dalam asset pipeline game, terutama saat mengimpor asset baru di mod tool, dan tampaknya tidak digunakan untuk rendering runtime
  • UI berbasis JavaScript bukan bottleneck utama berdasarkan data analisis
    • Gameface bukan berbasis engine browser penuh seperti Electron, melainkan framework kustom yang disesuaikan untuk UI game
    • Ada penjelasan bahwa seharusnya lebih unggul dalam penggunaan memori dan performa dibanding yang berbasis Chromium/Blink atau WebKit
  • Renderdoc memiliki keterbatasan sebagai alat benchmark presisi, tetapi memberikan bukti yang cukup untuk memahami “apa yang dilakukan game sehingga menjadi lambat”

Kesimpulan: bottleneck CPU berkurang, tetapi pipeline GPU nyaris belum selesai

  • Alasan langsung Cities: Skylines 2 terlalu berat bagi GPU adalah karena game mengirim terlalu banyak geometri yang tidak perlu ke kartu grafis
  • Pemborosan geometri ini berasal dari kurangnya LOD pada banyak mesh serta implementasi culling yang sederhana dan belum cukup disetel
  • Alasan implementasi culling sendiri dan lapisan penghubung rendering tampaknya karena integrasi Unity DOTS dan HDRP masih dalam proses, dan keterbatasannya besar untuk penggunaan di game nyata
  • Virtual texturing Unity juga masih eksperimental, sehingga Colossal Order mengimplementasikan solusi sendiri, dan sistem ini pun masih memiliki bagian yang belum matang
  • Alur yang dapat diduga adalah Colossal Order bertaruh pada teknologi baru Unity, DOTS, dan berhasil dalam aspek pengurangan bottleneck CPU serta skala simulasi, tetapi dari sisi grafis harus mengimplementasikan sendiri sistem seperti culling, animasi, dan texture streaming
  • Ada penilaian bahwa klaim pengembang bahwa game sejak awal menargetkan 30FPS sulit dipercaya, dan mengingat ini game PC murni serta kualitas grafisnya, hal itu sulit dibenarkan sebagai target performa
  • Area yang kemungkinan besar dapat diperbaiki adalah penambahan LOD, perbaikan culling, optimasi pemilihan shadow caster, dan perapian asset per properti; karena banyak asset mungkin harus ditangani satu per satu, ini akan membutuhkan waktu

Bacaan terkait

1 komentar

 
GN⁺ 2023-11-06
Opini Hacker News

  • Ini tulisan yang menarik, jadi saya berharap diskusinya berfokus pada apa tepatnya yang menarik
    Thread seperti ini mudah sekali bergeser menjadi generalisasi tentang $THING itu sendiri—dalam hal ini game secara keseluruhan—atau $RELATED—dalam hal ini framework—atau hal-hal serupa secara umum
    Pada prinsipnya itu bukan hal buruk, tetapi semakin jauh diskusi melangkah ke generalisasi, semakin dangkal dan kurang menarik jadinya. Karena itu di panduan situs juga ada aturan “hindari diskusi sampingan yang umum” - https://news.ycombinator.com/newsguidelines.html

  • Bagian yang mengatakan, “alasan Colossal Order tidak memakai culling bawaan Unity dan punya implementasi sendiri adalah karena integrasi Unity untuk DOTS dan HDRP masih sangat dalam proses, dan bisa dibilang tidak cocok untuk sebagian besar game nyata, sehingga mereka harus mengimplementasikan sendiri cukup banyak bagian grafis,” sayangnya sangat sesuai dengan pengalaman saya memakai tool Unity
    DOTS sudah dirilis, tetapi rasanya implementasinya dibiarkan terbengkalai seperti tool-tool lain yang diakuisisi Unity. Operasional perusahaannya benar-benar bermasalah, dan melihat insiden kebijakan harga yang meledak secara publik beberapa minggu lalu, mereka tampaknya lebih fokus mencari cara mengeruk lebih banyak uang dari pengguna daripada memperbaiki engine
    Implementasi ECS Bevy benar-benar bagus, dan saya berharap bersama Godex mereka berhasil di area ini

    • Saya tidak mengerti bagaimana Unity tampaknya membakar hingga 1 miliar dolar AS pendapatan setiap tahun, tetapi engine-nya masih terasa seperti produk setengah matang yang belum selesai. Ke mana semua uang itu pergi?
    • Godex pada akhirnya cuma seperti memakaikan lipstik pada babi. Ia mungkin bisa sedikit meningkatkan performa, tetapi ECS bukan optimasi ajaib yang bisa ditempelkan begitu saja seperti plugin
      Koherensi cache di lapisan gameplay tidak bisa memperbaiki bottleneck di level engine
    • Jujur saja, ada banyak cara untuk merilis game berperforma baik, dan ECS tidak wajib maupun selalu merupakan pendekatan modern. Itu hanyalah salah satu dari banyak pola arsitektur untuk menyusun game, dengan banyak kelebihan dan kekurangannya
      Misalnya, Godot tidak berpusat pada ECS, melainkan pada konsep “server”, yaitu subsistem game otonom yang menangani sebagian besar domain khusus seperti rendering dan physics secara independen, dan terhubung longgar dengan logika game umum
      Arsitektur ECS berasal dari era PS2/PS3 ketika CPU masih buruk. Karena cache kecil, biaya branch misprediction besar, memori lambat, ruang memori terfragmentasi, dan tidak adanya storage akses acak, developer harus membuat game mengikuti pola akses memori yang dapat diprediksi, dan hasilnya struktur yang memproses data game dengan streaming dalam potongan-potongan kecil menjadi umum
      Pendekatan seperti ini umumnya masih praktik yang baik sekarang, tetapi dengan CPU supercepat, speculative execution yang hebat, branch predictor yang baik, dan cache puluhan MB, itu tidak lagi menjadi syarat mutlak. Terutama jika melihat bahwa game modern tidak memperbesar skala kejadian di layar secara drastis dibandingkan 10–20 tahun lalu. Dalam game aksi pun masih jarang pemain melawan lebih dari belasan musuh sekaligus
      Untuk game yang menampilkan ribuan elemen sekaligus di layar, biasanya diperlukan logika dan pemrosesan khusus yang terpisah
    • Bukankah DOTS dibuat secara internal di Unity?

  • Tips untuk orang yang ingin mencoba game ini: ubah resolution scaling dari dinamis menjadi tetap
    Di 3080, menu utama yang tadinya “tidak bisa dimainkan di 10fps” berubah menjadi “berjalan lancar tanpa masalah” di dalam game dengan opsi menengah-tinggi

    • Bisa juga dimatikan sama sekali. Di 3080 saya, sepertinya itu membuat banyak artefak rendering
    • Itu bukan solusinya. Matikan motion blur dan depth of field. Depth of field khususnya membunuh performa menu

  • Sebagai referensi, setahu saya satu frame Crysis, berdasarkan adegan benchmark, kira-kira sekitar 300 ribu vertex atau triangle. Jadi tergantung ingatan saya salah ke arah mana, dan seberapa buruk rasio vertex/triangle tiap model, itu setara sekitar 3–10 tumpukan kayu gelondongan

    • Saya penulisnya: saya tidak menemukan cara mudah menghitung jumlah total vertex per frame di RenderDoc, jadi saya tidak menghitungnya sendiri. Namun seseorang di Reddit mengukur jumlah total vertex dengan ReShade, dan katanya pada adegan jarak dekat di kota besar, jumlahnya bisa mencapai ratusan juta hingga 1 miliar vertex
      Sunting: saya mengecek jumlah vertex dan polygon dengan RenderDoc. Adegan contoh dalam tulisan memproses 121 juta vertex dan lebih dari 40 juta triangle
    • Sepertinya benar. Saya masih ingat melihat “1M Triangles” di HUD performa dan berpikir, satu juta triangle itu gila. Jika mempertimbangkan edge split, billboard, dan sebagainya, kemungkinan hampir tidak ada vertex yang dipakai bersama

  • Saya sangat menyukai gaya penulisannya:
    Kalimat seperti “Pass ini sangat berat, karena memakan sekitar 8,2 milidetik, alias kira-kira waktu yang tidak masuk akal lamanya…”

    • Saya berharap lebih banyak orang menyisipkan humor kecil seperti ini bahkan dalam tulisan yang agak serius

  • “Mesh tumpukan kayu gelondongan ini pun hanya dipakai pada shadow rendering pass, tetapi punya lebih dari 100 ribu vertex”… tapi kenapa?

    • Karena dalam pengembangan game ada kira-kira sejuta hal yang harus diperhatikan. Bisa jadi seseorang atau suatu software membuat kesalahan pada pengaturan LOD. Atau kode LOD dinamis gagal melakukan culling mesh LOD0 dengan benar, atau kode itu tidak sempat diselesaikan tepat waktu, atau bisa juga karena alasan lain sama sekali
      Dalam game AAA, adanya beberapa elemen yang tidak sempurna dan belum dioptimalkan itu sepenuhnya normal. Anggaran selalu terbatas dan waktu pengembangan pendek. Selain itu, ini industri yang bergantung pada hit tanpa jaminan hasil. Ada beberapa cara meningkatkan peluang sukses game, tetapi biasanya lebih dekat ke sisi manajemen daripada pengembangan, dan proyeksi pendapatan preorder sering meleset. Jadi untuk mengurangi risiko, harus ada kompromi, biaya dipangkas di tempat yang memungkinkan, dan prioritas pengembangan paling mahal diturunkan. Kompromi-kompromi seperti ini jauh lebih besar daripada satu mesh yang tidak dioptimalkan. Satu mesh bukan apa-apa
      Memang menarik bahwa mesh ini LOD0 dan mesh gigi juga LOD0. Namun itu saja tidak membuat performa game runtuh, dan kemungkinan mereka memperbaiki ini sebagai pengganti perbaikan performa yang sebenarnya juga tampak kecil. Menurut saya thread ini agak berlebihan terobsesi pada mesh-mesh seperti ini
      Ada banyak komentar yang emosional, jadi saya tidak ingin menambahnya; saya hanya ingin memberi lebih banyak konteks
    • Padahal itu bisa saja ditangani dengan sekitar 100 vertex dan normal map yang cerdas; ini benar-benar di luar nalar
    • Studio yang membuat game ini punya sekitar 30 developer

  • Apakah ringkasannya tepat bahwa game ini memakai model yang sangat mendetail, tetapi tidak punya cara untuk mengabstraksikan secara cerdas atau melakukan culling terhadap hal-hal yang tidak akan tampil sebagai piksel nyata?
    Kalau begitu, apakah ini bisa diperbaiki dengan mudah, atau terlalu mendasar pada struktur intinya sehingga untuk menyelesaikannya harus mendesain ulang dari awal?

    • Tingkat kesulitan perbaikannya hanya bisa ditebak. Saya bukan ahli, tetapi menurut saya culling dan LOD adalah pilar besar dalam engine. Tidak bisa memakai implementasi yang sudah ada itu benar-benar situasi yang buruk
      “Trik”-nya sendiri mungkin sudah dikenal luas, tetapi saya tidak berpikir implementasinya mudah

  • DOTS berasal dari ide Mike Action. Lihat presentasinya di CppCon 2014, “Data-Oriented Design and C++” [1]. Namun menurut Twitter, Mike sudah meninggalkan Unity
    [1] https://www.youtube.com/watch?v=rX0ItVEVjHc

    • Tulisan aslinya memang menyebut sisi kasar DOTS, tetapi saya tidak melihat isi tulisan yang benar-benar bisa dianggap menunjukkan bahwa DOTS adalah penyebabnya. Kalau DOTS bermasalah, itu akan menimbulkan overhead CPU, tetapi di sini tampaknya lebih dekat ke penggunaan geometri yang luar biasa terlalu detail dalam jumlah besar dan tidak mengimplementasikan sistem LOD
      Kalau ada Nanite dari UE5, mungkin masih bisa bertahan entah bagaimana, tetapi geometri yang sedemikian berlebihan akan meruntuhkan semua hal lain
    • Apakah ini Mike Action yang sama yang, dengan dataset yang sangat meragukan kecuali untuk game olahraga dan semacamnya, mengatakan bahwa game 30fps terjual lebih baik daripada game 60fps?

  • Di Proton Experimental, saya menghabiskan 40 menit mencoba mendapatkan lebih dari beberapa fps bahkan pada peta kosong di 1080p, tetapi akhirnya menyerah dan refund. Kalau performa buruknya sudah diperbaiki, saya berniat mencobanya lagi
    Saya benar-benar banyak menikmati seri pertama, jadi sangat disayangkan saya tidak bisa mencoba karya yang ini

    • Solusinya muat dalam satu tweet -> https://twitter.com/ColossalOrder/status/1716883884724322795
      “Jika Anda mengalami masalah performa, kami menyarankan menurunkan resolusi layar ke 1080p, mematikan depth of field dan volumetrics, serta menurunkan global illumination sementara kami menangani masalah yang memengaruhi performa”
      Hanya itu yang saya lakukan untuk mendapatkan performa yang mulus di AMD Radeon RX 5700 XT
    • Di GeForce Now, game ini cukup layak dimainkan. Memang masih sedikit tersendat, tetapi saya bisa bermain selama beberapa jam tanpa masalah besar. Kadang ada stutter yang mengganggu, tetapi masih bisa ditoleransi