Dengan VBO Anda umumnya memiliki dua keunggulan utama.
Keuntungan 1 berhubungan dengan data yang sepenuhnya statis dan berasal dari kemampuan untuk menyimpan data verteks Anda dalam memori yang lebih optimal untuk GPU.
Keuntungan 2 berhubungan dengan data dinamis dan berasal dari kemampuan untuk menentukan data verteks Anda kapan saja sebelum menggunakannya untuk rendering, yang dapat menyalurkan lebih baik.
Keuntungan ketiga berasal dari batch call draw, tetapi juga dibagikan dengan array vertex jadul jadi saya tidak memanggilnya khusus untuk VBO. Mengirim data ke GPU (atau menggunakan data yang sudah ada di GPU) serupa dalam banyak hal dengan I / O disk dan lalu lintas jaringan - jika Anda memiliki beberapa batch besar, itu lebih efisien daripada banyak batch kecil.
Analogi yang baik (tidak 100% akurat tetapi cukup untuk membantu Anda mendapatkan ide) untuk ini adalah jika Anda seorang pengemudi bus yang harus membawa 50 orang dari satu kota ke kota lain. Anda dapat memuatnya satu per satu dan melakukan 50 perjalanan terpisah - itulah glBegin / glEnd. Atau Anda dapat menempatkan semua 50 di bus dan hanya melakukan perjalanan tunggal - itu batching dengan array vertex atau VBO (dalam kasus VBO 50 orang sudah berada di bus;)).
Ini ada harganya, dan di sini harganya adalah Anda kehilangan kemampuan untuk hanya menentukan data titik saat dan ketika Anda membutuhkannya. Baiklah, Anda bisa melakukannya (dengan beberapa pekerjaan tambahan), tetapi Anda tidak akan mendapatkan kinerja penuh dari kode Anda. Alih-alih, Anda perlu lebih memikirkan data verteks Anda, bagaimana data itu digunakan, bagaimana (dan jika) itu perlu diperbarui, apakah ada animasi yang dapat dilakukan dalam shader (sehingga memungkinkan data tetap statis - VBO benar-benar membutuhkan shader untuk banyak kasus animasi agar bekerja dengan baik) atau apakah Anda perlu meresepkan data vertex setiap frame, strategi pembaruan yang efisien jika yang terakhir, dll. Jika Anda tidak melakukan ini dan hanya menerapkan konversi naif Anda memiliki risiko yang sangat tinggi untuk menempatkan dalam banyak pekerjaan hanya untuk hasil akhirnya benar-benar berjalan lebih lambat!
Ini bisa tampak seperti pekerjaan yang sangat buruk ketika Anda pertama kali menemukannya, tetapi sebenarnya tidak. Setelah Anda masuk ke mode berpikir seperti ini, Anda akan benar-benar menemukan bahwa itu sangat mudah dan hampir muncul secara alami. Tetapi Anda dapat mengacaukan beberapa upaya pertama Anda dan Anda tidak harus berkecil hati jika demikian - mengacaukan adalah kesempatan untuk belajar dari kesalahan Anda.
Beberapa pemikiran terakhir.
Memiliki data model Anda dalam format yang dapat dengan mudah dimuat ke VBO dapat membantu membuat seluruh proses ini jauh lebih mudah bagi Anda. Itu berarti Anda harus menghindari format yang lebih kompleks atau eksotis, setidaknya pada awalnya (dan sampai Anda lebih nyaman dengan prosesnya); pertahankan hal-hal sesederhana dan sesederhana mungkin saat belajar dan akan ada lebih sedikit hal yang salah, dan lebih sedikit tempat yang harus dicari kesalahannya jika (atau kapan!) ada yang salah.
Orang-orang kadang-kadang menunda jika mereka melihat implementasi VBO menggunakan lebih banyak memori daripada implementasi glBegin / glEnd yang dioptimalkan / terkompresi (mereka bahkan dapat menyebutnya sebagai "limbah"). Jangan seperti itu. Kecuali dalam kasus yang ekstrim, penggunaan memori benar-benar tidak begitu penting. Ini pertukaran yang jelas di sini - Anda menerima kemungkinan penggunaan memori yang lebih tinggi dengan imbalan kinerja yang jauh lebih tinggi. Juga membantu mengembangkan pola pikir bahwa ingatan adalah sumber daya yang murah dan berlimpah yang ada untuk digunakan; kinerja tidak.
Dan akhirnya kastanye tua - jika sudah cukup cepat maka pekerjaan Anda selesai. Jika Anda menekan framerate target Anda, jika Anda memiliki ruang kepala untuk kondisi sementara, maka itu cukup baik dan Anda dapat melanjutkan ke langkah berikutnya. Anda dapat membuang banyak waktu dan energi untuk memeras tambahan 10% dari sesuatu yang sebenarnya tidak membutuhkannya (pernah ada, melakukan itu, masih jatuh ke dalam perangkap) jadi selalu pertimbangkan penggunaan paling optimal dari waktu Anda sendiri. - karena waktu programmer bahkan lebih murah dan kurang melimpah dari kinerja!