spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

hi

in vertex bzw. indexbuffern werden wie der name schon sagt vertices bzw. indices gespeichert. mehr nicht
es ist natürlich möglich mehrere modelle in einem vertex und index buffer zu speichern. über die entsprechenden offsets kannst du die auch auseinanderhalten ( von 0 bis 250 is das erste modell, 251 bis. 1056 das zweite, ... ).
ich persönlich hab für jedes modell einen eigenen vertex und indexbuffer.

Es ist sehr Sinnvoll einen Buffer Manager und einen Textur Manager zu schreiben der die Daten verwaltet. Damit sparst du sehr viel Speicher, da keine Redundanten Daten mehr vorliegen.
Das gleiche kannst du auch für die kompletten Modelle machen. Die meisten Modelldaten eines Modells sind immer gleich. Unterschiede gibt es nur wenn man daraus z.B. einen Character macht. Diese haben Unterschiedliche Positionen und Gegenstände in den Händen und andere Animationsinformationen.
Es ist also Sinnvoll zwischen einem Modell und z.B. einem Character oder Spielobjekt (wie z.B. eine einfache Kiste) zu Unterscheiden. Damit kannst du dann noch einmal Speicher sparen.

Irgendwo in diesem Forum gab es schon einmal eine Diskusion über die Verwaltung von Vertex Buffern. Dabei kamm der Vorschlag eine Liste von Vertexbuffern aufzubauen die n Byte Groß sind (z.B. 64KB). Dies kann sich als sehr vorteilhaft erweisen.
Was nicht sehr gut ist wenn man viele Modelle in einem großen VertexBuffer hat. Weil ein Buffer immer komplette hin und her geschoben wird. Wenn der Buffer dann ein paar Megabyte groß ist, wirckt sich das sehr negativ auf die Performance aus. Zudem ist die Möglichkeit größer das er im Hauptspeicher liegt und nicht im VRAM.
Da haben die VB Listen ihren vorzug. Da sie eher klein sind, finden sie eher eine Lücke im VRAM und um Platz im VRAM zu schaffen muss man auch immer nur kleine häpchen verschieben.

Von der Handhabung her ist es am einfachsten für jedes Modell einen VB zu erzeugen. Was aber gar nicht geht ist das man in einem IB meherere Modell speichert. Schon bei der Darstellung meines Terrains bin ich durch den IB begrenz. Da die Hardware nur n Indices erlaubt.

In meiner Aktuellen Engine werd ich es so machen.
Direct3D erlaubt es einen Formatlosen VB zu erstellen. In diesen kannst du unabhängig vom Vertexformat, vertice speichern. Dann produzierst du einen Manager der einfach ein Array von Vertice annimmt. Dieser Manager verteilt dann das Array auf die einzelnen 64KB großen VertexBuffer die in einer einfachen Liste gespeichert werden. Als ergebnis bekommt man dann einen Satz Offsets geliefert die den Bereich angeben in dem sich das Modell befindet.
IndexBuffer speichert die Modellklasse selber. Weil diese sehr begrenzt sind und nicht alle Modelle einenen IndexBuffer haben müssen. Bei kleineren Modellen ist es eh überflüssig.

Was für Vertice man nun im Manager ablegt spielt keine Rolle. Ich werde das in einem VB Interface kapseln. so sieht es für den Benutzer aus als würde er für jedes Modell einen VertexBuffer erstellen. Intern geht alles über die Liste.

Nun Rendert man nicht mehr einzelne VertexBuffer sondern Bereiche die n VertexBuffer enthalten können. Der Vorteil liegt auf der Hand. Die change das viele VertexBuffer bereits im VRAM liegen ist größer als wenn man mehrere Große hat.


Wie gesagt so werd ich das machen. Da ich über ein VB Interface gehe werd ich aber auch die Möglichkeit offen lassen zu wählen. Entweder Manager oder Einzelner VB. Da es grad bei den Leveldaten um sehr große Datenmengen geht, kann es sich vorteilhafter auf die Performance auswircken wenn man nicht über den Manager geht.

Zitat

Wie ist es denn mit den Level Daten. Nehmen wir an, ich habe 2 Räume mit einem Gang, der sie verbindet. Diese Level Daten werden dann in einen Vertexbuffer gepackt, oder auch auf mehrere aufgeteilt?

Ja das ist eine gute Frage. Die sich wohl jeder von uns gestelt hat oder noch stellen wird. Ein gutes Konzep hab ich dafür noch nicht. Bei einem Terrain habe ich es so gemacht das alle Vertice in einem VB liegen und die Leafs enthalten dann jeweils einen IB, die dann mit dem VB gerendert werden. Ideal ist das aber nicht da der VB sehr groß ist. Sollte er einmal verschoben werden müssen, kostet das viel Zeit.

Also bei mir ist es so:

Ich habe ne Model-Klasse, welche u. a. Zeiger auf die Vertex und IndexBuffers (also die Modelldaten) hat. Der Konstruktor erwartet u.a. gültige Zeiger auf nen VB und IB.

(Ich schreib ab jetzt VB/IB für VertexBuffer/IndexBuffer)

Wenn man also jetzt ein Modell erzeugen will, guckt man erst im VB/IB-Manager nach, ob die Modelldaten (z. B. für ein klitzegleiches Modell) schon geladen wurden. Wenn ja erzeugt man die Modell-Klasse mit ebendiesem schon geladenen VB/IB. Wenn nicht lädt man die Daten neu, registriert sie beim VB/IB-Manager und übergibt sie dem Konstruktor der Modellklasse als Parameter.

Vielleicht hilft dir das weiter. Mich würde interessieren, ob du (oder irgendjemand) ne bessere Methode kennt...


Samuel G.