Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 12:46

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 16 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: Sa Nov 26, 2016 15:39 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
In diesem Artikel hat einer der Entwickler von Granny(eine sehr gute Animations Middleware) sich mit Mesh optimierung beschäftigt und das Ergebnis hat meine aktuelles Wissen outdated.
Es ist schneller die Triangles ohne Indices nach cache zu sortieren als Triangle Stripes.
Indices sind auch nicht sehr hilfreich.
Triangle Stripes benötigen je nach komplexität mehrere Drawcalls, während Triangle-Listen immer nur einen brauchen.
Drawcalls sind der Langsamste Faktor auf modernen Grafikkarten und deswegen hat man mit OpenGL 4-4.5 und DX12 fast ausschliesslich diesen gewidtmet.
Die Umsortierung der Vertices für Cachezugriff lässt auch die bessere Cacheeffizienz, die Triangle-Stripes vom Design her mit bringen keinen Vorteil mehr übrig.
Der Nachteil ist, dass eine Triangle-Liste mehr Speicher benötigt als Triangle-Stripes(bis zu ~33% weniger VRam).
Dies ist aber nur beim kopieren über den Bus ein Performance Problem und das passiert eher selten.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Nov 26, 2016 20:17 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
TAK2004 hat geschrieben:
Der Nachteil ist, dass eine Triangle-Liste mehr Speicher benötigt als Triangle-Stripes(bis zu ~33% weniger VRam).

Hat man bei Stripes im Extremfall nicht sogar 66% weniger Speicherbedarf?
Man braucht ja ab dem zweiten Triangle im Stripe nur einen Vertex.

Ich bin leider nicht wirklich vertraut mit der Thematik, mich würde aber interessieren in wie weit man für den Cache theoretisch optimieren kann.
Bei Stripes erbt ja das nächste Dreieck immer 2 Vertices des vorigen Dreiecks.

Wenn man sich jetzt ein quadratisches Mesh vorstellt und die Quads in Tris aufteilt, hat man im inneren des Mesh immer 6 Tris, die sich ein Vertex teilen.
Das heisst, dass wenn man jetzt ein Chunk nimmt und es irgendwie schafft, dass die Verts alle im Cache sind, die die Tris grade brauchen,
bräuchte man fast 6 mal weniger den Vert berechnen! Zumindest, wenn man den Chunk als groß genug annimmt... Wow...
Ich konnte aus den Zahlen jetzt leider nix rausfinden in die Richtung, aber weißt Du zufällig um welchen Faktor man ca. schneller sein kann, als wenn man jeden Vert explizit berechnet? Und um wieviel so ein Cacheoptimierter Algo ist, als reine Stripes?
Nach der Abschätzung könnte es ja fast 3 mal so schnell sein...Was ich aber nicht glaube, dass man es annähernd hinkrigt.
Hängt der optimale Algorithmus denn nicht auch stark von der Cachesize ab?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Nov 27, 2016 09:43 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Wiedermal falsch, sorry.
Bei Stripes werden fast alle Vertices (außer denen ganz am Anfang und Schluss)von jeweils drei aufeinanderfolgenden Dreiecken geteilt.
Schätze daher, dass für eine Cacheoptimierung via dieser besagten Listen der Preformancegain kleiner 2 sein muss.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Nov 29, 2016 11:33 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Nicht vergessen, dass du entweder Indices oder mehrere Draw-Calls benötigt, bzw. auch Treiber support für degenerierte Triangle-Stripes benötigst(nicht im Standard), sonnst brauchst du sowieso mehrere Drawcalls.
Triangle-List braucht immer nur einen Drawcall.

Wir haben seit ner weile in GPUs und CPUs prefetch mechanismen, welche schon die nächsten Daten aus dem Speicher anfordern, obwohl wir die noch garnicht brauchen.
Wenn man die Daten Cache optimiert, dann liegen die Linear im Speicher und damit gibt es nur cache misses, wenn unsere Berechnung schneller ist als das laden von Daten.
Der Vorteil von triangle stripes wird also schon dadurch aufgehoben, dass die Vertexdaten Linear sortiert werden und prefetch so die Daten schon in den Cache lädt, bevor der Zugriff passiert.
Der Cache Algorithmus geht dann noch ein weiteren Schritt und versucht soviele Vertexzugriffe wie möglich in einer Cacheline unter zu bringen, damit auch schnelle Berechnungen kein Cache-Miss auslösen.

Die AMD und NV Treiber starten mehrere Threads und geben die OpenGL Befehle in diese
Ich vermute, dass die für jeden Kern ein Input Thread nutzen, da ich im VS Debugger für mein 8Kern 8 zusätzliche Treiber-Threads und für mein 4Kern 4 zusätzliche Treiber-Threads sehe und bei OpenGL Breakpoints auch in diesen anhält.
Die API ist laut Spec nicht multithreading fähig, man kann aber mit einem w/xglmakecurrent call ohne fehler von einem anderen Thread aus Opengl Befehle ausführen aber muss halt sicherstellen, dass nie von 2 oder mehr Threads zwischen makecurrent und dem letzten OpenGL call ein anderer das gleiche macht.
Wenn man es wirklich so gelöst hat, braucht man die Queues, für jeden Kern nicht mit Mutex, Atomics oder ähnlichesn sichern, weil der Thread, der die OpenGL Befehle enqueued nie zur gleichen Zeit auf den Kern ausgeführt werden kann, wie der Treiber Thread auf den gleichen Kern den input processed.
Makecurrent würde dann ledeglich ein Indikator für die richtige Queue setzen müssen und die Befehle hämmern in die Queue, die der Indikator angibt.

Je mehr Draw-Calls, des so wahrscheinlicher sind Thread switches und die erhöhen dann entsprechend die gesammtkosten für ein Frame.
Reduziert man die Anzahl an Drawcalls so sehr, dass eine Zeitscheibe vom OS ausreicht, dann hat man auch nur ein Switch und die Kosten nur einmal(weniger geht ned).
Im Artikel schreibt er, dass die in ihren Game gleiche oder leicht bessere Performance erreicht haben aber andere Entwickler auch teilweise schlechtere Ergebnisse hatten.

Windows hat maximale Zeitscheiben zwischen 10-16ms(je nach OS Version), sobald aber ein Systemcall oder ein thread warten Aufruf kommt switcht der Sheduler auf ein anderen Thread und wir bekommen entsprechend die penalties von dem OpenGL Threading Konzept oben drauf.
Daher wird in Engine Architektur und diversen Präsentationen immer ein konzentrierter Processing Block über mehrere Kerne und anschliessend erst ein konzentrierter OpenGL call block empfohlen.
So kann nur die maximale Zeitscheiben limitierung während OpenGL Befehlen greifen.
Man sollte auch immer ein glFlush ausführen, dann weitere Berechnungen für was auch immer machen und dann erst glSwapBuffer, weil das Flush die Befehle übergibt, der Treiber-Thread arbeitet, zurück gibt, wir dann unsere Berechnungen machen und dann bei SwapBuffer hoffentlich schon die fertigen Daten auf der GPU haben.

Ich hätte gerne mal das Cache Algo auf dem Game von meiner letzten Firma getestet, da hätte man den Perfekten Testkandidat gehabt, da wir sehr detailierte Terrains mit triangle-stripes gerendert haben.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Nov 29, 2016 20:51 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
TAK2004 hat geschrieben:
Nicht vergessen, dass du entweder Indices oder mehrere Draw-Calls benötigt, bzw. auch Treiber support für degenerierte Triangle-Stripes benötigst(nicht im Standard), sonnst brauchst du sowieso mehrere Drawcalls.
Woher hast du die Information, dass degenerierte Dreiecke vom OpenGL-Standard nicht vorgesehen sind? Habe gerade mal im Web und der Spec gesucht, konnte aber nichts dergleichen finden. Meines Wissens ist es erlaubt, mittels glDrawArrays und verwandten Funktionen GL_TRIANGLES und GL_TRIANGLE_STRIPs zu rendern. bei denen beliebig viele aufeinander folgende Vertices identisch sind. Außerdem darf man afaik mittels glDrawElements usw. GL_TRIANGLES und GL_TRIANGLE_STRIP rendern, wenn beliebig viele aufeinander folgende Indices gleich sind, was ja zu degenerierten Dreiecken führt. Das ist eigentlich der übliche Weg, mehrere TriangleStrips in einem Rutsch zu rendern, wenn Primitive Restart nicht unterstützt wird (GL < 3.1). Korrigiere mich, wenn ich falsch liege.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Nov 30, 2016 17:50 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
glAwesome hat geschrieben:
Woher hast du die Information, dass degenerierte Dreiecke vom OpenGL-Standard nicht vorgesehen sind? Habe gerade mal im Web und der Spec gesucht, konnte aber nichts dergleichen finden. Meines Wissens ist es erlaubt, mittels glDrawArrays und verwandten Funktionen GL_TRIANGLES und GL_TRIANGLE_STRIPs zu rendern. bei denen beliebig viele aufeinander folgende Vertices identisch sind.

Das mein ich damit, dass es nicht explizit erlaubt ist, wenn einer der Treiberhersteller sich penibel an die Specs hält, würde es dort nicht gehen.

Erst restart ermöglicht das garantiert, wie schon erwähnt. Ab da kann man auch das Wireframe korrekt anzeigen.
Denn das triangle wäre degeneriert und fliegt aus der pipeline aber die Linie ist valide und wird gerendert.

Ein Problem damit ist, dass sich degenerierte Triangles und cache Effizienz im Weg stehen.
Bei einem Terrain, was ich quasi Zeilenweise mit einem Stripe render, geht das recht gut, man braucht nur eines pro Zeile aber bei normalen Meshes für Häuse, Character werden es immer mehr.
Diese sind Cache ineffizient und haben sogar ein höheren Aufwand in der Pipeline, da mehr Dreiecke durch die Shader-Unit müssen.
Trianglestripes werden ja in triangle aufgeteilt, bevor sie in die Shader-Units gehen und dort passiert ja die eigentliche Arbeit.
Der Vorteil lag also vor den Shader-Units, dass das übergeben von 3 Vertices dank cache bzw. in dem Fall bestimmt auch schon register effizienter waren aber müssen dafür halt mehr 3Ecke verarbeiten.
Trianglelisten haben die degenerierten 3Ecke nicht und können aber so cache effizient sein, weil es ja prefetch gibt und somit die höhere cacheineffizienz durch mehr Daten kompensieren.
Wenn man nun die Trianglelist cache optimiert, dann ist die Triangleliste theoretisch um den Teil schneller, die die Degenerierten Dreiecke noch in der Shader-Unit verbrauchen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Nov 08, 2017 22:29 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Bin gerade nochmal auf den Artikel gestoßen, und da ist mir etwas aufgefallen.

TAK2004 hat geschrieben:
Es ist schneller die Triangles ohne Indices nach cache zu sortieren als Triangle Stripes.
Indices sind auch nicht sehr hilfreich.


Aber in dem Atrikel steht ganz am Anfang:
"This paper introduces an algorithm for optimising an indexed triangle list to be friendly to a wide variety of hardware vertex caches of unknown size."

Das hat mich auf die Frage gebracht: Wie kann die GPU überhaupt den Vertex-Cache ausnutzen ohne Indizes? Wenn man Dreiecke immer wieder mit den redundanten Vertices reinschiebt, wie erkennt die GPU denn dann, dass sie diese 3 Floats gerade schon mal gehabt hat? Sie müsste doch dann relativ aufwändig nach diesem identischen 3er Vektor suchen, oder? (je nachdem auch 2er-Vektor oder wie auch immer)

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Nov 09, 2017 02:55 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Ich glaube, ich bin heute etwas neben der Spur und ich bringe hier zwei verschiedene Sachen durcheinander.
Jetzt ist mir doch wieder klar, dass eine Sortierung der Dreiecke, ob nun indexed oder nicht von Vorteil ist, da die Daten, die im Cache dann vorliegen mit höherer Wahrscheinlichkeit auch die folgenden Vertices beinhalten.
Allerdings gibt es doch auch noch den Fall, dass ein Vertex, der mehrfach kurz hintereinander auftaucht, via Indizes nur einmal berechnet werden muss, und dies fällt doch bei non-indexed Trianglelisten weg, oder?
Hab ich das richtig verstanden, dass letzerer Cachevorteil dann nachrangig ist, und es tatsächlich performanter ist, die Dreiecke komplett ohne Indices zu zeichnen, als bspw. über glDrawArrays statt glDrawElements, sofern sie richtig sortiert sind?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Nov 09, 2017 07:22 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ja, deine Vermutung ist korrekt. Es kommt auf den Input an, ob indices effizienter sind. Man muss ja bedenken, dass die Indices auch in den Cache geladen werden müssen und somit weniger Platz für Vertices ist.
Sicher kann man nur sein, wenn man beides testet und das bessere wählt. Man kann wohl grobe Prognosen machen aber Grafikkarten können auch precaching/vorraus schauen. Also da mehrere indices im Cache sind kann man auch mehrere vertices erkennen und schon Anfordern, während die aktuellen verarbeitet werden. Daher ist das alles relative schwammig und schwer vorher zu sagen, ob es schneller oder langsamer ist.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Nov 09, 2017 13:38 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Was mir dazu gerade noch eingefallen ist:
Es kommt wohl auch darauf an, wie rechenintensiv der Vertexshader ist, und inwieweit die Bandbreite der Bottleneck ist.

Wenn ich z.B. einen sehr rechenintensiven Vertexshader habe, denke ich wird indexed immer gewinnen, da man die Anzahl der Vertexberechnungen deutlich reduzieren kann, was bei non-indexed nicht möglich ist. Sofern ich das richtig verstanden habe.

Also kann man dann sagen, dass der Post T&L Cache nur bei indexed Triangles und Stripes/Fans verwendet werden kann?
Und dass der Pre T&L Cache hingegen bei sortierten non-indexed Trianglelisten sogar besser ausgenutzt werden kann als bei indexed Trianglelisten und Stripes?


EDIT: Der Text in rot mach glaub ich doch kein Sinn.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Zuletzt geändert von Vinz am Fr Nov 10, 2017 22:16, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Nov 10, 2017 21:50 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Noch ein bisschen mehr Senf will ich dazugeben.
Meiner Erfahrung nach fällt der Vertexshader alleine meist deutlich weniger ins Gewicht als der Teil, der danach kommt, und zwar Triangulation, Tiefenoperationen und der Pixelshader.

Das gilt aber nur, wenn ein beträchtlicher Teil der Geometrie innerhalb der Clippingplanes landet.
Predepthpass kann hier wahre Wunder wirken bei komplexer Geometie.

Von so einer Vertexcacheoptimierung darf man sich glaub ich daher nur dann viel erwarten, wenn man viel Geometrie hat, die zu einem großen Teil gar nicht im Bild ist, oder viel mehr Details hat als bei ihrer Entfernung erkennbar wären und somit von vorne herein überflüssig ist.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Nov 10, 2017 21:53 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Oder auch, wenn der Vertexshader übermäßig rechenintesiv ist oder gar nicht er rasterisiert wird.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Nov 10, 2017 22:13 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Sorry, aber ich muss nochmal.

Ich habe es nicht ausprobiert, aber ich glaube, es macht gar keinen Sinn, Triangles ohne Indices überhaupt irgendwie zu sortieren.

Denn ohne Indices ist der Zugriff doch immer linear, es kann also keine Cachemisses geben. :0
Und soweit ich das gelesen habe, gibt es keinen Benefit vom Post-Vertex-Cache bei Trianglelisten ohne Indices.

Hab mir den Artikel oben auch nochmal kurz angeschaut, und über die non-indexed Trianglelisten nur Folgendes gefunden:
" If this hardware is still a specific target for some reason (for example, some older and portable consoles still use non-indexed rendering), it is better to run one of the algorithms custom-designed for efficient stripping of non-indexed meshes."

Also Strips, wenn non-indexed.

Wenn ich jetzt nicht völlig daneben gehauen habe, ist das was ganz oben steht falsch, und das Sortieren macht nur bei indexed Trianglelisten Sinn, und die non-indexed kann man getrost vergessen, wenn man sich nicht auf Uralthardware befindet oder lieber Strips nimmt.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Nov 10, 2017 22:19 
Offline
DGL Member

Registriert: Fr Mai 11, 2012 13:25
Beiträge: 229
Programmiersprache: c++, c, JavaScript
Vinz hat geschrieben:
Sorry, aber ich muss nochmal.

Ich habe es nicht ausprobiert, aber ich glaube, es macht gar keinen Sinn, Triangles ohne Indices überhaupt irgendwie zu sortieren.



Kann man so auch nicht sagen. Es kann z.B. Sinn machen bei Alphablending, was ich sagen wollte ist, dass es keinen Sinn macht für Cacheoptimierung.

Bevor ich hier zuviel Schmarrn erzähl, klär doch bitte mal jemand das Ganze hier auf.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Nov 12, 2017 15:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Also als erste würde ich sagen, mein erster Post ist verwirrend, da nach so langer Zeit selbst ich grübeln musste, was da eigentlich steht.
Also das Paper sagt, dass eine sortierte Indices List schneller ist als Triangle Stripes.
Auf moderner Hardware sind Drawcalls ein großer Faktor und NV/AMD/Intel empfehlen weniger Drawcalls und dafür komplexere/größere. Also ein riesen Triangle List Drawcall ist besser als 10 Triangle Stripe Drawcalls.
Triangle Listen mit Indices sind schneller als ohne, solange die Anzahl der Triangles nicht zu klein ist.
Ob man Vertices in einzelne Buffer oder interleave in einen verpackt hängt vom Shader ab.

Du musst das große ganze betrachten und es in einzelne Stages zerlegen.
Vertex processing
*Vertex Caches
*Vertices per Cacheline
Viewport Culling
Geometry Shader
*erzeugte Geometry
Fragment Shader
*Texel cache
*Texel per Cacheline
*decoding Aufwand von Texel
*overdraw
*Auflösung

Man kann es noch weiter aufdröseln aber das ist erstmal ein grober Einblick.
Die Wahl ob du Vertices mit Position, UV, UV2, Weights,... zusammen packst oder in getrennten Buffern führst und dann noch ein Index Buffer nutzt oder nicht, bringt viele Kombinationen und Auswirkungen.
Einzelne Buffer machen Sinn, wenn du den einen oder anderen zur Laufzeit änderst, sonnst ist interleaved besser, da die Daten sehr kompakt im Cache liegen und weniger kopiert werden muss.
Je kleiner ein Vertex des so mehr passt in den Cache und des so schneller wird es. Half floats sind also sehr praktisch, unter umständen kann es auch sinnvoll sein errechenbare Daten weg zu lassen.
Man kann z.B. Normals in 2 floats speichern und die 3. Komponente errechnen, wenn diese schneller ist als der Zeitverlust durch Cache-Misses und längeren Kopierzeiten.
Bei Normal-Maps ist das common practice.

Wann ist Vertex-Cacheoptimierung wichtig ?
Häufig sind die Fragmentshader langsamer als die Vertexshader aber die Anzahl an Aufrufen variiert beim Fragmentshader aber ist beim Vertexshader fix.
Also wenn ich ein Model mit 20k Triangles und 10k Vertices hab, dann laufen alle 10k Vertices durch, eventuell sogar mehrfach, je nachdem wie effizient der Vertex-Cache ausgenutzt wird.
Dann werden Triangles, die ausserhalb des Viewports liegen nicht weiter verarbeitet aber alles was drin liegt.
Fragment-Shader sind Auflösung- und Positions-Abhängig, in ihren Aufrufen. Also wenn das Model so weit weg ist, dass es noch 3 Pixel ein nimmt, ist der Fragment-Shader entsprechend nur für die Pixel und Subpixel aktive.
LOD und Batchrendering kann dir hier helfen.

Wann ist eine Triangleliste ohne Indices von Vorteil ?
Ganz einfach, wenn man nur eine Hand voll Triangles hat, die ohne Probleme in den Vertex-Cache passen z.B. Billboards, Particle, UI-Elemente oder Decals.
Oder noch konkreter, wenn der Drawcall nicht mehr Vertices braucht als in den Cache passen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 16 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 25 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.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.075s | 17 Queries | GZIP : On ]