Avec les VBO, vous avez généralement deux avantages majeurs.
L'avantage 1 concerne les données entièrement statiques et provient de la possibilité de conserver vos données de sommet en mémoire, ce qui est plus optimal pour le GPU.
L'avantage 2 concerne les données dynamiques et provient de la possibilité de spécifier vos données de sommet à tout moment avant de les utiliser pour le rendu, ce qui peut mieux les canaliser.
Un troisième avantage provient du traitement par lots des appels de tirage, mais est également partagé avec les tableaux de vertex à l'ancienne, donc je ne l'appelle pas spécifiquement pour les VBO. L'envoi de données à un GPU (ou l'utilisation de données déjà sur le GPU) est similaire à bien des égards aux E / S de disque et au trafic réseau - si vous avez quelques grands lots, c'est plus efficace que de nombreux petits lots.
Une bonne analogie (pas 100% précise mais suffisante pour vous aider à comprendre) est que si vous êtes un chauffeur de bus qui doit amener 50 personnes d'une ville à l'autre. Vous pouvez les charger un à la fois et effectuer 50 trajets distincts - c'est glBegin / glEnd. Alternativement, vous pouvez mettre tous les 50 dans le bus et faire un seul voyage - c'est-à-dire avec des tableaux de vertex ou des VBO (dans le cas VBO, les 50 personnes seraient déjà dans le bus;)).
Cela a cependant un prix, et ici le prix est que vous perdez la possibilité de simplement spécifier les données de sommet au fur et à mesure que vous en avez besoin. Eh bien, OK, vous pouvez le faire (avec un travail supplémentaire), mais vous n'obtiendrez pas toutes les performances de votre code. Au lieu de cela, vous devez réfléchir davantage à vos données de sommet, à la façon dont elles sont utilisées, à la manière (et si) qu'elles doivent être mises à jour, à la possibilité de réaliser des animations dans un shader (permettant ainsi aux données de rester statiques - les VBO ont vraiment besoin de shaders pour un beaucoup de cas d'animation pour bien fonctionner) ou si vous avez besoin de spécifier à nouveau les données de sommet chaque image, des stratégies de mise à jour efficaces si ces dernières, etc. Si vous ne faites pas cela et implémentez simplement une conversion naïve, vous avez un risque très élevé de mettre dans beaucoup de travail seulement pour que le résultat final fonctionne réellement plus lentement!
Cela peut sembler énormément de travail lorsque vous le rencontrez pour la première fois, mais ce n'est pas vraiment le cas. Une fois que vous êtes dans le mode de penser comme ça, vous constaterez en fait que c'est incroyablement facile et vient presque naturellement. Mais vous pouvez gâcher vos premières tentatives et ne vous découragez pas si c'est le cas - le gâchis est l'occasion d'apprendre de ce que vous avez fait de mal.
Quelques dernières réflexions.
Avoir vos données de modèle dans un format qui peut être facilement chargé dans un VBO peut vous aider à rendre ce processus beaucoup plus facile. Cela signifie que vous devez éviter les formats plus complexes ou exotiques, au moins au début (et jusqu'à ce que vous soyez plus à l'aise avec le processus); gardez les choses aussi simples et basiques que possible lors de l'apprentissage et il y aura moins de choses à se tromper et moins d'endroits où chercher des erreurs si (ou quand!) les choses tournent mal.
Les gens sont parfois découragés s'ils voient une implémentation VBO utilisant plus de mémoire qu'une implémentation glBegin / glEnd optimisée / compressée (ils peuvent même l'appeler "gaspillage"). Ne sois pas comme ça. Sauf dans les cas extrêmes, l'utilisation de la mémoire n'est vraiment pas si importante. C'est un compromis clair ici - vous acceptez une utilisation de la mémoire potentiellement plus élevée en échange de performances sensiblement supérieures. Aide également à développer l'état d'esprit selon lequel la mémoire est une ressource bon marché et abondante qui peut être utilisée; la performance ne l'est pas.
Et enfin le vieux châtaignier - s'il est déjà assez rapide, votre travail est terminé. Si vous atteignez votre cadence d'images cible, si vous avez de la marge pour les conditions transitoires, alors c'est assez bon et vous pouvez passer à l'étape suivante. Vous pouvez perdre beaucoup de temps et d'énergie en extrayant 10% supplémentaires de quelque chose qui n'en a pas réellement besoin (été là, fait cela, toujours tomber dans le piège), alors pensez toujours à l'utilisation la plus optimale de votre temps - parce que le temps du programmeur est encore moins bon marché et moins abondant que la performance!
