Konsep
Pada dasarnya, grafik adegan tidak lebih dari grafik asiklik dua arah yang berfungsi untuk mewakili serangkaian hubungan spasial yang terstruktur secara hierarkis.
Mesin-mesin di alam liar cenderung memasukkan barang-barang lain ke dalam grafik adegan, sebagaimana dicatat. Apakah Anda melihatnya sebagai daging atau sapi mungkin tergantung pada pengalaman Anda dengan mesin dan perpustakaan di luar sana.
Menjaga Ringan
Saya menyukai gaya Unity3D memiliki simpul grafik adegan Anda (yang pada dasarnya adalah topologi daripada struktur spasial / topografi) secara inheren mencakup parameter spasial dan fungsionalitas. Di mesin saya, simpul saya bahkan lebih ringan dari Unity3D, di mana mereka mewarisi banyak anggota sampah yang tidak perlu dari superclasses / antarmuka yang diimplementasikan: Inilah yang saya miliki - kira-kira seringan yang Anda bisa dapatkan:
- anggota pointer orangtua / anak.
- pra-transform anggota parameter spasial: posisi xyz, pitch, yaw and roll.
- matriks transformasi; matriks dalam rantai hierarkis dapat dengan cepat & mudah berkembang biak dengan berjalan secara rekursif ke atas / ke bawah pohon, memberi Anda transformasi spasial hierarkis yang merupakan fitur utama grafik adegan;
- sebuah
updateLocal()metode yang update hanya ini simpul yang mengubah matriks
- sebuah
updateAll()metode yang memperbarui ini dan semua matriks transformasi node turunan
... Saya juga memasukkan persamaan persamaan gerak dan dengan demikian anggota kecepatan / percepatan (linier & sudut) di kelas simpul saya. Anda dapat melepaskan itu, dan menanganinya di pengontrol utama Anda jika Anda mau. Tapi itu dia - memang sangat ringan. Ingat, Anda dapat memiliki ini di ribuan entitas. Jadi seperti yang Anda sarankan, tetap ringan.
Membangun Hirarki
Apa yang Anda katakan tentang grafik adegan referensi grafik adegan lain ... Saya sedang menunggu lucunya? Tentu saja mereka lakukan. Itulah kegunaan utama mereka. Anda dapat menambahkan simpul apa pun ke simpul lain mana pun, dan transformasi akan terjadi secara otomatis di dalam ruang lokal transformasi baru. Yang Anda lakukan hanyalah mengubah pointer, tidak seperti Anda menyalin data! Dengan mengubah pointer, Anda kemudian memiliki grafik adegan yang lebih dalam. Jika menggunakan Proxy membuat segalanya lebih efisien maka dengan segala cara, tapi saya belum pernah melihat kebutuhannya.
Hindari Logika terkait Render
Lupakan tentang rendering saat Anda menulis kelas node node grafik Anda, atau Anda akan mengacaukan hal-hal untuk diri Anda sendiri. Yang penting adalah bahwa Anda memiliki model data - apakah itu grafik adegan atau tidak tidak masalah - dan bahwa beberapa penyaji akan memeriksa bahwa model data dan merender objek di dunia sesuai, apakah itu dalam 1, 2 , 3 atau 7 dimensi. Maksud saya adalah: Jangan mencemari grafik adegan Anda dengan logika render. Grafik adegan adalah tentang topologi dan topografi - yaitu konektivitas dan karakteristik spasial. Ini adalah keadaan sebenarnya dari simulasi dan ada bahkan tanpa adanya rendering (yang dapat mengambil bentuk apa pun di bawah matahari dari tampilan orang pertama ke grafik statistik ke deskripsi tekstual). Node tidak menunjuk ke objek yang berhubungan dengan rendering - namun kebalikannya mungkin benar. Pertimbangkan juga ini: Tidak setiap simpul grafik adegan di seluruh pohon Anda akan dapat diulang. Banyak yang hanya akan menjadi wadah. Jadi mengapa bahkan mengalokasikan memori untuk pointer-to-render-object? Bahkan anggota pointer yang tidak pernah digunakan, masih mengambil memori. Jadi balikkan arah penunjuk: Contoh terkait-render merujuk model data (yang mungkin, atau termasuk, simpul grafik adegan Anda), BUKAN sebaliknya. Dan jika Anda ingin cara mudah untuk menjalankan melalui daftar controller Anda belum mendapatkan akses ke tampilan terkait, kemudian gunakan kamus / hashtable, yang mendekati O (1) membaca waktu akses. Dengan begitu tidak ada kontaminasi, dan logika simulasi Anda tidak peduli apa yang diberikan penyaji, yang membuat hari Anda dan malam pengkodean Jadi mengapa bahkan mengalokasikan memori untuk pointer-to-render-object? Bahkan anggota pointer yang tidak pernah digunakan, masih mengambil memori. Jadi balikkan arah penunjuk: Contoh terkait-render merujuk model data (yang mungkin, atau termasuk, simpul grafik adegan Anda), BUKAN sebaliknya. Dan jika Anda ingin cara mudah untuk menjalankan melalui daftar controller Anda belum mendapatkan akses ke tampilan terkait, kemudian gunakan kamus / hashtable, yang mendekati O (1) membaca waktu akses. Dengan begitu tidak ada kontaminasi, dan logika simulasi Anda tidak peduli apa yang diberikan penyaji, yang membuat hari Anda dan malam pengkodean Jadi mengapa bahkan mengalokasikan memori untuk pointer-to-render-object? Bahkan anggota pointer yang tidak pernah digunakan, masih mengambil memori. Jadi balikkan arah penunjuk: Contoh terkait-render merujuk model data (yang mungkin, atau termasuk, simpul grafik adegan Anda), BUKAN sebaliknya. Dan jika Anda ingin cara mudah untuk menjalankan melalui daftar controller Anda belum mendapatkan akses ke tampilan terkait, kemudian gunakan kamus / hashtable, yang mendekati O (1) membaca waktu akses. Dengan begitu tidak ada kontaminasi, dan logika simulasi Anda tidak peduli apa yang diberikan penyaji, yang membuat hari Anda dan malam pengkodean Dan jika Anda ingin cara mudah untuk menjalankan melalui daftar controller Anda belum mendapatkan akses ke tampilan terkait, kemudian gunakan kamus / hashtable, yang mendekati O (1) membaca waktu akses. Dengan begitu tidak ada kontaminasi, dan logika simulasi Anda tidak peduli apa yang diberikan penyaji, yang membuat hari Anda dan malam pengkodean Dan jika Anda ingin cara mudah untuk menjalankan melalui daftar controller Anda belum mendapatkan akses ke tampilan terkait, kemudian gunakan kamus / hashtable, yang mendekati O (1) membaca waktu akses. Dengan begitu tidak ada kontaminasi, dan logika simulasi Anda tidak peduli apa yang diberikan penyaji, yang membuat hari Anda dan malam pengkodeandunia lebih mudah.
Sedangkan untuk pemusnahan, lihat kembali di atas. Pemusnahan area-minat adalah konsep logika simulasi. Artinya, Anda tidak memproses dunia di luar area ini (biasanya kotak, bundar atau bulat). Ini terjadi di loop controller / game utama, sebelum rendering terjadi. Di sisi lain, pemusnahan frustrasi murni terkait dengan render. Jadi lupakan tentang pemusnahan sekarang. Ini tidak ada hubungannya dengan grafik adegan, dan dengan berfokus padanya Anda akan mengaburkan tujuan sebenarnya dari apa yang Anda coba capai.
Catatan Akhir ...
Saya mendapatkan perasaan yang kuat bahwa Anda berasal dari latar belakang Flash (khusus AS3), mengingat semua detail tentang rendering dimasukkan di sini. Ya, paradigma Flash Stage / DisplayObject mencakup semua logika render sebagai bagian dari skenario. Tetapi Flash membuat banyak asumsi yang tidak perlu Anda buat. Untuk mesin game yang lengkap, lebih baik tidak mencampur keduanya, karena alasan kinerja, kenyamanan, dan pengontrolan kompleksitas kode melalui SoC yang tepat .