TRIANGLE LIST oder STRIP?
-
So habe ich es jetzt gemacht
Geht es vielleicht noch einfacher?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.Jetzt kann man aber sowohl eine Triangle List als auch ein Triangle Strip indizieren...
strips sparen index-daten waehrend triangle-lists flexiblere index-strukturen ermoeglichen.
es lassen sich jeweils beispiele finden fuer die das eine bessere loesungen ergibt als das andere.
-
@ABC++: Es heisst Pappnasen, und hier war nie von OGL die Rede. Und wieso sollte man in OGL was anderes als Index-Buffer verwenden? Vergiss glDrawArrays und vergiss Display Lists. Mach dir nen Vertex Buffer, schreib deine Vertices rein, mach nen Index Buffer, schreib deine Index Daten rein, und render es einfach (z.B. mit glDrawRangeElementsEXT). Ohne Display List, ohne sonstwas. Gleich wie man es in D3D machen würde. Die notwendige Extension heisst ARB_vertex_buffer_object, und ist in so gut wie jedem halbwegs aktuellen Treiber implementiert.
@xindon: Klar kann man Tri-Strips und Tri-Lists indizieren, bloss wenn man erstmal einen Index-Buffer verwendet, dann ist es ziemlich egal ob man nun Lists oder Strips rendert, da es kaum mehr einen Performance Unterschied gibt. Vorausgesetzt man organisiert seine Lists so dass die Indizes nicht "wild in der Gegend rumspringen". Mit Tri-Lists kann man eben meistens grössere Batches machen als mit Tri-Lists, und das bringt oft einiges. In OGL wohl weniger als in D3D, aber egal.
-
Mit Tri-Lists kann man eben meistens grössere Batches machen als mit Tri-Lists, und das bringt oft einiges
erklaer' mal.
-
hellihjb schrieb:
Mit Tri-Lists kann man eben meistens grössere Batches machen als mit Tri-Lists, und das bringt oft einiges
erklaer' mal.
Ja, ok, ich hätte sagen sollen "solange man nicht auf diverse Tricks zurückgreift". Wenn du degenerierte Dreiecke verwendest um Strips zu verbinden ist das natürlich nichtmehr so.
Auf jeden Fall würde ich die Performance von Strips vs. Lists in der speziellen Anwendung um die's geht vergleichen, und dann erst entscheiden ob es wert ist den zusätzlichen Aufwand zu treiben Strips zu verwenden.
-
Also bei statischer Geometrie in OGL sind Displaylisten durchaus eine Überlegung wert. Ich denke nicht, dass du da mit deinen VBOs schneller kommst.
-
Naja, ich hab einfach eine Abneigung gegen Display Lists, weil sie für die OGL Implementierung der blanke Horror sind. Rendern von statischer Geometrie sollte mit Display Lists - eine sehr gute OGL Implementierung vorausgesetzt - nahezu ohne Overhead möglich sein. Rendern mit Vertex Buffer + Index Buffer allerdings genauso.
Es soll natürlich jeder verwenden was er für richtig hält, für mich sind das halt VBOs.
p.S.: es sind nicht "meine VBOs", die verwendet eigentlich so gut wie jeder
-
Ah jo war ja nur ein Hinweis
Auf delphigl.com hat glaube mal einer einen vergleich gemacht und VBOs waren halt nicht schneller. Die Displaylisten sind bei guten Treibern schon ziemlich effizient, kan sogar schon "gehobenes" Frustum-Culling dabei sein, ist aber Treiberabhängig. Aber auf alle Fälle liegen die Daten ja im VRAM(falls noch Platz war^^), also im Prinzip dann wie die VBOs mit halt, wo man keine Änderungen mehr zulässt.
Aber das du dich mit VBOs auskennst trifft sich gut. Arbeite mich da grad etwas ein und bin am suchen, wie man mit VBOs auch die Tangentenwerte für das Bumpmapping(für die Shader) mit ins Format reinbekommt.
Weist du das?
-
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.
-
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.
-
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 31die 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.
-
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
-
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...
-
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)
-
Ich arbeite ohne indexbuffer.
Indices 7 und 8? Du meinst wohl Dreiecke 7 und 8?
Oder besteht ein Indiz immer aus 3 Werten?
MfG
-
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
-
Die Reihenfolge der Verbindungen...
Wäre es nun ratsam, einen indexbuffer zu verwenden?
MfG
-
ohne indices gibt werden alle triangles erstmal verarbeitet -> keine degenerierten. ohne indices gibt es auch ne schlechte cache ausnutzung. am besten sind indicierte trianglelists.
-
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
-
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.
-
Die Mehrheit meint wohl, triangleStrips seien performanter, da doch nicht so viele indices verwendet werden.
Da muss doch was dran sein?MfG
