TRIANGLE LIST oder STRIP?
-
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
-
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.
-
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...
-
Also trianglelists sind schneller, weil weniger vertices verwendet werden? Zwar mehr indices, aber das macht ja anscheinend nichts aus.
-
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.
