scenegraph transformation

miller_m

bisher hatte ich so geplant alle node transformationen in weltkoordinaten anzugeben somit müsste ich jedes mal die matrix pushen, allerdings ist der stack
ja sehr begrenzt, in der regel 32. die stack grösse überschreitet ja man mit leichtigkeit mit einem ast. zweite überlegung war, ist vermutlich auch die bessere, am anfang vom ast eine einheitsmatrix zu setzen und dann die transformationen pro node dazu multiplizieren. doch wenn ich den baum traversiere sollte es eigentlich nicht wichtig sein in welcher tiefe ich mich befinde.
wie lösst ihr das problem? eigener root knoten? zusatz var?

eigentlich nicht wichtig aber es geht um opengl

dali

Wie es du schon richtig gesehen hast eine lokale und eine globale Transformation. Dann ist die globale einfach lokale * globale des Parent.

Cpp_Junky

Übrigens kann man sich auch leicht selber so einen Matrix Stack basteln der dann unbegrenzt ist. Könnte allerdings Geschwindigkeit kosten wenn man dauernd die Matrix wegsichert und zurückschreibt.

miller_m

ist klar, habe ich auch schon geschrieben, aber meine nodes kennen das parent nicht. warum auch.
mir macht du das wechseln des astes sorgen.
bsp:

root
        /         \
1.transformation  2.transformation
       |            |
     mesh         mesh

traversieren:
root
1. transformation
mesh zeichnen
hier müsste ich wieder auf die root matrix zurück
2. transformation
mesh zeichnen

vermutlich muss ich noch ein zusätzliches node einführen ala matrix stack.

miller_m

Cpp_Junky schrieb:

Übrigens kann man sich auch leicht selber so einen Matrix Stack basteln der dann unbegrenzt ist. Könnte allerdings Geschwindigkeit kosten wenn man dauernd die Matrix wegsichert und zurückschreibt.

so etwas dachte ich mir auch schon, aber wie du schon sagst ist dieses vielleicht nicht das optimale.

dali

aber meine nodes kennen das parent nicht.

Speicher halt nen Pointer auf den Parent? Naja depth-first durch den Baum traversieren und dann die Matrix anpassen ist doch kein Problem. Sharing ist halt dann ein kleines Problem aber sonst...

miller_m

dali schrieb:

Speicher halt nen Pointer auf den Parent?

sollte kein problem sein.

dali schrieb:

Naja depth-first durch den Baum traversieren und dann die Matrix anpassen ist doch kein Problem

gute idee aber dann müsste das leaf ja ein transform node sein oder sehe ich etwas falsch

dali

Jeap das Leaf wäre in deinem Fall ein Node.
Schöner wäre es natürlich wenn du eine 2te Klasse machst in der du Pointer auf Parent und die Transformationsmatrizen speicherst von der du dann Node und Geometry etc ableitest weil ein Node als Leaf ist nicht gerade schön aber eigentlich egal.

miller_m

mmmh, wenn ich dich richtig verstanden habe verkompliziert das meine ursprünglichen design gedanken. da ich eigentlich den graphen öfters mittels verschiedenen visitors durchlaufen wollte und somit verschiedene traversierungs methoden entwickeln müsste.

TGGC

dali schrieb:

Jeap das Leaf wäre in deinem Fall ein Node.

Ist es doch immer.

Irgendwie glaub ich nicht, das so ein paar Matrixmultiplikationen länger dauern, als die Szene aufzupinseln.

Bye, TGGC

dali

TGGC schrieb:

dali schrieb:

Jeap das Leaf wäre in deinem Fall ein Node.

Ist es doch immer.

Ne ist es nicht.

TGGC

Natürlich ist es das. Siehe Begriffsdefinitionen Graphentherorie.

Bye, TGGC

dali

Naja normalerweise reden wir bei nem Szenengraph ja über nen abstrakten Graph also dass die Blätter/die Geometrie dann keine Kinder mehr haben ansonsten hätte man ja viel mehr Aufwand/Zeitverlust die Transformationen zu verwalten...

TGGC

dali schrieb:

Naja normalerweise reden wir bei nem Szenengraph ja über nen abstrakten Graph also dass die Blätter/die Geometrie dann keine Kinder mehr haben ansonsten hätte man ja viel mehr Aufwand/Zeitverlust die Transformationen zu verwalten...

Du erzählst Unsinn. Ein Blatt ist ein Knoten in der Graphentheorie.

Bye, TGGC

dali

Aber ein Scenegraph ist kein normaler Graph. Warum soll eine Geometry auch ein Kind haben? Warum soll ein Knoten 2 oder mehr Väter haben?

TGGC

dali schrieb:

Aber ein Scenegraph ist kein normaler Graph.

Natürlich ist ein Scenegraph ein Graph. Etwas ist entweder ein Graph, oder es ist kein Graph. Ein "Mittelding" (anormaler Graph?!) gibt es nicht. Dieser Graph hat nur bestimmte Eigenschaften, auch Baum genannt.

Bye, TGGC

dali

Ein Baum wäre zum Beispiel eine Eigenschaft eines Graphen? Dann würde aber auch bei jedem Baum ein Blatt ein Knoten sein deiner Logik nach oder?

Cpp_Junky

Der einzig wahre Graph... ähhh Graf ist der hier

http://hometown.aol.de/grafzahl38/images/graf zahl.jpg

TGGC

dali schrieb:

Ein Baum wäre zum Beispiel eine Eigenschaft eines Graphen?

Unsinn, Graphen, die gewissen Eigenschaften genügen, nennt man Bäume.

dali schrieb:

Dann würde aber auch bei jedem Baum ein Blatt ein Knoten sein deiner Logik nach oder?

Ja, darum geht es doch: Ein Blatt ist ein Knoten. Immer.

Bye, TGGC

dali

Also ich habe zb Klassen Node, Transform und Geometry:

class Transform {
...
};
class Node: public Transform {
Transform* childs[]
};
class Geometry: public Tranform {
..
};

dann sind die Blätter von der Klasse Geometry also nicht Node also kein Knoten. Also ich weiß jetzt nicht genau was du unter Knoten meinst aber wenn du unter Knoten die Gruppierungsklasse meinst dann ists falsch..

rapso

lasst euch von TGGC nicht verrückt machen, ihr benutzt schon die typischen termini für sowas. gibt viele engines und coder die mit euch gleicher meinung wären. es geht ja nicht darum eine wissenschaftliche theorie anzuwenden, sondern namen zu haben unter denen sich die, die sich damit beschäftigen, auch was vorstellen können. und wenn ihr von z.b. leaf sprecht, egal was irgendwelche weltfremden theoretiker behaupten, jeder der nen bsp-tree mal implementiert hat (nach guten vorbildern), weiß was ihr meint. jeder n00b in dieser richtung dürfte natürlich nicht wissen, was in diesem fall der unterschied zwischen node und leaf ist

rapso->greets();