How A Plague Tale: Innocence Frame Render

Kata Pengantar

Seperti dalam studi saya yang lain, mari kita mulai dengan pengantar. Hari ini kita melihat game terbaru dari pengembang Perancis Asobo Studio. Pertama kali saya melihat video game ini tahun lalu, ketika seorang rekan berbagi trailer gameplay 16 menit dengan saya. Mekanik "tikus melawan cahaya" menarik perhatian saya, tetapi saya tidak benar-benar ingin memainkan game ini. Namun, setelah dirilis, banyak yang mulai mengatakan bahwa sepertinya dibuat di mesin Unreal, tetapi ini tidak benar. Saya ingin tahu bagaimana cara kerja rendering dan seberapa banyak pengembang terinspirasi oleh Unreal secara umum. Saya juga tertarik pada proses rendering kawanan tikus, karena dalam permainan itu terlihat sangat meyakinkan dan, terlebih lagi, itu adalah salah satu elemen kunci dari gameplay.

Ketika saya mulai mencoba menangkap permainan, saya berpikir bahwa saya harus menyerah, karena tidak ada yang berhasil. Meskipun gim ini menggunakan DX11, yang sekarang didukung oleh hampir semua alat analisis, saya tidak bisa membuatnya bekerja. Ketika saya mencoba menggunakan RenderDoc, game mogok saat startup, dan hal yang sama terjadi dengan PIX. Saya masih tidak tahu mengapa ini terjadi, tetapi untungnya, saya dapat menyelesaikan beberapa tangkapan menggunakan NSight Graphics. Seperti biasa, saya menaikkan semua parameter secara maksimal dan mulai mencari bingkai yang cocok untuk analisis.

Frame Break

Setelah membuat beberapa tangkapan, saya memutuskan untuk menggunakan salah satu dari permulaan permainan untuk analisis bingkai. Tidak ada banyak perbedaan antara grip, dan selain itu, saya bisa menghindari spoiler.

Seperti biasa, mari kita mulai dengan frame terakhir:


Hal pertama yang saya perhatikan adalah keseimbangan yang benar-benar berbeda dalam game rendering event ini dibandingkan dengan apa yang saya lihat di game lain sebelumnya. Ada banyak panggilan imbang di sini, yang normal, tetapi yang mengejutkan hanya beberapa dari mereka yang digunakan untuk pasca-pemrosesan. Di gim lain, setelah merender warna untuk mendapatkan hasil akhir, frame melewati lebih banyak tahapan, tetapi dalam A Plague Tale: Innocence, tumpukan pasca pemrosesan sangat kecil dan dioptimalkan hanya untuk beberapa acara rendering / kalkulasi.

Gim mulai membangun bingkai dengan merender GBuffer dengan enam target render. Menariknya, semua target render ini memiliki format integer 32-bit unsigned (dengan pengecualian satu) alih-alih warna RGBA8 atau format lain yang khusus untuk data tersebut. Ini sulit karena saya harus mendekodekan setiap saluran secara manual menggunakan fungsi Custom Shader dari NSight. Saya menghabiskan banyak waktu mencari tahu nilai mana yang dikodekan dalam target 32-bit, tetapi mungkin saja saya melewatkan sesuatu.


GBuffer 0

Target pertama berisi beberapa nilai bayangan dalam 24 bit, dan beberapa nilai lain untuk rambut dalam 8 bit.


GBuffer 1

Target kedua terlihat seperti target RGBA8 tradisional dengan nilai kontrol material yang berbeda di setiap saluran. Sejauh yang saya mengerti, saluran merah adalah logam (tidak sepenuhnya jelas mengapa beberapa daun ditandai dengan itu), saluran hijau terlihat seperti nilai kasar, dan saluran biru adalah topeng dari karakter utama. Tidak ada tangkapan yang saya buat menggunakan saluran alpha.


GBuffer 2

Target ketiga juga tampak seperti RGBA8 dengan Albedo di saluran RGB, dan saluran alpha di setiap tangkapan yang saya buat benar-benar putih, jadi saya tidak mengerti apa yang harus dilakukan data ini.


GBuffer3

Target keempat penasaran karena pada semua tangkapan saya hampir hitam. Nilai-nilainya terlihat seperti topeng bagian dari vegetasi dan semua rambut / bulu. Mungkin ini ada hubungannya dengan transparansi.


GBuffer 4

Target kelima mungkin semacam penyandian normal, karena saya belum melihatnya di tempat lain, dan shader tampaknya mengambil sampel peta normal dan kemudian menampilkan ke target itu. Dengan pemikiran ini, saya belum menemukan cara memvisualisasikannya dengan benar.


Kedalaman dari GBuffer 5


Topeng dari GBuffer 5

Target terakhir adalah pengecualian karena menggunakan format floating point 32-bit. Alasan untuk ini adalah karena mengandung kedalaman linear gambar, dan bit tanda mengkodekan beberapa topeng lain, lagi-lagi menutupi rambut dan bagian dari vegetasi.

Setelah pembuatan GBuffer selesai, resolusi peta kedalaman dikurangi dalam shader komputasi, dan kemudian peta bayangan diberikan (peta bayangan mengalir langsung dari matahari dan peta kedalaman kubik dari sumber cahaya titik).


Sinar senja

Setelah menyelesaikan peta bayangan, Anda dapat menghitung pencahayaan, tetapi sebelum itu, sinar dewa dirender menjadi target yang terpisah.


SSAO

Pada tahap perhitungan pencahayaan, shader komputasi dilakukan untuk menghitung SSAO.


Geometri Buram Diterangi

Pencahayaan ditambahkan dari peta kubik dan sumber cahaya lokal. Semua sumber cahaya yang berbeda ini, dikombinasikan dengan target yang diberikan di atas, membentuk gambar HDR yang menyala sebagai hasilnya.


Elemen Penyajian Proaktif

Elemen-elemen yang diberikan dalam rendering proaktif ditambahkan di atas geometri buram yang diterangi, tetapi mereka tidak terlalu terlihat dalam adegan ini.

Setelah mengumpulkan semua warna, kami hampir selesai, hanya ada beberapa operasi pasca-pemrosesan dan UI.


Resolusi warna berkurang dalam penghitung komputasi dan kemudian ditingkatkan untuk menciptakan efek mekar yang sangat indah dan lembut.


Setelah mengkomposisikan semua hasil sebelumnya, menambahkan kotoran kamera, penilaian warna, dan akhirnya koreksi gambar warna, kami mendapatkan warna pemandangan. Hamparan UI memberi kita gambar dari awal artikel.

Layak disebutkan beberapa hal menarik tentang rendering:

• Instancing (duplikasi geometri) hanya digunakan untuk jerat individual (tampaknya hanya untuk vegetasi). Semua objek lain disajikan dalam panggilan undian terpisah.
• Sepertinya objek diurutkan kira-kira dari depan ke belakang, dengan beberapa pengecualian.
• Tampaknya pengembang tidak melakukan upaya apa pun untuk mengelompokkan panggilan draw dalam hal parameter material.

Tikus

Seperti yang saya katakan di awal artikel, salah satu alasan saya ingin menjelajahi permainan ini adalah karena cara membuat paket tikus. Keputusan itu mengecewakan saya dalam beberapa hal: tampaknya itu dibuat dengan kekerasan. Di sini saya menggunakan tangkapan layar dari adegan lain dalam permainan, tapi saya harap tidak ada spoiler di dalamnya.


Seperti halnya dengan objek lain, tikus tampaknya tidak memiliki duplikasi geometri, kecuali kita mencapai jarak di mana kita beralih ke tingkat terakhir detail jala (LOD). Mari kita lihat cara kerjanya.


LOD0


LOD1


LOD2


LOD3

Tikus memiliki 4 level LOD. Menariknya, pada tingkat ketiga, ekor tertekuk ke tubuh, sedangkan ekor keempat tidak. Ini mungkin berarti bahwa animasi hanya aktif untuk dua level pertama. Sayangnya, NSight Graphics tampaknya tidak memiliki alat yang cukup untuk menguji ini.


Tidak ada duplikasi (instancing) tikus.

Dengan duplikasi.


Dalam adegan yang ditunjukkan di atas, jumlah tikus berikut ini diberikan:

• LOD0 - 200
• LOD1 - 200
• LOD2 - 1258
• LOD3 - 3500 (dengan duplikasi geometri)

Ini membuat kita mengerti bahwa ada batasan ketat pada jumlah tikus yang dapat diberikan pada dua LOD pertama.

Dalam tangkapan yang saya buat, saya tidak dapat mengidentifikasi logika yang menghubungkan tikus dengan LOD individu. Terkadang tikus yang lebih dekat ke kamera tidak terlalu detail, dan terkadang tikus yang hampir tidak terlihat memiliki detail tinggi.

Kesimpulannya

Plague Tale: Innocence sangat menarik dalam hal rendering. Hasil nya pasti membuat saya terkesan, mereka melayani gameplay dengan sangat baik. Seperti halnya mesin berpemilik, alangkah baiknya mendengar analisis yang lebih terperinci dari bibir para pengembang sendiri, terutama karena saya tidak dapat mengkonfirmasi beberapa teori saya. Saya berharap artikel saya suatu hari nanti sampai ke seseorang dari Asobo Studio dan mereka melihat bahwa orang-orang memiliki minat dalam hal ini.