So... ich muss mal eine Aussage von mir Revidieren. Weil sie Falsch ist.
Und zwar geht es um die VertexBuffer und die Stream Sources die man setzen kann. Da hab ich in einem anderen Thread (weis nicht mehr wo) gesagt, das man mit den Stream Sources mehrere Vertex Buffer an einander hängen kann. Das war im dem Zusammenhang mit der Aussage das Die Grakas besser mit gleich großen VB's umgehen können. Daher kam ich auf die Idee, das man einfach ein Array mit z.B. 64KB großen VB's anlegt und wenn ein Mesh mehr Platz braucht, werden die dann mittels den Stream Sources aneinander gehängt so das alle Daten wieder vollständig sind. Dies ist jedoch
nicht so!
Richtig ist es das man mit den Stream Sources mehrere VB's zusammenhängen kann, so das sie einen vollständigen Vertex ergeben. Also...jeder weis ja das man sich den Inhalt eines Vertex frei wählen kann (Stichwort FVF). Was die meisten aber wohl nicht wissen ist, das die Reihenfolge der Daten ebenfalls frei wählbar ist und
nicht fest vorgegeben ist. Die doku schreibt das hier zwar ein bisschen blöde. Aber man sollte sich mal die Vertex Declaraions Ansehen. Damit kann man nicht nur die Reihenfolge der Daten angeben, sondern auch in welchem VB die einzelnen Daten liegen. Dies wird mittels der Stream ID angegeben.
Ich hab dazu ein keines Test App geschrieben, in dem die Position und die Farbe jeweils einen eigenen VB haben und durch die Stream ID verbunden werden.
Wenn ich wieder zuhause bin werd ich das mal hochladen.
An dieser stelle noch mal ein dankeschön an David, der mich auf der Dusmnia drauf gestoßen hat
Das schöne daran ist, das man dadurch viel mehr Möglichkeiten hat und man vor allem diese besser umsetzen kann. Vor allem bei meinem Problem, das ich oben beschrieben habe.
Performancevorteile hat man dabei dann auch gleich. Denn mal im ernst, wenn man was verändert ist es doch meist nur die Position eines Vertex. Wenn man nun die Position in einem eigenen VB unterbringt brauch man nicht mehr so viele Daten hin und her schieben.
Beispiel: Ein std. Vertex hat eine Position, Normal und ein Texturkoordinaten Paar. Das sind dann gleich mal 32Byte/Vertex. Wenn man nun die Position ändern will, muss man 32Byte/Vertex erst in den RAM schieben und dann wieder zurück in den VRAM. Mit obigen verfahren brauch man jedoch nur 12Byte/Vertex hin und her schieben. Macht eine ersparniss von 20Byte/Vertex.
Bei einem Modell mit sagen wir mal 1000 Vertice sind das mal eben 20.000Byte die man weniger hin und her schieben muss.