Bagaimana mesin permainan komersial mengatur buffer indeks / simpul?


8

Pendahuluan: Pertanyaan ini akan datang dari sudut pandang Direct3D, karena itulah yang saya kenal.

Jelas kami mengeluarkan sedikit overhead setiap kali kami mengubah vertex atau buffer indeks di Direct3D (yaitu dengan IASetIndexBuffer). Tapi saya kira jika kita mengalokasikan satu indeks raksasa / buffer vertex kita akan akhirnya harus mengelola memori secara manual, dan semacam berakhir dengan masalah fragmentasi (atau berhenti sementara kita menukar semua data di sekitar).

Jadi bagaimana mesin komersial memuat / membongkar data? Saya agak condong ke arah pendekatan berbasis 'paket', jadi 'paket' model memiliki buffer vertex / indeks sendiri yang dapat kita muat / keluarkan karena paket tidak lagi diperlukan; dan kemudian mencoba untuk menggambar semua instance dari paket yang sama.

Tetapi saya akan tertarik untuk mendengar apa cara penanganan yang diterima / standar ini?


1
Ini adalah pertanyaan yang bagus dan juga berlaku untuk OpenGL.
glampert

Jawaban:


13

Ada sejumlah teknik berbeda untuk mengatur data, dan banyak gim menggunakan campurannya.

Untuk geometri statis, yang terbaik adalah memiliki lebih sedikit IB dan VB individual.

Permainan tradisional berbasis 'level' yang berarti aset untuk bagian permainan dimuat dan kemudian permainan dimulai. Untuk meminimalkan waktu muat, informasi idealnya disusun untuk mendukung ini (mis. Memuat semuanya untuk level secepat mungkin tanpa mencari-cari di media / disk), mungkin mereplikasi informasi antar level. Dalam pendekatan ini, satu skema adalah memiliki VB dan IB besar untuk model atau serangkaian model, dan kemudian menyerahkan himpunan bagian dari itu untuk menggambar.

Untuk generasi Xbox 360 / PS 3, jumlah RAM relatif kecil dibandingkan ukuran gim, sehingga mesin menjadi berorientasi 'streaming' yang berarti mereka memuat konten secara dinamis saat pemain bergerak melaluinya. Ini juga disebut pendekatan 'dunia terbuka'. Dalam pendekatan ini, tantangannya adalah 'memotong' geometri menjadi bit yang dapat Anda muat berdasarkan petunjuk spasial. Tantangan lain terutama untuk platform 32-bit adalah memastikan bahwa memori tidak menjadi terfragmentasi (atau bahkan fragmentasi ruang alamat virtual) selama periode waktu yang lama - permainan berbasis level sering mengatur ulang memori antar level, sesuatu yang tidak dapat dilakukan oleh mesin streaming dengan mudah. Oleh karena itu, pengemasan menjadi ukuran tetap atau set ukuran tetap untuk IB / VB yang dialokasikan dan digunakan kembali sebagai kumpulan sangat membantu.

Untuk generasi Xbox One / PS 4, ada banyak RAM untuk bekerja dengan relatif terhadap konsol sebelumnya, dan banyak core ekstra, begitu banyak game secara agresif mengompresi aset mereka dan kemudian menggunakan core CPU "ekstra" untuk mendekompresi mereka di Latar Belakang. Dengan ruang alamat virtual 64-bit, ada sedikit kekhawatiran tentang fragmentasi ruang alamat virtual. Pendekatan ini menjaga waktu pemuatan rendah, mengemas aset dengan baik untuk unduhan digital, dan mendukung rendering 'dunia terbuka'. Di sini digunakan pendekatan kumpulan untuk mengelola IB / VB.

Ada juga pengajuan geometri dinamis yang sering digunakan untuk medan, model deformable / destructible, dll. Ini bukan yang efisien dalam hal bandwidth bus GPU, sehingga game sering memiliki campuran geometri statis dan dinamis. Dalam hal ini, pola pembaruan DISCARD Peta Direct3D biasanya berarti Anda hanya menggunakan IB / VB tunggal (atau untuk skenario rendering multithreaded, dual IB / VB yang Anda tukarkan dengan mengisi / membuat setiap frame).


Terima kasih atas jawaban anda. Bolehkah saya mengajukan beberapa pertanyaan klarifikasi? Apa pola DISCARD Peta Direct3D?
Xenoprimate

1
Pola ini dijelaskan di sini untuk Direct3D 9 sebagai Lock DISCARD, tetapi pola itu digunakan dengan Direct3D 10.x / 11.x serta Map DISCARD untuk sumber daya dinamis. Anda dapat melihat contoh bagaimana ini diterapkan untuk Direct3D 11 dengan melihat kelas PrimitiveBatch dari DirectX Tool Kit .
Chuck Walbourn
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.