Ok. I will try to elaborate, though it is not that easy and clear for me as well. Stated differently, if the problem was 100% clear, I just solved it.
The most basic problem, I wanted to solve first is the ability to specify relative/local transformations between a parent and a child object. So I created a Transform class which only encapsulates such a single relative transformation. Next, I wanted to relate these local transformations to world space and I wanted the ability to hierarchically structure local transformations in such a way that changing a local transformation affects the world transformation of all direct and indirect children as well. So this is my scene graph. This is not some general graph describing some arbitrary node connections, but a specialized graph in the sense that a connection between two nodes is always associated with a (direct) relative transformation between those two nodes. The idea is based on the way Unity3D's editor organizes a scene: a scene can have multiple root nodes each having their own hierarchy and each node has at least a local transformation. This conceptually works for lights, cameras and models, but is less suitable for screen-space sprites since 3D transformations are not used for the latter. One still needs them, however, to be able to add child nodes to such sprites which unlike the sprites require the chain of transformation to and from world space. So I created a TransformNode class. Instances of this class constitute the scene graph. A TransformNode has a pointer to its parent node (which does not exist for root nodes) and its child nodes. Furthermore, the TransformNode contains a Transform specifying the local transformation (connection with its parent node or the world itself in case this is a root node). Since, I want to cache the transformation matrices and update them if they are dirty, child TransformNodes must be notified of changes to a Transform of one of their ancestor TransformNodes (to invalidate their matrices). Some callback mechanism can be added to the Transform class for this purpose, but this is not clean: the Transform class is finished and must be a general class that can be used as some utility in other projects as well. Furthermore, adding some listener for example results in less controllable traversals of the hierarchy. So I wrapped the Transform inside the TransformNode. This is also more convenient for the user: instead of dealing with Transforms and TransformNodes, it suffices to use the TransformNode, furthermore it is not even possible anymore to work with a Transform since this is completely hidden by the TransformNode. By wrapping the Transform, cached matrices of the descendants of a TransformNode can be invalidated in a straight forward breadth-first or depth-first traversal. Alternatively one can flush transformation matrices down the graph once per frame. The disadvantage of flushing is the inability to use the transformation matrices for scripting. My approach, however, always results in the correct and up-to-date transformations. For example: if you translate some parent model first, and then retrieve the world-to-object or object-to-world matrix of some child light, camera or model, you will get a matrix taking the re-positioning of the parent into account.
The first problem that arises, however, is what is a parent and child node for a TransformNode. It could be a TransformNode, but like I said the TransformNode (just as for a Transform) merely deals with a hierarchy of transformations. I do not want to add extra data for activating/deactivating nodes, for giving a name to a node. So instead of storing pointer to TransformNodes inside the TransformNode for constituting the hierarchy, I use some other class Node which owns a TransformNode. So implicitly, a hierarchy of TransformNodes exists though indirectly due to the Node. This has two advantages. First, I can access the TransformNode of a Node by just calling a method Node::GetTransform(), which is cleaner and clearer than directly invoking transformation related functionality on Node itself. Second, I can use Nodes instead of TransformNodes for the propagation of data in my graph. For example: transformation matrices can be invalidated by notifying the TransformNode of each child Node, subtrees can be activated/deactivated by notifying each child Node.
The only tricky part in my Node<->TransformNode implementation is managing the hierarchy. Adding to, removing from and re-adding to a Node is supported. If Nodes are terminated (marked for deletion), the whole subtree will be terminated. If a copy constructor is invoked, a deep-copy of the whole subtree is performed and results in a new subtree (which has no connections with the previous subtree). So far we have some abstract Node class which is finished and is a general enough to be of use as some utility in other projects as well.
The Node class is derived by the SceneNode class which basically adds a name at the moment. I do not consider a human readable name some universal property of a Node, so this is not added to the Node. The SceneNode has ModelNode, CameraNode and LightNode subclass which provide functionality to add a Model, Camera and Light, respectively, which can all have their own hierarchies. For example a Camera is not the same as CameraNode. The Camera deals with the view-to-projection matrix and the camera lens. The CameraNode obviously deals with the Camera and its Transform as well as with additional fluff such as some view settings and a viewport transformation.
For the purposes of rendering, I do not work with the root Nodes or root SceneNodes but I need to distinguish Nodes till some certain specialization level and I want a fast way of iterating these. Therefore, my Scene class contains separate collections for all CameraNodes, all ModelNodes and all specializations of the LightNodes. The disadvantage of working with specialized lights, is the user's inability to define its own lights. On the other hand it is difficult to probably impossible to handle all lights in a similar fashion for a rasterizer compared to a ray tracer. Cameras on the other hand can be specialized by the user, since the Camera interface suffices to work with for rendering. So for example: I never need to distinguish between orthographic and perspective cameras and the user can define a fish eye camera himself that will be used appropriately while rendering.
For rendering purposes, I collect all active CameraNodes, ModelNodes and specialized LightNodes in some buffer which will be passed around for the different render passes. Note that I do not directly use the implicit hierarchies underneath them. There is in fact only one indirectional usage: getting the object-to-world and world-to-object transformation matrix. If one of these matrices is dirty, some child-to-ancestor propagation is possible.
But now there is another problem: on the one hand we have some hierarchy of Nodes and on the other hand we have some flattened collections of Nodes in the Scene. Only the latter will be rendered. For ease of use, I decided that all Nodes must be created by invoking some factory method on the Scene object. So if you want to create an OmniLightNode, you invoke Scene::Create< OmniLightNode >(name, args). This method will create the OmniLightNode and ensures the OmniLightNode is added to the collection of OmniLightNodes. When the user receives his OmniLightNode, that Node is a root Node. If he wants, he can add it to some other Node. Unfortunately, I do not allow or support the other way around: what if the user copies (i.e. deep copy) an existing OmniLightNode, he can not add it to the scene since I do not provide an interface for that. The first reason for not providing an interface is to avoid the need to check for duplicates in the collections of the Scene itself prior to adding. I use a vector and not a set since the vector is more cache coherent and faster to iterate sequentially. Furthermore, adding the same component twice is an exceptional stupid situation that should not have an impact on all additions. The second reason is actually the inability to do so without a visitor. You can create an OmniLightNode and a PerspectiveCamera without using the Scene and add the latter as a child of the former. Or you could invoke the Clone method on some existing Node which will create a deep copy of which the Scene is unaware. If you want to add this Node to the scene, you probably succeed for that specific Node but what about its descendants? They need to be added to the Scene as well and they need to be added to the appropriate collection. The only way this could be achieved is by using a visitor pattern?
But there is even another very similar problem. Lets assume we have some OBJ mesh of some windmill consisting of a base building and the blades. The mesh specifies that the blades are a child of the base building. When I perform a Scene::CreateModel(name, args), I create a ModelNode for the base building and the blades and I add the latter to the former. Both ModelNodes are added to the collections of the Scene and the root ModelNode is returned to the caller. The caller obtains a pointer to a ModelNode which has one ModelNode as a child (i.e. the blades), but how do you use the latter one? If the name is unique, I can query the ModelNode of the building and obtain a Node of the blades (this also requires the name to be present in the Node and not in the SceneNode). Since, I have a Node, I can obtain the TransformationNode and use it in some script for rotating the blades. But I do not have the ModelNode, I have a Node, so if I want to do something fancy such as changing the material, I cannot do that without casting or double dispatching (i.e. visitor).
So I hope this somehow makes a bit sense?
