Hi,

ich würde meine Welt, in meinem Fall bloß eine GUI, jedoch mit perspektivischer Projektion, gerne in einer Baum-Struktur Speichern, dass bringt mir gerade für die GUI viele Vorteile, wenn ich einen Knoten rotiere, dann rotieren die Unter-Knoten natürlich mit, ich bin mir nur nicht ganz sicher wie ich das realisieren soll, bisher dachte ich einfach jeder Knoten bekommt eine Matrix welche die Position und Rotation des Knoten beinhaltet und dass wird halt zu den Kindern hin aufmultipliziert, mit anderen Worten: Position und Rotation sind relativ zueinander.

Ich krieg das allerdings einfach nicht sauber hin, bisher siehts es in Etwa so aus:


(Aus dem Gedächtnis aufgeschrieben, keine Gewähr auf evtl. Fehler)

So in etwa schaut mein Code aus.
Irgendwie bin ich unzufrieden damit, gerade weil ich es nur für eine GUI nutze. Es scheint mir doch sehr Performance lastig zu sein, in dein meisten Fällen bestehen die Knoten aus 4 Vertizes und 6 Indizes (Quads), dafür so ein Aufwand mit den Matrizen scheint mir überdimensioniert, gerade weil auch relativ tiefe Ebenen vorkommen (4 bis 6 sind keine Seltenheit), dann habe ich quasi für jedes Quad 4-6 Matrix Multiplikationen und überhaupt halte ich für jeden Knoten (wie gesagt meistens Quads) eine komplette Matrix, die benötigt ja mehr Speicher als das Quad selbst...

Gibt es da irgendwelche schöneren Lösungen? Habt ihr Ideen? Mir ist eben nur wichtig, dass sich bei der Rotation, bzw. Verschiebung eines Knoten die Unterknoten mit verschieben, es soll eine 3D GUI werden.

Viele Grüße & Danke im voraus .

Ideen:
1. Speichere direkt die Matrix, nicht die einzelnen Vektoren. Aktuell musst du nämlich immer erst alle Werte kopieren bevor du auch nur irgendwas tun kannst.
2. Wenn du wirklich nur Rotation und Translation (Verschiebung) möchtest, kannst du auf Quaternions umsteigen. Diese sind eine alternative zu Matrizen, können aber nur Rotation. Translation kann man hinzunehmen indem man zusätzlich einen Vektor speichert. Skalierung oder Scherrungen wären nicht möglich. Vorteil ist, dass die sich zwei Quaternions leichter (weniger Operationen) miteinander multiplizieren lassen. Nachteil ist es gibt aber zusätzlichen Aufwand, für OpenGL musst du das Quaternion in eine Matrix umwandeln. Der Nutzen für deinen speziellen Fall ist fraglich, da du wahrscheinlich in den meisten Knoten etwas rendern wirst. Es würde sich möglicherweise lohnen, wenn du etwa nur in den Blattknoten umwandeln müsstest oder in jedem Schritt auch die inverse Matrix benötigst. Skalierung könnte bei einer GUI natürlich durchaus notwendig sein, dann würde es ganz ausscheiden.
3. Ich denke mal viele Elemente (insbesondere in den unteren Baumebenen) sind fest und ändern sich nicht. Wahrscheinlich transformierst/rotierst du nur ganze Fenster, nicht kleine Detail-Elemente. In diesem Fall könntest du die Vertices Vor-Transformieren und gemeinsam in einem VBO des Eltern-Knotens speichern. Auf diesen vor-transformierten VBO musst du nur noch die Matrix des Elternknotens anwenden, nicht die Kindermatrizen. Ggf. erlaubt dir dieser Ansatz sogar vieles in einem Rutsch zu rendern. (Der Overhead alleine durch den Draw-Call ist recht hoch, es macht kaum einen Unterschied ob du 1 oder 100 Dreiecke in einem Aufruf renderst....also wenn irgendwie möglich nicht alle Quads einzeln rendern...geht natürlich nicht immer in sinnvoller weise)

_________________
Yeah!

Hi,

danke für deine Tipps, gerade der letzte Punkt klingt vernünftig, ich müsste mir nur überlegen wie ich das möglichst dynamisch erledige, ich hab mir überlegt jeder GLView auch einen Status zuzuweisen, STATIC oder DYNAMIC, wenn eine GLViewGroup jetzt einige STATIC GLViews beinhaltet, können diese statischen Views vortransformiert in der ViewGroup gespeichert werden (bzw. in einem VBO in der ViewGroup). Wenn diese Statischen Views nun doch transformiert werden sollen, passiert das einfach komplett auf der CPU in einem eigenen Thread und wird anschließend in das VBO geschrieben.
Bei den DYNAMIC Views bleibe ich einfach bei dem alten Renderpfad, wobei man mal testen müsste ob es nicht vielleicht grundsätzlich schneller wäre einfache Views (=wenig Vertizes) vorzutransformieren und am ende einfach nurnoch ein VBO zu rendern. Evtl. kann man auch die gesamte GUI auf der CPU Transformieren, aber ich denke das hängt rein davon ab, aus wievielen Views die GUI besteht.

Ich werd mich dann demnächst mal ans ausprobieren machen .