es wird ja immer überall wenn es um Performance optimierungs geschichten geht erwähnt das man Triangle Strips bevorzugen sollte gegenüber einzelnen Triangles. (Gut heutzutage wohl egal, alles wo das erwähnt wird sind ältere Dokumente - aber egal)
Ist ja im prinzip auch einleuchtend, allerdings... man kann doch garnicht jede geometrie als TriangleStrip darstellen..? Ich seh es als ziemlichen overhead an mein Objekt intern in mehrere TriangleStrips aufzusplitten und dann jeden Strip einzeln zu zeichnen.. da ist es doch weit performanter einfach alles auf einen schlag zu zeichnen als Triangles, oder nicht?
Oder liege ich falsch und man kann doch irgendwie jede Geometrie auch als TriangleStrip rendern..? Aber mir fällt schon bei ner simplen plane nicht ein wie ich die mit einem einzigen Strip machen sollte - gibt eben immer am ende von einer bahn ein problem zur nächsten zu kommen.
Es ist möglich zwei beliebige TriangleStrips durch einige degenerierte Dreiecke zu verbinden. Ich glaube man musste da nur den letzten Punkt des ersten Strips sowie den ersten Punkt des zweiten Strips zweimal einbauen. Das ergibt dann insgesamt vier unsichtbare Dreiecke, da diese jeweils Fläche == 0 haben.
Aber du hast Recht, es ist kompliziert ein normales Mesh in TriangleStrips zu konvertieren. Der Nutzen gegenüber anderen Techniken wie z.B. Indices ist gering. Indices, auch bekannt unter dem Namen "Shared Vertex", sind wesentlich einfacher anzuwenden und reduzieren ebenso den Speicherbedarf.
Edit: Mit den Formeln im Mesh-Artikel kannst du dir genau ausrechnen wie groß die Ersparnis bei einem Mesh mit N Vertices ist. Verwendest du Indices (32bit Integer) sowie nur die Vertex-Position (9x32bit float) sparst du bereits 50% des Speichers ein. Wenn du auch noch Normalen und Texturkoordinaten hast ist die Ersparnis noch wesentlich größer. Im Durchschnitt wird ein Vertex von 6 Dreiecken genutzt.
Hey Aya, du kannst doch bestimmt auch Java coden, oder? Dann schreib doch mal einen kleinen Benchmark für unseren DGL Benchmark.
Java kann ich, ja... (http://www.cginfo.eu/ war das Projekt wofür ich Java gelernt hab) Hab allerdings nur einmal ganz kurz was mit JOGL gemacht, und generell schon wieder so lange kein Java entwickelt das ich mich da erstmal wieder ein bisschen einarbeiten müßte..
Wenn es den Benchmark schon für C++ gäbe.. dann...
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Die Spec für den Benchmark steht im Wiki unter DGL Benchmark. Ich fände es gut wenn sich jemand freiwillig melden würde, den auch für z.B. C++ umzusetzen.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Die Spec für den Benchmark steht im Wiki unter DGL Benchmark. Ich fände es gut wenn sich jemand freiwillig melden würde, den auch für z.B. C++ umzusetzen.
hehe, ich sag's aber mal ganz ehrlich: Ich hasse es dinge zu Programmieren die mich perönlich im moment nicht Interessieren, das tu ich bei der Arbeit oft genug schon ^^ In der wenigen verbleibenden Freizeit arbeite ich lieber an meinen eigenen Projekten..
Nich falsch verstehen ^^ Aber wollte nicht drum rum reden warum ich den Benchmark nich schreiben kann/mag..
Registriert: Di Dez 27, 2005 12:44 Beiträge: 393 Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo,
mit Triangle Strips kann man glaub ich fast ein Drittel der zu berechnenden Vertices einsparen ( wenn man keine Indizes benutzt ).
Natürlich kann man nicht jede Geometrie mit nur einem einzelnen Strip zeichnen, man muß meistens mehrere Strips verwenden. Will man sein Mesh in Triangle-Strips zerlegen, hängt jeder Strip davon ab, in welcher Reihenfolge man die Vertices im Startdreieck wählt. Ist die Reihenfolge festgelegt, ist der entstehende Strip eindeutig bestimmt ( sofern jede Kante maximal 2 benachbarte Dreiecke hat ). Da es in einem Dreieck 6 verschiedene mögliche Vertexreihenfolgen gibt, sind 3 maximal zusammenhängende Triangle Strips pro Dreieck möglich. Ein interessantes Problem ist es eine optimale Triangle-Strip-Zerlegung zu finden ( also eine mit der geringsten Stripanzahl ), könnte möglicherweise ein NP-Problem sein
Problematisch ist die Technik, wenn man Octrees benutzt oder verschiedene Texturen im Mesh hat. In dem Fall bekommt man nur sehr kurze Strips, und die Einsparungen sind nur minimal.
Viele Grüße dj3hut1
_________________ Wenn Gauß heute lebte, wäre er ein Hacker. Peter Sarnak, Professor an der Princeton University
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Das Thema haben wir nicht zum ersten mal ^^ Also kann ich die Antwort schneller schreiben. Trianglestripes sind wesentlich schneller, da man 1)VRAM spart 2)Bus bandbreite beim laden in das VBO 3)mit weniger Speicherzugriffen mehr Vertice verarbeitet werden können 4)GPU Caching besser greift. Trianglestripes können durch Tools, von z.B. AMD und NVidia aus normalen Trianglelisten erstellen lassen. Dabei werden aber gleich noch ein Z-Ordering und TextureID ordering gemacht. Es macht mitlerweile auch sinn Texturearrays(ab OGL3) zu verwenden, damit man größere Stripes rendern kann, Der Unterschied ist mehr als Spürbar und je komplexer die Models, des so mehr fällt es ins Gewicht.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Es ist jetzt nicht mein Thread aber ich denke es gehört dazu, wenn ich jetzt einen Octree einbaue sind Trianglestrips aber nichtmehr performant, weil ich sie in kleine Stücke schneiden muss, dadurch erhöht sich die Zahl der Aufrufe doch, oder nicht? Außerdem kann ich dann nicht wie bei Zb. Dreiecken einen Node mit einem Aufruf rendern, sondern muss für jeden Strip einzeln rendern.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Du zerlegst dein Octree ja nicht so klein, sonnst bricht dir die Anzahl der Binding und Drawcalls alleine schon das Genick. Eigentlich sollte man den Designer die Möglichkeit geben, zu entscheiden wie das Octree arbeiten soll, denn dieser weiß ob das Level zu groß, klein, zuviele Polys oder zuviele Objekte auf ein Node hat. Es macht oft mehr Sinn einfach viel zu viele Triangle zu rendern, als es zu zerlegen und die einzelnen Teile zu verarbeiten, wenn man z.B. ein Terrain hat. Bei Innenräume ist es abhängig von der Komplexität, da z.B. hinter einer Wand viele Polygonlastige Objekte sein können, die erstmal verarbeitet werden müssen, um dann raus zu fliegen. In OpenGL3 sind die Bindings und Drawcalls das Bottleneck, dann Füllrate und dann der Triangledurchsatz.
Edit: Vor OpenGL3 ist die Füllrate das Bottleneck und dann erst Bindigns/Drawcalls und Triangledurchsatz.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
OpenGL3 fähige Hardware hat weniger Probleme mit der Füllrate, da die Pixelshader Units ordentlich nachgerüstet wurden. Mit OpenGL3 braucht man ein sehr großen Teil der Zeit für das binden/unbinden und aufrufen von Zeichenbefehlen und die sind so groß, dass bei komplexen Szenen diese mehr Zeit fressen als das Rendern selber. Du musst bedenken, dass du nun immer einen Shader brauchst, in der regel mehrere Texturen, VBO, FBO benutzt. Daran wird aber wohl für die kommende OpenGL Version gearbeitet, das ist aktuell die größte Forderung der OpenGL Entwickler auf dem Offiziellen OpenGL Forum. Nvidia hat eine extension entwickelt, welche den Pointer auf das Objekt, im VRAM, zurück liefern kann und damit benötigt man keine glBind/glUnbind befehle mehr, da man den Shadern die Pointer direkt übergeben kann, statt eine IndexID wie aktuell. Man muss dann allerdings einiges an Code entfernen und alle bleibenden Funktionen um die Pointer Var erweitern. Ich schätze mal, wenn man es bringt wird man allerdings gleich OpenGL5 daraus machen, da der API Unterschied zu drastisch ist. Man musst ja auch nach OpenGL3.3 gleich 4 bringen, da die Änderungen in der Pipeline zu große waren(tesselierungs unit und so weiter).
Wo ich mich echt freue, dass der Konkurrenzkampf zwischen AMD und Nvidia zu gunsten der Entwickler ausgetragen wird. Wir bekommen immer mehr nützliche Features und immer schnellere Hardware.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.