Scene Graph + Verständnis Problem
-
Hi!
Seit einiger Zeit bin ich am überlegen, wie ich am besten einen Scene Graph aufbaue, allerdings stoße ich dabei immer wieder auf Verständis Probleme.
Angenommen ich habe einen Baum, der Objekte vom Typ "Node" speichert.
Nun leite ich von der Basisklasse "Node" einen Typ "GeoNode" ab.
Dieser speichert Transformationen, Rotationen und Skallierungen und stellt gleichzeitig Methoden zur verfügung, die rekursiv durch die Childnodes itterieren, um das jeweilige attribut auch dort zu verändern (zb.SetTransformation()).Ich erstelle nun ein Objekt vom Typ "GeoNode" und füge eine Childnode eines anderen Typs hinzu, der weder GeoNode als Basisklasse, noch eine Methode SetTransformation() besitzt.
Wenn ich nun für das Parent Objekt SetTransformation() aufrufe, fängt er an durch die Childs zu travesieren um dort gleichfals SetTransformation() aufzurufen.Für das Objekt, das GeoNode nicht als Basisklasse
besitzt, wird dies aber logischerweise nicht gelingen.Wie umgehe ich dieses Problem?
-
indem die ueberladene funktion dann einfach leer ist.
btw. wenn du c++ codest, must du nicht set/get vor funktionen schreiben, dafuer gibt es extra funktions-ueberladung
-
indem die ueberladene funktion dann einfach leer ist.
Würdest du das wirklich über virtual calls machen?
Ich denke gerade sowas grundlegendes wie eine Transformations-Matrix sollte man direkt in die "Node" Klasse einbauen, und dann mit inline Funktionen drauf zugreifen.
btw. wenn du c++ codest, must du nicht set/get vor funktionen schreiben, dafuer gibt es extra funktions-ueberladung
Es gibt auch Leute die "Set" und "Get" als Prefix bevorzugen, auch wenns in C++ ohne geht
-
hustbaer schrieb:
indem die ueberladene funktion dann einfach leer ist.
Würdest du das wirklich über virtual calls machen?
Ich denke gerade sowas grundlegendes wie eine Transformations-Matrix sollte man direkt in die "Node" Klasse einbauen, und dann mit inline Funktionen drauf zugreifen.
wie sonst?
du kannst natuerlich auch jedesmal ne langsamme abfrage machen anhand eines flags oder desgleichen ob du die transformation vollbringen sollst oder sofort returnen. aber der saubere c++ Weg wird dich gluecklicher machen, besonders wenn du spaeter waehrend eines transforms noch mehr machen moechtest, koennte ja z.b. sein dass du in 'Renderable'-Leafs mal so eine UV animation/transformation durchfuehren moechtest.btw. wenn du c++ codest, must du nicht set/get vor funktionen schreiben, dafuer gibt es extra funktions-ueberladung
Es gibt auch Leute die "Set" und "Get" als Prefix bevorzugen, auch wenns in C++ ohne geht
gibt auch leute die this-> vor alles schreiben muessen, leute die keine accessor funktionen nutzen, leute die vor jede variablendeclaration noch struct schreiben usw.
nur wozu? eine einen sauberen c++ style gelernt kann man nicht mehr ohne leben
-
Also, erstmal danke für die antworten (:
indem die ueberladene funktion dann einfach leer ist.
Wäre eine Möglichkeit nur ensteht dann zum einen einen overhead durch Funktionsprünge, die absolut nicht sein müssen, und zum anderen sieht es imho komisch aus wenn sämtliche Objekte innerhalb des Baumes für jede Möglichkeit Funktionen bereitstellen(Geometrie Transformationen waren ja nur ein einfaches Beispiel, es gibt ja weiiiiiiit mehr).
Ich denke gerade sowas grundlegendes wie eine Transformations-Matrix sollte man direkt in die "Node" Klasse einbauen, und dann mit inline Funktionen drauf zugreifen.
Naja, stell dir zum Beispiel eine Node vor die die Aufgabe hat, Hintergrundmusik zu spielen. Wäre auch komisch wenn diese Geometrie Transformationen speichert.
Gibt es keine sinnvolle Möglichkeit auch komplexere Situationen in so einem Graphen darzustellen, die halt über Transformationen und Rendern hinausgehen?
-
Äh, ok, sorry, ich dachte man sollte für Grafik und nicht-Grafik sowieso zwei (oder mehr) parallele "Graphen" fahren. Bzw. sagen wir mal so, ich kenne das so.
Dann gibts eigentlich keine Nodes mehr die keine Transformation brauchen.Macht meiner Meinung nach auch Sinn, denn dann gehen eben solche Sachen wie das durchackern aller Transformationen oder das zusammensuchen aller Nodes die auch physikalisch simuliert werden oder ähnliches viel schneller. Weil man im Prinzip nurmehr die Nodes angreifen muss die auch relevant sind. Und wenn man das so aufbaut macht es mächtig viel Sinn einfach jeder Grafik-Node ne Transformation zu verpassen, und dann mit inline Funktionen drauf zuzugreifen.
Ich lasse mich diesbezüglich aber gerne belehren, was Game-Programming angeht bin ich wirklich nicht der Kenner/Könner/Crack.
-
nenn es nicht Transform, nenn es "Update" und schon ist es nicht mehr so absurd wenn der ganze scenegraph fuer jede node ein Update faehrt.
ich kenn das ganze nur mit einem scenegraph und hoechstens noch culling-graphen usw.
und nein, du musst nicht fuer jede Ableitung die funktionen leer ueberschreiben, sofern du ein basisobjekt hast das leere funktionen schon bereitstellt.
Eine weitere moeglichkeit ist, dass du nur eine art von Nodes hast, an denen du dann laefs haengen hast, und nur die laefs sind dann von verschiedenen objekttypen.
