Essa é realmente uma escolha entre desempenho e flexibilidade, mas vou listar minhas opiniões sobre isso.
Um único VBO
Os lados positivos são:
- Apenas uma chamada para desenhar sua cena. Isso aumenta o desempenho. Embora seu aplicativo possa exigir várias chamadas de sorteio, você ainda pode ter um único VBO e deixar a contagem e o deslocamento decidirem seu desenho.
- Não exigindo alterações de estado entre seus objetos. Isso aumenta o desempenho.
e os lados negativos são:
- Difícil de gerenciar, embora isso dependa de como você escreve seu código, se ele foi projetado corretamente, etc.
- Ao dizer que é difícil gerenciar, quero dizer coisas como atualizar o VBO, definir o deslocamento correto para cada objeto etc.
VBO individual: s
Os lados positivos são:
- Fácil de implementar.
- Mais fácil de gerenciar desde o início.
e os lados negativos são:
- Muitas mudanças de estado. Isso diminui o desempenho.
- Muitas chamadas de sorteio. Isso diminuirá o desempenho.
Sumário
Eu recomendo que você crie um perfil do seu aplicativo; obtenha seu gargalo real nos dados que você pode ver. A otimização prematura pode ser mostrada (neste caso) como desnecessária. No entanto, dito isso, se você descobrir uma perda real de desempenho em seu aplicativo, dado o cenário individual da VBO: s , poderá começar a implementar uma única VBO.
No entanto, contanto que não seja necessário (o número de objetos é baixo, não há muitas alterações de estado no geral, etc.) eu recomendaria usar VBO: s individuais, a menos que você veja que isso não vai funcionar.
Editar
Eu esqueci de mencionar que ficaria tudo bem com várias chamadas de empate. O mais importante em tempos críticos de desempenho é manter as mudanças de estado no mínimo. Você pode simplesmente definir o número de índices a serem processados e um deslocamento para cada chamada de empate, e isso é bom. Mas, no entanto, mantenha as mudanças de estado o mais baixas possível e faça o menor número possível de chamadas, esse é o grande olá desta resposta, ou pelo menos o que tentei dizer.