Hierarchy. That is what this thing called scenegraph is about. Objects in a 3D world have relations to each other, to the world, to the physics, to all kinds of factors that influence them. The scenegraph is a way to isolate groups of objects by storing the hierarchy between the objects. It creates a focuspoint where physics meets motion and therefore separating the physics library from the gameengine. This way the connection between these libraries stays very thin.
[top]
Creating a hierarchy means creating a situation where the objects are not all equal. Some are more important than others, some know of others while others know nothing of some. If you want to let a character wave his arm, you don't want to tear it of his hand and shoulder. The arm must know it has a hand at the end of it so that when it moves it can tell the hand to move also. So if you move the arm, you move the hand and therefore move the fingers. The arm has a one-way relationship with the hand: a hierarchy. This hierarchy is stored in a scenegraph. In the previous example we choose for the arm knowing of the hand and the hand knowing of the fingers. But the fingers do not know of the hand and surely nothing of the arm. We wanted to wave the hand, so we made the arm the most important part of the hierarchy. We call the arm the 'parent' of the hand. The hand itself is a parent to the fingers. The fingers are children of the hand, just like the hand is a child of the arm. And all of these are called 'nodes'.
Now, if one of you boys and girls have already heard of a scenegraph, take notice that the scenegraph used in Ketsji might not be the same sort of scenegraph you heard about. So how does our scenegraph work? First, let me tell you the way 'other' scenegraphs work. Other programs that use a scenegraph have one that is practically nothing more then an entire database of all relations of all objects and the world they're in. This way everything is structured in a nice way. The problem with this kind of scenegraph is that it is not convenient for visibillity algorithms. And why should you want to know the hierarchy/relation of all objects? It works fine for 3D creation suites, but inside a gameengine it is too elephantine.
Well then, what about the scenegraph in Ketsji? This scenegraph is meant for local local hierarchies. It is more de-centralized. We want to control our world piece by piece, divide and conquer.
Take a character in a 3D world (and let's call him JP). Every part of JP's body is a gameobject. All of these gameobjects are related to nodes in the scenegraph belonging to JP. The most important node, i.e. the torso, has knowledge of its position in the world around it. We call it the rootnode. The arms have only knowledge of their relative position to the torso. They're children of the parent torso. The hands are children of the armes, the fingers are children of the hands. The same with the legs and the head. So JP is a scenegraph in itself. Just a small hierarchy for a group of objects belonging together.
As I told you before, the scenegraph is used mainly for positioning, or -more precise- change of positioning: motion. When moved, a parent gives his new position to its child. The child creates his own new position by means of a transformationmatrix, stored locally. But the parent is not the only one influencing the child. There are things like controllers. A controller is used for applying motion to the node. There are several sorts of controllers, for things like physics, IPO's (interpolators) and soon IKA's (inverse kinematics). But remember, a controller is not part of the scenegraph, it is part of Ketsji itself. This way the scenegraph module doesn't need to be altered when controllertypes are added or changed, it is happy when it gets information from *a* controller, no matter what kind. We now have a situation that is easily extendable.
Lets start with physics. If JP is hanging in the air, Newton wants him to fall down. The way we handle this apple is by way of the physicscontroller. A physicscontroller is the ony way the physics are connected to the 3D world. A gameobject has no knowledge of physics. The physics module tells the physicscontroller what it wants and the physicscontroller tells JP's root node. Ok, now JP's torso wants to fall down. Because it is connected to its children, JP's limbs and head are going to join the torso and there he goes, all the way down.
Now we want JP to be scared while he drops, waving his arms. We connect an IPO-controller to his arms telling them to shake around. So now the arms' position isn't only determined by the law of physics (though be it indirectly) but also our IPO.
Copying an object is easy. But how do we copy a group of objects, complete with hierarchies, and relations to new, not even existing objects and controllers? First we copy the rootnode. We say to the object: go and procreate yourself. And so it happened: the object replicates itself. Second we tell all kids (and their kids, and their kids) to replicate themselves. Now we got a whole bunch of new objects, but these objects do not have a relation with each other yet. Using callbackfunctions and temporarily meshes we store the relations and project these on the new objects. Now the new parents can find their new children and a new hierarchy is created.
It is important to realize that all relations have to be new: we don't want a hand to respond to a controller of the hand it was copied from, but to its own controller.
Something else. As an example of the exstensibility of the engine, in the future there'll be a feature called inverse kinematics. We want JP to walk up the stairs. If we move the torso up and drag his legs along, things will go wrong: the torso moves up, tells the legs to move accordingly (the parent-child relation) but ai ai ai his feet are IN the stairs! Off course we don't want this. So we tell JP to move his feet first and after that his legs and then his torso. We call this inverse kinematics. But the problem now is that the feet don't know who their parents are. We know the legs are but the feet don't. So how do we fix this? Well, IKA works on controller level. The IKA controllers connected to the feet have a relation to the controllers connected to the legs. So if we tell JP to lift a foot, this information goes to the related controller and that controller tells the leg to move accordingly.
[top]
[top]