Kapan saya harus menandai GameObjects sebagai Statis?


9

Berikut adalah dokumentasi Persatuan yang sesuai .

Menurut penjelasan dari halaman dokumentasi Unity tentang Static GameObjects, kadang-kadang menandai GameObjects sebagai statis dapat mempengaruhi kinerja dengan cara yang buruk (misalnya Static Batching menyebabkan lebih banyak penggunaan memori) .

Jadi kapan saya harus benar-benar ingin menggunakan fungsi-fungsi ini?

Terima kasih sebelumnya.

Catatan Kaki:
Saat ini saya sedang mengembangkan game top-down 2D yang memiliki banyak Sprite dan LineRenderers, tetapi tidak ada objek 3D (bahkan bukan quad). Semua GameObjects sedang dipakai secara prosedural dari prefab premade. LineRenderers diperbarui dari skrip setiap frame. Dan hampir semua Sprite bergerak konstan. Mayoritas Sprite berbagi materi yang sama. Semua LineRenderers juga berbagi materi yang sama.


1
BUKAN UNTUK POHON DI HUTAN. Kami digigit oleh yang buruk. LAMA kali membangun, MASSIVE data di level Anda. Catatan: dokumen tentang ini secara khusus menyatakan bahwa Anda tidak boleh menggunakannya untuk hutan. :)
Almo

@Almo saya dengan anak laki-laki, dapat memahami rasa sakit ini
Hamza Hasan

Jawaban:


6

Tidak ada aturan keras tentang kapan Anda harus atau tidak membuat GameObjects statis.

Paling tidak, hanya lakukan untuk objek yang tidak akan pernah bergerak seumur hidup mereka. Tetapi Anda harus tahu apa fungsinya untuk mengevaluasi apakah Anda seharusnya atau tidak.

Ini membekukan jala ke dalam data adegan, sehingga Anda tidak memiliki overhead GameObject untuk item tersebut. Ini berarti peningkatan kinerja dengan biaya mengubah data adegan pada waktu pembuatan dan biaya memori tambahan untuk aplikasi akhir yang dibangun.

Ini bagus dalam banyak kasus, meskipun dapat menimbulkan masalah, misalnya dengan hutan. Juga, itu berarti bahwa alih-alih menyimpan verts untuk pohon sekali dan GPU menggambar salinan, ia harus menduplikasi verts itu di semua tempat. Itu membutuhkan waktu selama pembuatan, dan ruang di aplikasi. Aplikasi kami beralih dari 3-4 GB menjadi 300-400 MB saat kami membuat pohon tidak statis. Waktu build berubah dari 3-4 jam menjadi 1 jam.

Setelah mengatakan semua itu! Game Anda adalah 2d, dan mungkin akan mendapat manfaat dari menyetel GameObjects dalam adegan menjadi statis, asalkan Anda tidak memiliki banyak dari mereka.


Bukankah membuat prefab statis membuat instance statis juga?
S. Tarık Çetin

Tidak jika Anda instantiate saat runtime ... Bagaimana bisa "statis"? Mungkin aku salah ... Akan memeriksanya.
Almo

2
Saya baru saja mengkonfirmasi bahwa, jika cetakan ditandai sebagai statis, contoh instantiated juga statis.
S. Tarık Çetin

1

Jika saya katakan secara umum maka Segala sesuatu yang tidak akan pernah bergerak (bahkan pixel) dalam seluruh kehidupan aplikasi harus ditandai sebagai statis. Biasanya berguna untuk memanggang lampu, memanggang jalur navmesh, dan sebagainya ..

Nah, jika Anda berkembang tanpa benda 3D maka santai saja dan dinginkan. Tidak perlu khawatir tentang rendering realtime, bayangan atau masalah lainnya. Bahkan menghapus satu-satunya cahaya datang dengan pemandangan baru;)

Nah, siapa pun dapat memperbaiki saya jika saya salah di tempat mana pun.


3
Ini benar-benar salah untuk hal-hal seperti hutan. Ini mengurangi drawcall ... tapi membuat semua pohon menjadi jala. Berarti bahwa alih-alih menyimpan verts untuk pohon sekali dan GPU menggambar salinan, ia harus menduplikasi verts itu di semua tempat. Itu membutuhkan waktu selama pembuatan, dan ruang di aplikasi. Aplikasi kami beralih dari 3-4 GB menjadi 300-400 MB saat kami membuat pohon tidak statis.
Almo

@Almo perbedaan huggggeeeeee
Hamza Hasan

Saya pikir Anda harus mengklarifikasi di awal jawaban Anda bahwa Anda merekomendasikan ini hanya karena ini adalah permainan 2d.
Almo

@Almo Terima kasih kepada Anda, sekarang saya pikir batch statis adalah hal yang berbahaya untuk disentuh, seperti oven yang Anda tidak bisa yakin panas atau tidak. :)
S. Tarık Çetin

@Almo merasa bebas untuk mengedit bro ini, jika merasa membutuhkannya. Silakan
Hamza Hasan
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.