Hi,

ich stelle mein Flipbook ja grad auf C++ um. Da hier alles in 2D ist verwende ich einfach den Intermediate Mode um quads mit texturen im Ortho-Mode zu zeichnen, wollte das aber im zuge der umstellung jetzt mal auf VBOs umbasteln.

Grundsätzlich ist das kein problem, nur ich hatte eben die idee, statt für jedes Quad ein VBO zu erstellen (oder alle umständlich in einem uz verwalten) würde es sich doch anbieten wenn ich mir einmal ein Quad-VBO erstelle und dann bei jedem aufruf nur die vertex-positionen in diesem VBO ändere, oder?

Also ich habe einen einzigen VBO mit vier vertex'n drin und passe die für jedes quad neu an.

Spricht da was dagegen?
So erspare ich mir die masse an (sehr kleinen) VBOs und kann nach wie vor (wie im intermediate mode) sehr leicht Quads zeichnen..

Aya~

1. Eine sehr gute Frage, wenn später wirklich nur noch VBOs genutzt werden, und man braucht nur 3 Quads oder so, was dann hab ich mich auch schon oft gefragt^^

Aber was auf jedenfall dagegenspricht, dass ein so kleines VBO unperfomant ist. Ich glaube erst ab 10000 Vetices oder so, wird das wirklich erst brauchbar. Hatte ich mal vernommen hier.
Was wohl besser wäre ist, alle Quads und irgendwelche anderen Objekte in ein VBO packen, eventuell auch alles, und dann mit gldrawrangeelements und einem offset arbeiten, das macht sich ganz gut eigentlich und vermeidet auch ein so kleines VBo.

Aber die Profis haben da sicher noch was zu zu sagen *duck*
mfg ^^

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x

Mit gldrawrangeelements ist eine möglichkeit kleine VBOs zusammen zu packen, aber bei Quads reit in der regel ein einziges quad aus. Alle anderen lassen sich leicht durch transformation (im Vertexshader) erzeugen.

EInen großen performance unterschied sollte es nicht geben, da hier meistends eher der pixelshader limitiert.

_________________
Lumina plattform unabhängige GLSL IDE

Genauso mache ich es in meiner GUI. Alle Formen sitzen (derzeit noch als Displaylisten) fix im Grafikkartenspeicher. Die Originalgröße aller dieser Formen (Vierecke, Sechsecke, Kreise...) passt in den Bereich [-1 .. +1] und sie werden nur geshiftet und gescaled. In Windows XP komme ich jetzt damit performancemäßig schon ziemlich nah an die normale Windows API heran. Mal sehen, wie es in Linux ist. Mit dem X11 Server liefere ich mir grade ein Gefecht.

Da wollt ich eigentlich noch was zu gesagt haben. Habs aber verpennt.

In meiner Fontbibliothek arbeite ich aktuell noch ohne VBOs. Werde ich aber ändern. Nur in diesem Zuge hatte ich mal was umgestellt. Zu erst hatte ich die Position der Quads mit glTranslate festgelegt. Aber da dass nicht sonderlich VBO Kompatibel ist hatte ich es auf absolute Positionen umgerechnet. Das Ergebniss hatte mich selber auch überrascht, denn obwohl ich die Position auf der CPU berechnet hatte war es schneller. Ich denke aber das liegt daran, dass glTranslate erst mal mit Floats arbeitet und somit vermutlich die FPU angesprochen werden muss und, dass 2 Integeradditionen schon alleine schneller sind als ein Funktionsaufruf an sich. Um eine Hausmarke zu nennen. Die Framerate von meinem BlockLoop beispiel ging von 800 auch 1000 fps hoch.

Displaylisten hatte ich zwischenzeitlich auch mal getestet. Aber sehr schnell wieder verworfen. Denn dadurch ging die fps von früher 800 auf 600 runter. Die Position hatte ich auch mit glTranslate bestimmt. Den Grund dafür sehen ich darin, dass moderne Treiber immer mit VBOs arbeiten und entsprechend muss für ein einzelnes Quad immer ein VBO gebunden, eingestellt und aktiviert werden. Da wird vermutlich der Verwaltungsaufwand der Renderzeit überlegen.

Wenn man aber selber kontrolliert, wann das VBO gebunden wird und wann man etwas zeichnen, dann wird man sich wohl einiges an Verwaltungsaufwand ersparen können.

Aber VBOs sind auch für das Streamen von Vertexdaten geeignet. Und zwar muss man beim Erstellen angeben, dass der Verwendungszweck Stream/Dynamic ist. Und anschließend kann man diesen write only mappen und seine Daten in den gemappten Bereich schreiben. Wenn man diesen entmappt und zeichnen, dann kann der Treiber entscheiden wann er die Daten wirklich hochlädt und zeichnet (wenn die karte zu tun hat). Das ganze ist dann asynchron. Allerdings hatte ich schon mal mit was mit einem VBO/PBO rumgespielt und musst leider feststellen, dass das mappen mitunter einiges an Zeit beansprucht. Allerings hatte ich damit auch wirklich nur ganz kurz rumgespielt.

Also das addieren von 2 int und 2 floats ist schon unterschiedlich, unzwar berechnet er die 2 floats schneller
Die CPU's haben schon seit längerem wesentlich mehr Gleitkomma einheiten als normale einheiten für Ganzzahlige Operationen. Dadurch sind float operationen schneller als integer auf CPU's wie den AMD X² oder Core2Duo.
Das glTranslate ist ein massiver overhead, findet man auch in einigen optimierungs FAQ.
Oft verwendet man das translate mit 3 komponenten, was also schon mal 3 stack pushes sind, dann geht das an den treiber, der muss die statemachine entsprechend anpassen. Man bracht auch für jedes Zeichen ein Translate.
Dann ist noch die Frage, ob wirklich so optimiert, dass er nur x,y,z auf die Transformationsmatrix addiert oder das wirklich über den Mathematischen weg mit (Identity Matrix+Transformationsvektor)*Transformationsmatrix.
Wenn du die vorberechnest, dann machst du das auch nur einmal, wenn du die transformationen per displaylist regelst, machst du es immer wieder(sinnlos rechnung).

Vorberechnungen sind immer schneller, man braucht nur oft mehr Speicherplatz.
Es gibt allerdings auch ausnahmen, wie z.B. ein lustiger Sinus/Cosinus trick mit floatingpoint, der es erlaubt eine lookuptable ohne lookuptable zu nutzen xD.

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

Projekte: https://github.com/tak2004

Alles in allem kommen wir zu dem Schluß, dass die performanteste Möglichkeit, ein Quad zu zeichnen, die Folgende ist:
VBO+VertexShader (das ist der Teil, der nur einmal erzeugt wird) +Transformationsmatrix (diese wird immer wieder neu erzeugt).

Das hat mich nochnicht wirklich überzeugt.. das mag der sinnvollste weg sein wenn man ein fest definiertes quad hat und es nur via glRotate/gltranslate verschieben möchte.

Ich brauche aber viele verschieden geformte Quads (für jedes UI element halt eins).. und da denke ich mal ist es doch eher sinnvoll die daten im VBO ständig zu ändern statt alle 4 vertices via Shader zu transformieren..

Alternativ könnte man sich eine transformation Matrix berechnen die das Quad translated und skaliert, aber das würde a) nur bei rechteckigen quads gehen und b) bin ich mir da echt unsicher ob das dann noch schneller ist als wenn ich einfach die vertices ändere im VBO (zumal ich deren world Position sowieso schon weis).

Aya

Na, ich habe doch das gleiche Problem wie Du, oder?

Exzerpt aus meiner Unit GraphicSupport.pas:

Mit dieser kleinen Prozedur mache ich aus einem Quadrat dessen Punkte im Bereich [-1..+1] alle Rechtecke, die es gibt. Ich mache auch aus einem kleinen Kreis der die Bounding Box[-1..+1] nicht nur alle Kreise, die es gibt, sondern auch alle Ellipsen die es gibt. Ich kann rein theoretisch ALLE 2D Formen, die Dir einfallen in beliebige Bounding Boxen einschreiben. Daher sind nicht nur Schriften und Bilder, sondern auch 2D Formen grundsätzlich frei wählbar. Mit einer Scherung könnte man aus einem Viereck auch ein Trapez machen, das verwende ich aber nicht.

Für eine GUI, die nur mit Vierecken arbeitet, genügt daher ein VBO mit EINEM Quadrat.
Traude

Am schnellsten bist du mit einem VBO ohne Shader.
Du updatest einfach das VBO, wenn sich was ändert, ganz einfach und unkompliziert.
Die ganze sache ist trotz des öfteren Updates noch total performant, weil diese Updates an einer Hand abzählen kannst aber der Shader zig hundert male in der Sekunde durch rattert. Wann machst du ein VBO update? Wenn sich die Position oder größe eines Objektes verändert und wann ist das der Fall, in einem Fenster? Also bei meinen Widgets genau 1mal ,wenn ich create aufrufe und die werte setze. Natürlich gibt es immer ausnahmen aber die kann man total easy umschiffen.
Fall Nr.1 Das Popup Menu,DropDown Menu.
man kann hier über visible on/off arbeiten und sich veränderungen an den vertice sparen oder noch so stylische fades einbauen, ausrollen ist out und kostet massiv wartezeit oder man merkt den effekt ned, weil er zu kurz ist.

Fall Nr.2 Scrollbalken, darf ich vorstellen VBO nr.2 und problem gegessen.
Noch dazu braucht man nicht für jeden Scrollbalken nen neues VBO machen sondern nur eines und das kann man dann easy per scale und translate setzen(shader ist hier schon overpower).

Mehr Kompos fallen mir ned ein, wo sich was bewegt oder in der größe verändert.
Vieleicht noch bei einem Colorpicker, ein Dreieck was die Zielfarbe andeutet aber das ist das gleiche wie mit Nr.2.

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

Projekte: https://github.com/tak2004

Hi,

ja aber würde ich es so mache wie von dir vorgeschlagen würde das bedeuten das ich pro UI komponente mindestens eine VBO mit nur vier vertices drin hätte... und das erscheint mir unperformant..

Bzw wäre halt die frage was sinnvoller ist, viele kleine VBOs (für jedes UI eins) oder ein einziges Kleines welches von jedem UI element benutzt und einfach für jedes UI element neu geupdated wird... werd ich wohl einfach mal testen müßen.

Aya

WTF wer hat denn gesagt das du für jedes GUI Element ein VBO verwenden sollst ?
Du hast ein VBO für ein ganzes Formular, Dialog, wie du es auch immer nennst und dort sind alle Triangledaten drin.
Deine Komponenten haben nur noch start und count auf das vbo.

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

Projekte: https://github.com/tak2004

Umh.. kein grund gleich so auszurasten...


Das "problem" an der sache ist das ich auch viele Quads einfach so ausserhalb der UI (also normal im programm) zeichne und mir da einfach gern einen schönen standardweg machen würde.. wenn ich da für jedes Quad nen VBO + Start + Count (wobei der bei nem quad klar ist) speichere werden das u.U. viele daten die anfallen und alles nur unübersichtlich machen.

Daher meine idee halt einfach das VBO einfach als ImmediateMode zu missbrauchen = die daten im Quad-VBO einfach anpassen und das VBO updaten.. ich denke bei einem so kleinen VBO sollte das kein problem sein..

Aber ich werd es einfach ausprobieren wie sich das performance mäßig äussert.. ob ein großes besser ist als ein kleines das sich ständig ändert.

Aya

Ich bin nüde, hab nur 3h geschlafen und sehr gereizt. War heute früh zum Mitternachtsverkauf von WOW Addon und habe bis kurz vor 6 gezockt und 8:45Uhr hat der Wecker geklingelt. Aggro!!!

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

Projekte: https://github.com/tak2004

[ot]warst du direkt bei diesen "riesenfeiern hust" am europacenter oder wo die war? ich musste wegen meines cousins mit .. alles freaks!!! xD[/ot]

Zum Thema.. ihr sagt nen kleines vbo und dann immer updaten.. aber sonst sagt ihr doch, ein vbo bloß nicht zu klein machen, weil das probleme macht? o.O
ich meine die 4 punkte kann man doch echt in irgendeinen beliebigem vbo mit dranhängen und per offset anzeigen lassen? oder müsste dann immer das ganze vbo neu gemappt/streamt werden?

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x