Hallo,
man bekommt häufig zu hören, dass drawArrays oder allgemein draw-Aufrufe viele Performanceverluste bedeuten. Aber, dass sie schon bei einer Menge von ca.250 Aufrufen lediglich 2-3 FPS auf dem Bildschirm zaubern, finde ich dann doch sehr merkwürdig. Erst ab unter 50 drawArrays-Aufrufen (oder auch drawElements) habe ich flüssige Bildersequenzen. Ich kann mir so auf dem ersten Blick nicht erklären, warum ein solches Ruckeln bei vergleichsweise so wenigen draws auftritt. Dies kann nichts anderes bedeuten, als dass ich etwas falsch mache. Ich skizzier mal kurz den Aufbau meines Programmes:

In meiner Szene befinden sich einige oder viele Elemente/Modelle. Jedes dieser Elemente wird durch ein Javascript-Objekt repräsentiert, das eine zeichnen-Methode besitzt. Nach dem initialisieren von VBOS, wird jedes Objekt mit Hilfe seiner zeichnen-Methode gezeichnet. Hier mal der Code von zeichnen():



Ich habe heraufgefunden, dass neben dem Hauptsündenbock drawArrays auch die Matrizenfunktionen extrem viel Rechenleistung beanspruchen. Woran genau das liegt (sprich, ob es an den Funtkionen oder Matrixoperationen), weiß ich nicht.

Hier mal ein paar Matrix-Funktionen (nach http://learningwebgl.com/blog/ )


Matrixoperationen basieren auf dem Matrizenframework: http://sylvester.jcoglan.com/


Ich wäre für jeden Tipp der Performancesteigerung sehr dankbar..denn ich muss schon manchmal mehr als 50 Objekte auf dem Bildschirm bringen. Die Objektstruktur brauche ich, weil einzelne Objekte z.B. im nachhinein auf einfach Art anders eingefärbt werden sollen oder es sollen Einzeltransformationen möglich sein (ein Objekt darf verschoben werden und der Rest der Szene nicht) etc..


Grüße

Ähm, du benutzt WebGL, also JavaScript. Da das ganze im Browser läuft ist das im Vergleich zu compiliertem C++ oder Delphi verdammt langsam.

Also wenn ich mir anschaue wie diese Sylvester-Lib implementiert ist wunder mich nicht das das langsam ist. Schauen wir uns z.B. die einfache Addition von zwei Vektoren an:



WTF? Z.B. werden da Arrays benutzt. In Java-Script sind Arrays unter Umständen (je nach Browser) keine richtgen Arrays sondern eigentlich eine Map die den Index auf den Wert abbildet. Der Index wird zuerst in einen String umgewandelt von dem ein Hashwert berechnet wird und dieser wird dann in einer Hashmap gesucht. Das hat zwar den Vorteil das man "alles" als Index benutzen kann ist aber auch im Vergleich verdammt lahm.
So wäre es doch viel einfacher:

Ich denke du bist gut beraten dir da selbst was zu implementieren. Alternativ schlage ich vor mein WGT als Grundlage zu benutzen. Das hat obendrein den Vorteil das GoogleWebToolkit den Code nochmal gezielt für jeden Browser optimiert.

Des weiteren solltest du überlegen ob du wirklich jedes Frame die Objekt-Matrix neu berechnen musst. Insbesondere für unbewegliche Objekte reicht es doch die Matrix einmal auszurechnen und dann nur noch mit der Camera/Projektion zu multiplizieren.

Dann scheinst du da mehrere VBOs für ein Objekt zu benutzen. Du kannst Position und Normalen auch in einen Buffer tun. Das spart dir langsame API-Aufrufe und oben drein muss sich die Grafikkarte die Daten nicht erst zusammensuchen.

Außerdem sehe ich da deinen gl.bindFramebuffer-Aufruf. Ist der notwendig. Ein Framebuffer-Wechsel ist langsam und ich weiß nicht ob die Funktion so schlau ist zu merken wenn "null" bereits gebunden ist.

_________________
Yeah!

Erstmal danke für die schnelle Antwort

Gut, ich mach mich auf die Suche nach etwas Schnellerem oder bastel mir was Einfaches.


Stimmt, werde ich so machen. Generell lässt sich sagen, dass sich das Matrizenproblem ganz gut bearbeiten lässt, jedoch nicht die drawArrays Angelegenheit.


Meinst du ein Interleaved-VBO? Derzeit beinhalten meine Objekte die Vertices und Normalen als Objektattribut (Array). Das bedeutet, dass ich aus diesen beiden Arrays ein drittes erstellen müsste um das Misch-VBO zu benutzen (ist ja kein Problem, wenn Javascript schnell auf Arrays operieren kann). Ich guck mal was es für Geschwindigkeitsvorteile mit sich bringt.


Das kommt auch weg oder in eine if-Abfrage..

JavaScript kann nicht sonderlich schnell auf Arrays arbeiten. Warum erstellst du den Buffer nicht von vornherein als Interleaved-Buffer? Nach meinen Experimenten habe ich festgestellt das es am schnellsten ist direkt Meshes aus JSON-Dateien zu laden, weil das der Browser nativ parsen kann.

_________________
Yeah!

Hi, ich habe mal nahezu alle hier genannten Vorschläge in die Tat umgesetzt und spüre einen deutlichen Performancegewinn. Besonders nach dem Wechsel zur http://code.google.com/p/glmatrix/ Matrixbibliothek gab es einige FPS-Gewinne. Ein interleaved VBO für Vertices und Normalen benutze ich auch, was aber kaum Unterschiede brachte. Wichtiger war es auf das böse bindBuffer und createBuffer zu achten..

Nun bekomme ich auch bei ca. 250 Aufrufen eine halbwegs gute Geschwindigkeit (ca. 15fps), wobei da schon die CPU und der Browserspeicher ordentlich zu kämpfen haben.
Eine höhe ANzahl von drawArrays führt leider zu unangenehmen Rucklern; das Bild ist nicht mehr flüssig.
Meine Fragen:

1.) ist es generell so, dass schon mit vergleichsweise wenigen draw-Aufrufen eine so grottenschlechte Performance üblich ist oder mache ich irgendwo einen Fehler? Meine Szene wird nicht nur maximal ~500 Objekte, sondern viel mehr darstellen müssen.

2.) Wie macht man es denn normalerweise mit derart vielen Einzelobjekten, die nach dem Zeichnen z.B. durch Colorpicking identifiziert werden und individuell manipulierbar sein sollen?
Mit ist halt nur die Idee mit dem VBO pro Objekt gekommen.

grüße

Ich denke du kannst davon ausgehen das alles was du auf der CPU machst um den Faktor 20 (mindestens!) langsamer ist als wenn du das in C++ oder Delphi machen würdest. Die Grafikkarte läuft natürlich nicht langsamer. Bei Verwendung von WebGL der Browser bzw. JavaScript der limitierende Faktor.


Sind alle Objekte sichtbar? Wenn nicht, kannst du eine Baumstruktur aufbauen so das du mit wenigen Tests viele Objekte vom rendern ausschließen kannst?
Da du ja offensichtlich Colorpicking machst musst du zweimal rendern. Mache den Sichtbarkeitstest nicht zweimal sondern erstelle eine Liste/Array der sichbaren Objekte und rendere diese zweimal.
Kannst du Berechnungen in den Vertexshader auslagern? Du könntest etwa jedes Objekt mit einem zusätzlichen Attribut pro Vertex markieren. Der Vertexshader kann dann anhand dieses Zusatz-Attributes entscheiden welche Transformationsmatrix ernehmen soll, etc...

_________________
Yeah!