TRIANGLE LIST oder STRIP?

hellihjb

wie man die Tangentenwerte für das Bumpmapping mit ins Format reinbekommt

einfach entsprechend viele zusaetzliche textur-koordinaten definieren (entweder in der vertex-struktur selbst oder zusaetzliche arrays anlegen) und die daten reinschreiben.

ceplusplus

hellihjb schrieb:

um zwei einzelne strips zu mergen braucht man lediglich zwei polygone (im strip also jeweils ein zusaetzlicher eckpunkt) mit jeweils zwei gleichen eckpunkten - ein solches polygon hat folglich einen flaecheninhalt von 0 und wird im rasterizer verworfen.
auf diese weise gelangt man quasi "unsichtbar" vom ende von strip1 zum anfang von strip2.
je nach anzahl deiner polygone im strip (gerade/ungerade) aendert sich dadurch die orientierung (gegen-/uhrzeigersinn) des folgenden (kompletten) polygons.
du benoetigst also anstatt 4 lediglich zwei oder drei zusaetzliche eckpunkte.

Ich bekomm es nicht hin. Warum muss ich 12 Primitives angeben, um 8 anzuzeigen?

Kannst du mir das vielleicht wie hier: http://krautland.net/primitives.jpg erklären? Wieviele vertices man wo benötigt.

hellihjb

in deiner skizze hast du 3 strips:

1: 00 01 02 03 04 05 06 07
2: 12 13 14 15 16 17 18 19
3: 24 25 26 27 28 29 30 31

die zusaetzlichen vertices seien mal ausser acht gelassen.
ausserdem sind deine polygone hier im uhrzeigersinn definiert, gewoehnlich macht man's andersrum - dadurch waere dein backface-culling invertiert.

die einzelnen polygone deines strips sehen also so aus:
(+/- zeigt die orientierung des polygons - diese aendert sich im strip bei jedem polygon)
1: 00 01 02 + (3 vertices des ersten polygons)
2: 01 02 03 - (jeweils die zwei letzten plus ein neuer vertex)
3: 02 03 04 +
4: 03 04 05 -
5: 04 05 06 +
6: 05 06 07 -

einzufuegen waeren in diesem fall zwei weitere:
(diese polygone haben jeweils zwei identische vertices, sind also nicht sichtbar)
7: 06 07 07 +
8: 07 07 12 -

darauf folgt der zweite strip:
9: 07 12 12 +
10:12 12 13 -
11:12 13 14 + (hier ist das erste polygon des folgenden strips komplett)
12:13 14 15 -
...

im falle einer ungerade polygonanzahl wuerde sich also die orientierung des folgenden strips aendern. entweder man fuegt einen weiteren doppelten eckpunkt ein oder aendert die orientierung des folgenden strips.

ceplusplus

Also sind es jetzt doch 4 Dreiecke, bis ich den nächsten strip fortführen kann?

7: 06 07 07 +
8: 07 07 12 -

9: 07 12 12 +
10:12 12 13 -

Die werden dann alle verworfen, also ist es egal?

Und wie kann ich die Anzahl der gezeichneten Dreiecke abfragen (DirectX9)?

MfG

hellihjb

Also sind es jetzt doch 4 Dreiecke

ja und nein.
indices 7 und 8 sind die vertices die zusaetzlich eingefuegt werden muessen,
9 und 10 sind die ersten beiden vertices des neuen strips die fuer sich alleine ja noch kein vollstaendiges polygon ergeben.

Die werden dann alle verworfen, also ist es egal?

die vertices gehen durch die transformationseinheit, liegen aber (sofern indexed strips) sowieso noch im cache, kosten also an der stelle quasi nichts.
die daraus resultierende polygone werden beim backface-culling test verworfen da flaecheninhalt gleich 0.
der aufwand eines zusaetzlichen rendercalls waere bei weitem hoeher.

wie kann ich die Anzahl der gezeichneten Dreiecke abfragen?

die anzahl hast du doch angegeben
falls du herausfinden willst, wieviele degenerierte triangles vom rasterizer verworfen wurden, wird das leider nicht (ohne weiteres) moeglich sein...

TGGC

hellihjb schrieb:

falls du herausfinden willst, wieviele degenerierte triangles vom rasterizer verworfen wurden, wird das leider nicht (ohne weiteres) moeglich sein...

Reicht es nicht, einmal durch die Indexliste zu gehen, und zu zaehlen, wie viele Dreiecke 3 unterschiedliche Eckpunkte haben? f'`8k

Gruß, TGGC (\-/ has leading)

ceplusplus

Ich arbeite ohne indexbuffer.

Indices 7 und 8? Du meinst wohl Dreiecke 7 und 8?

Oder besteht ein Indiz immer aus 3 Werten?

MfG

hellihjb

Indices 7 und 8? Du meinst wohl Dreiecke 7 und 8?

ich meinte diejenigen indizes die polygon 7 und 8 definieren, also vertex 07 und 12.

Ich arbeite ohne indexbuffer.

dann ist dein vertexbuffer circa doppelt so gross wie er zu sein braeuchte.

Oder besteht ein Indiz immer aus 3 Werten?

nein, indizien sind etwas voellig anderes

ceplusplus

Die Reihenfolge der Verbindungen...

Wäre es nun ratsam, einen indexbuffer zu verwenden?

MfG

rapso

ohne indices gibt werden alle triangles erstmal verarbeitet -> keine degenerierten. ohne indices gibt es auch ne schlechte cache ausnutzung. am besten sind indicierte trianglelists.

ceplusplus

Aber bei ner TriangleList braucht man doch viel mehr vertices?

Sind indizierte TriangeStrips nicht das beste für ein Terrain?

Es muss doch Fakten geben.

MfG

rapso

ceplusplus schrieb:

Aber bei ner TriangleList braucht man doch viel mehr vertices?

nein, nur mehr indices.

Sind indizierte TriangeStrips nicht das beste für ein Terrain?

Es muss doch Fakten geben.

ja, indizierte trilist.

ceplusplus

Die Mehrheit meint wohl, triangleStrips seien performanter, da doch nicht so viele indices verwendet werden.
Da muss doch was dran sein?

MfG

rapso

indices selbst haben keine performancerelevanz, weder ist ihre datenmenge relevant, noch ihre verarbeitungsgeschwindigkeit, vertices sind das problem.
-> vertices sollten so optimal wie nur moeglich fuer die GPU geliefert werden.

dot

so ist es und das sagt z.b. nvidia auch.
indizierte triangle lists. wers immer noch nicht glaubt, braucht einfach nurmal google zu bemühen...

ceplusplus

Also trianglelists sind schneller, weil weniger vertices verwendet werden? Zwar mehr indices, aber das macht ja anscheinend nichts aus.

rapso

ceplusplus schrieb:

Also trianglelists sind schneller, weil weniger vertices verwendet werden? Zwar mehr indices, aber das macht ja anscheinend nichts aus.

es werden immer gleich viele vertices verwendet, aber als trianglelist liegen sie optimaler vor, wenn also ein vertex gerade schon bearbeitet wurde und im chace ist muss es nicht nochmal bearbeitet werden.

ceplusplus

Immer gleich viele vertices?

TriangleStrip (Für ein Rechteck zB.):

0 - 1 - 2
1 - 2 - 3

TriangleList:

0 - 1 - 2
3 - 4 - 5

??

MfG

dot

nein, wir haben indices:

strip:

0-1-2-3

2 dreiecke, 4 vertices, 4 indices

list:
0-1-2
2-1-3

2 dreiecke 4 vertices, 6 indices

ok, jetzt zeichnen wir 2 nicht zusammenhängende quads:

strip:

0-1-2-3-3-4-4-5-6-7

8 dreiecke (4 degenerierte), 8 vertices, 10 indices

list:

0-1-2
2-1-3
4-5-6
6-5-7

4 dreiecke, 8 vertices, 12 indices

3 nicht zusammenhängende quads:

strip:

0-1-2-3-3-4-4-5-6-7-7-8-8-9-10-11

14 dreiecke, 12 vertices, 16 indices

list:

0-1-2
2-1-3
4-5-6
6-5-7
8-9-10
10-9-11

6 dreiecke, 12 vertices, 18 indices

beides gibt das gleiche ergebnis und nutzt den vertex cache gleich effizient (2 hits pro dreieck). aber die strip variante braucht min. doppelt so viele dreiecke die zwar degeneriert sind und nicht gezeichnet werden, die graka muss aber trozdem erstmal nachschauen um das zu bemerken was bei der list entfällt.
die list braucht hingegen nur konstant 2 indices mehr als der strip.
bei guten optimierungen und größeren meshes wird der unterschied zwischen strip und list praktisch gegen 0 gehen, wobei lists einfacher zu handhaben sind.
bei lists muss man natürlich unbedingt auf den vertex cache achten (also schauen, dass man nich wahlos in der gegend rumspringt, das wär natürlich der overkill).

wenn man jetzt größere zusammenhängende flächen hat und einen vertex cache von, sagen wir 12 vertices, sollte man natürlich benachbarte dreicke die sich vertices teilen zusammennehmen, um möglichst oft ein vertex zu recyclen bevor es von einem andren aus dem cache geworfen wird. das erfordert unter umständen "kleine sprünge in näherer umgebung" die man mit einer list so fast gratis bekommt, bei einem strip aber degenerierte dreiecke erfordern. wenn man bedenkt, dass ein index normalerweise nur 2 byte groß ist und die list nicht soo viel mehr indices als der strip benötigt, wird unterm strich nichts wirklich gegen eine list und nichts wirklich für einen strip sprechen, wobei die list meine wahl wäre, da imo einfacher und universeller einsetzbar.

afaik sind außerdem lists das lieblingsessen von modernerer hardware

ceplusplus

Danke, das ist mal ne Antwort!

Schade, jetzt wird alles noch komplizierter (eigenes Modellformat, loader...).

MfG