DIE Lösung ist es bestimmt nicht, sondern nur eine.
Ich finde es von handling her leichter wenn jedes Objekt seinen eigenen Vertexbuffer hat. Natürlich ist es dann bei der Übertragung zur Graka langsamer wenn du viele Objekte brauchst. Dafür brauchst du dir die Stellen nicht merken wo sich ein Objekt im Vertexbuffer befindet, sondern kannst immer den gesammten Vertexbuffer render.
Da ich immer mehrere Vertexbuffer nehme weiß ich es nicht, aber ist es denn möglich verschiedene Vertexformate in einem Vertexbuffer zu schreiben? Ich glaube zwar schon abe ich weiß es jetzt nicht
Also wenn du nur einen VB nehmen willst wäre eine Klasse für die Verwaltung schon nicht schlecht, diese könnte ihn dann (neu) anlegen und freigeben. Zudem könntest du dieser Klasse dann die Daten geben die in den VB sollen und sie werden dann automatisch reingeschoben und du bekommst ein Objekt zurück welches eine Referenz auf den VB, das Format, und die Positionen wo sich das Objekt im VB befindet zurück.
So würde ich es dann machen. Also eine Klasse für die Verwaltung und eine welche ein einzelnes Objekt repräsentiert.
Mir ist gerade noch ein Grund eingefallen der gegen einen einzigen Vertexbuffer spricht. Wenn du während des Programmablaufs ständig neue Objekte nachlädst oder zerstörst könnte das Handling mit einem VB sehr umständlich und eventuell sogar langsamer werden. Denn es kann schnell passieren das dein VB fragmentiert. Defragmentieren wäre zwar möglich kostet aber viel Zeit und Verwaltungsaufwand (Positionsdaten anpassen). udem müsstest du den kompletten VB nach jeder Änderung komplett übertragen, auch wenn du viele Objekte davon nicht brauchst.
Solltest du pro Level (oder was auch immer) eine Konstante Anzahl an Objekten haben wäre ein einziger Vertexbuffer besser da du ihn nur beim Erstellen an die Graka übergeben musst.
Also kurz zusammengefasst:
Konstante Objekte pro Level ect. -> Ein Vertexbuffer
Häufige Änderung der Objektzahl -> Ein Vertexbuffer pro Objekt/Gruppe