Grafik Pemandangan sebagai Wadah Objek?

Grafik adegan berisi simpul game yang mewakili objek game. Pada pandangan pertama, mungkin tampak praktis untuk menggunakan Grafik Scene sebagai wadah fisik untuk dalam objek game, daripada std :: vector <> misalnya.

Pertanyaan saya adalah, apakah praktis untuk menggunakan Scene Graph untuk memuat objek-objek game , atau haruskah itu digunakan hanya untuk mendefinisikan objek-objek adegan / simpul-simpul, sementara menyimpan objek-objek yang disimpan dalam wadah yang terpisah, seperti std :: vector <>?

architecture scene-graph

— Bunkai.Satori
sumber

Adakah yang punya ide? Saya berencana untuk menggunakan kedua Grafik Scene untuk mengatur Aktor / Node Game, dan kemudian Vektor untuk melakukan berbagai penyortiran yang harus lebih cepat daripada menyortir pohon SceneGraph multi jalur.

— Bunkai.Satori

@ Semua: Saya punya satu pertanyaan lagi: apakah SceneGraph berisi seluruh peta, atau haruskah hanya berisi sebagian peta, katakanlah area yang terlihat? Jelas, Grafik Adegan kemudian akan terus diperbarui, saat pemain bergerak di atas peta.

— Bunkai.Satori

Jawaban:

Memutuskan jenis manajemen adegan yang akan digunakan sangat bergantung pada jenis logika apa yang Anda coba jalankan. Pertimbangkan berbagai konsumen adegan Anda:

Memberikan Konsumen

Perender mungkin hanya ingin tahu apa yang saat ini terlihat oleh pengguna pada titik tertentu. Ia menginginkan hierarki volume yang terikat untuk pemusnahan cepat ( artikel wiki BVH) sehingga dapat mengetahui bahwa kursi di dalam kapal tidak perlu ditarik karena batas-batas kapal berada di luar pandangan frustum. Ini mungkin tertanam ke dalam sebuah octree .

Mungkin juga ingin memiliki gagasan bahwa kursi berada di punggungnya di dalam kapal, dan bahwa perahu itu berguling-guling di atas beberapa ombak ketika akhirnya terlihat. Dengan cara itu untuk menemukan koordinat dunia akhir dari simpul kursi, ia dapat menggabungkan transformasi kursi dan kapal dan dilakukan dengannya (ini juga membuat pekerjaan Anda sebagai programmer lebih mudah).

Namun cara lain untuk melihat masalah ini adalah bahwa penyaji mungkin menjalankan kartu yang bagus, dan akhirnya hanya ingin setumpuk segitiga diurutkan sehingga meminimalkan tekstur, shader, material, pencahayaan, dan mengubah perubahan keadaan. Yang terakhir ini mungkin akan membantu Anda lebih dari BVH, berdasarkan kinerja.

Pengguna Logika Game

Logika gim mungkin hanya menginginkan daftar datar hal-hal yang dapat saling berbicara dengan sistem pesan, sehingga std :: vector mungkin baik-baik saja.

Gim ini mungkin juga menginginkan cara untuk melacak siapa yang paling dekat dengan apa, jadi semacam informasi [tetangga terdekat] [3] mungkin bisa membantu dalam kasus itu. Ini dapat disediakan oleh BVH juga, tetapi harus naik turun grafik mungkin mengganggu.

Gim ini bahkan mungkin hanya ingin tahu bahwa ketika bergerak A, item A harus bergerak juga ... dalam hal ini kita kembali ke semacam hierarki transformasi.

Konsumen Fisika

Fisika gim Anda mungkin ingin memiliki [representasi khusus] [4] ruang dalam ruangan untuk deteksi tabrakan yang sangat cepat. Bergantian mungkin menggunakan semacam octree atau [hashing spasial] [5] untuk secara efisien menemukan hal-hal yang mungkin bertabrakan.

Tidak ada struktur data fisika di atas yang benar-benar terlihat seperti "grafik adegan" dalam arti Java3D.

Konsumen Audio

Mesin audio hanya ingin geometri, mungkin set yang berpotensi terlihat (terdengar), atau semacam hierarki volume yang terikat untuk menghitung pelemahan dan penyebaran suara. Sekali lagi, tidak benar-benar semacam grafik adegan, meskipun mungkin grafik geometri dalam adegan Anda.

Pada akhirnya ... ... itu benar-benar hanya tergantung pada kebutuhan aplikasi Anda. Saya sarankan menggunakan daftar datar untuk memulai, dan melihat di mana masalah Anda muncul. Anda bahkan dapat mencoba daftar datar dengan hierarki transformasi, karena itu mungkin satu jenis naskah yang berguna untuk alasan selain efisiensi.

Semoga berhasil!

— ChrisE
sumber

@ Chris: +1 untuk pertanyaan luar biasa. Menurut pendapat saya, ini adalah jawaban terbaik di sini, karena itu saya tandai yang ini sebagai Jawaban yang Diterima . Jika saya mengerti dengan benar, Anda membuktikan bahwa Scene Graph tidak selalu merupakan solusi akhir. Khususnya dalam Game Logic, apakah Anda melihat Grafik Adegan sebagai cara yang benar untuk memperbarui transformasi (skala, terjemahan) objek terkait? Contoh, kursi ada di atas kapal, jadi koordinat kursi diperbarui saat perahu bergerak? Atau, apakah Anda melihat solusi yang lebih baik untuk pembaruan koordinat relatif?

— Bunkai.Satori

@ ChrisE: Selain yang disebutkan di atas, dalam kasus Scene Graph digunakan, dapatkah itu sendiri digunakan sebagai satu-satunya pemegang benda untuk adegan, atau Anda akan merekomendasikan memiliki wadah lain (katakanlah std :: vector <>) selain Scene Grafik?

— Bunkai.Satori

Saya sebenarnya sedang dalam proses menyarankan hal itu. Saya akan mencoba menjaga hierarki transformasi (di sini, pohon n-ary di mana node memiliki satu orangtua dan beberapa anak, dan tidak ada anak yang dibagikan di antara node) dengan setiap node yang berisi referensi ke objek game. Objek game disimpan dalam array datar dan terpisah (katakanlah, std :: vector).

— ChrisE

Selama pembaruan, Anda dapat menjelajahi daftar datar dan melakukan logika permainan, dan setiap kali gerakan relatif terjadi (katakanlah, kursi didorong ke depan di atas kapal) Anda menggunakan hierarki transformasi untuk menemukan transformasi lokal ke dunia terakhir dengan berjalan orang tua dari objek Anda dan menyatukan transformasi mereka. Ini menggunakan hierarki transformasi untuk apa yang terbaik (menyederhanakan gerakan relatif), dan masih memungkinkan Anda menyimpan daftar objek yang nyaman di sekitar.

— ChrisE

Perbaikan lebih lanjut adalah untuk menjaga di setiap objek bendera kotor dan transformasi segala sesuatu di atasnya dalam hierarki transformasi. Transformasi parent-to-world cache (yang baru saja saya sebutkan) berarti bahwa untuk setiap pembaruan posisi objek, Anda hanya perlu melakukan satu perkalian matriks (transformasi relatif ke orangtua dengan transformasi orangtua-ke-dunia). Setiap kali Anda memperbarui transformasi relatif, Anda juga memperbarui bendera kotor Anda.

— ChrisE

Ada satu alasan bagus untuk tidak menggunakan grafik adegan sebagai wadah untuk objek game, dan itu adalah instancing. Jika Anda ingin menggunakan kembali beberapa sumber daya, jauh lebih masuk akal untuk hanya merujuk ke sumber daya dari grafik adegan Anda beberapa kali daripada memiliki beberapa salinan yang sebenarnya.

— Jari Komppa
sumber

@Jari: +1 untuk jawaban yang bagus. Seperti yang saya pahami, pendekatan umum, adalah memiliki wadah terpisah dari jerat yang dapat diulang. Grafik adegan biasanya mengacu pada wadah jerat yang dapat di render, untuk mengambil informasi bentuk objek. Selain itu, setiap simpul grafik adegan berisi informasi transformasi. Jari, memiliki desain seperti itu, saya ingin tahu, apakah masih disarankan untuk memiliki wadah std :: vector <> yang terpisah untuk node game, katakan untuk tujuan pengurutan yang lebih cepat, atau alasan lain ..

— Bunkai.Satori

Tergantung - mungkin berguna untuk benar-benar memiliki beberapa daftar linear dari node untuk pemrosesan AI, fisika, apa pun yang lebih cepat. Tapi saya akan pergi ke sana setelah saya melihat apakah ada masalah sebaliknya.

— Jari Komppa

Jadi, untuk menyimpulkan, seharusnya dapat diterima bahwa permulaan hanya memiliki satu SceneGraph, yang akan berisi semua objek dalam adegan. Bisakah Anda memberi saran, jika kamera, lampu, pemicu harus ada dalam grafik adegan juga?

— Bunkai.Satori

Segala sesuatu yang dipengaruhi oleh hierarki transformasi harus ada dalam grafik adegan, tapi saya masih tidak akan memberikan kepemilikan grafik adegan, tetapi menyimpannya di tempat lain untuk pemrosesan (animasi, fisika, dll) yang lebih mudah.

— Jari Komppa

Dipahami Jari. Terima kasih. Saya akan mulai dengan versi yang lebih kecil, dan menambahkan wadah lain untuk pemrosesan lebih mudah nanti sesuai kebutuhan.

— Bunkai.Satori

Memisahkan objectmodel dan viewmodel Anda (scenegraph) biasanya merupakan ide yang bagus.

Lihat artikel ini pada subjek.

Di antara banyak hal ini akan memungkinkan untuk penggunaan objek kolam. Yang mungkin penting untuk manajemen memori yang efisien.

— Nailer
sumber

+1 untuk kontribusi yang baik. Saya membaca artikel itu. Ini membahas pola pemrograman, dan jika saya mengerti dengan benar, Object Model akan membuat daftar objek dalam adegan diatur dalam semacam std: vector <> container, sementara ViewModel akan berisi objek yang sama yang diatur dalam Scene Graph? Namun, hanya objek yang sedang ditampilkan yang akan dimuat dalam Grafik Pemandangan?

— Bunkai.Satori

Dan bagaimana dengan kamera, pemicu, lighs? apakah mereka akan menjadi bagian dari grafik adegan juga?

— Bunkai.Satori

@ Bunkai.Satori Nah, Anda berpotensi memiliki hal-hal di scenegraph yang tidak ditampilkan di layar. Anda membangun scenegraph Anda, lalu Anda bisa menjalankan algoritma culling pada scenegraph sebelum merender node yang terlihat. Lampu kamera dan pemicu bisa ada baik dalam model dan model tampilan.

— Nailer

Terimakasih atas tanggapan Anda. Seperti yang Anda sebutkan pemusnahan , bagaimana hal itu dilakukan dalam praktek? apakah seluruh adegan termasuk dalam Grafik Adegan, atau hanya ada bagian yang terlihat? Jika seluruh adegan dalam Grafik Pemandangan, apakah seluruh grafik adegan dilalui per bingkai untuk mengirim hanya area yang terlihat ke OpenGL / DirectX API? Saya ragu bahwa seluruh adegan dikirim ke API berdasarkan per bingkai, karena bagian yang terlihat biasanya kurang dari 5% dari adegan lengkap. Atau, apakah grafik adegan diatur entah bagaimana, untuk dengan cepat mengambil area terdekat tanpa travelrsal penuh berdasarkan per-frame?

— Bunkai.Satori

Tempatkan seluruh adegan Anda di scenegraph. Seimbangkan grafik berdasarkan kriteria tertentu (mis. Anda bisa membuat oc-tree dari itu). Lintasi pohon dan tentukan simpul mana yang "Terlihat", "Terlihat sebagian" dan "Tak Terlihat" berdasarkan apakah kotak-kotak yang terikat ada dalam pandangan Anda. Anda dapat membuat "grafik visibilitas" super ringan yang pada dasarnya hanya terdiri dari referensi ke simpul dan bendera SG. Setelah pemusnahan frustrasi Anda dapat melintasi pohon lagi untuk melakukan pemusnahan oklusi. Mengulangi setiap frame, atau setiap frame di mana kamera atau pemandangan telah ditandai sebagai "kotor".

— Nailer