TRIANGLE LIST oder STRIP?



  • [EDIT] sorry, bitte löschen



  • Tri-Strips sind IMHO was für old-school Anhänger.
    Mittlerweile verwendet man normalerweise Vertex-Buffer und Index-Buffer,
    damit sind Tri-Strips ziemlich umsonst, man kann einfach Tri-Lists nehmen.

    das konzept des indexings erlaubt allerdings, ziemlich wahllos im grafikspeicher rumzuspringen - was der performance erheblichen schaden zufuegen kann.
    man muss sich also auch ueber eine sinnvolle sortierung des indexbuffers gedanken machen.



  • hustbaer schrieb:

    Klar sind es auch 2 Index-Werte mehr pro Dreieck, bloss ein Index ist 4 Byte

    Ich glaub spaetestens danach hab ich aufgehoert den restlichen Unsinn zu lesen... f'`8k

    Bye, TGGC (Das Eine, welches ist.)



  • Trianglestrip ist das schnellste was gibt. Sofern Man seine Daten so organisieren kann.



  • Ja klar wenn ihr meint.
    @TGGC: was bitte ist daran Unsinn -- ich meine wenn dus nichtmal gelesen hast? Ok, toll, man kann 2 Byte pro Index verwenden, war mein Fehler, also 2 oder 4 Byte. Der Rest ist trotzdem kein Unsinn, Tri-Strips bringen bei Verwendung von Index-Buffern kaum einen Vorteil.



  • Jetzt kann man ja aber sowohl eine Triangle List als auch ein Triangle Strip indizieren... 😮



  • Hallo ihr Papnasen,

    Trianglestrip mit glDrawArrays , nix Indexbuffer und indizieren .

    Schon mal ausprobiert??



  • Hey!

    So habe ich es jetzt gemacht: (Ohne Index-Buffer)

    http://krautland.net/primitives.jpg = http://krautland.net/primitives2.JPG

    Geht es vielleicht noch einfacher? Denn ohne diesen degenerierten(?) Dreiecken erscheint nochmals eine Diagonale durch jede Reihe.

    Und warum muss ich 30 Primitives angeben? Ich zähle nur 28...

    MfG



  • 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 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.



  • 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...


Anmelden zum Antworten