spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Der letzte Fall wäre klar, weil indexierte Vertices viel weniger Bus-Traffic verursachen. Aber wenn es sich um ein statisches Gelände handelt, dürfte da meiner Meinung nicht (viel) mehr bei rum kommen. Aber deswegen frage ich ja, ich bin mit der Technik auch nicht immer so up to date. Kann ja sein, dass Index-Buffer wegen Caching oder sonstewas doch merklich schneller ist.

Zitat von »BlueCobold«

Macht denn das das Rendering an sich schneller? Wenn die Daten eh schon in den Grafik-Ram übertragen wurden macht es doch keinen Unterschied mehr an FPS ob ich mit oder ohne Index arbeite, oder?

Doch, sogar einen wesentlichen. Der nennt sich Vertex-Cache
Natürlich setzt das voraus dass die Daten entsprechend dafür geeignet sind, aber selbst ein naiver Algorithmus sollte beim Erzeugen eines regelmäßigen Grid zumindest ein bisschen vom Cache profitieren.

Vor allem mit trianglestrips, damit kann man wohl am meisten vom cache profitieren - geht gerade bei terrains recht gut

Indizierte Triangle Lists sind potentiell sehr viel optimaler als Strips. Das Märchen dass Strips das Optimum wären kommt noch aus Zeiten da es keine indizierten Primitive gab
Bei einem Tristrip findest du immer maximal 2 Vertices im Cache, d.h. du hast im Idealfall (1 langer Strip) eine Missrate von 1/Triangle. Mit einer cacheoptimierten Trilist bekommst du Missrates um 0.6/Triangle zusammen.

Allerdings ist es bei nem regelmäßigen Gitter ja mehr oder weniger der naive Ansatz Strips zu generieren und vom Nutzen/Aufwand her sicher schon super. Eine richtige Cacheoptimierung mit raumfüllenden Kurven und so ist natürlich viel aufwändiger...

Mit der Aussage von dot kann ich ja noch mitgehen, aber wieso profitiert ein Triangle-Strip jetzt mehr vom Cache? Er macht weniger Zugriffe insgesamt, aber das heißt doch nicht, dass es vom Caching mehr profitiert.

Edit:
Und da war auch schon der dot schneller