scenegraph..

The scenegraph.. provides a common relational structure, to present blobs of things that move,scale, rotate and do other things together, as whole. When an entity wants to take a ride on a car, the entity is put as the vehicles child node, meaning that the entity now exists in the vehicle space and the vehicle exists in the world space, so any change to vehicles world space coordinates, affects the entity too.
The scenegraph is made of nodes, and the nodes, in Bolt will be made of Matrix4x4, the node can have all sorts of properties, camera, audio, image, shaders etc. from these we can derive the stuff that we actually do.. Inheriting the node and creating a camera node? nah, just attach camera property to the entity that the node is representing and done.. This way any and every entity can act as a camera, giving options and freedoms for creativity  and
nodes, create scenegraph, have child/parent reletations, contain spatialdata of Matrix4x4 for location and orientation.. maybe also matrix to denote acceleration/speeds..
colormodifications? no, for now pure scenegrap, to denote 3 dimensional relations.
What else? containing script nodes? entities? the physics? or should the physics be put on totally different abstraction level?
The entity system can probably encapsulate anything.. tight integration of the physics and the scenegraph?..

camera class.. and the tools

Development of bolt has slowed down a bit, as I've been busy at work, and pondering and prototyping the tools (mainly the map editor). I am using Trolltech QT.. some impressive extension to c++, tools and abstractions for fast development for the map tool. First thing I did was the main UI, that is just opengl canvas + a toolbar, Afterwards came the sketching of world classes (World + Tile), which encapsulates the vertexes and polygons for each grid. Each grid stores the polygon & vertex data, created with tools (heightmap tools etc, to ease the sketching of landscape).

At the moment I am trying to solve the camera abstraction.. Many have solved it with using gluLookAt style solutions ( LeoLol java engine, camera class , three.js src ), one UP vector, one FORWARD vector and one RIGHT vector, that can be easily used to rotate and move the camera. The nice thing about these vectors is, that strafing the camera, is as easy as to add the result from multiplying RIGHT vector with the strafing movement speed. This solution seems to be quite popular, it is even directly in some graphics api (M3G , glut) and, it works.. But for my needs, I see this kind of structure, too complicated.. 
First I was going to just store the camera as position (Vector3D) + orientation(Quaternion) + projection(Matrix4x4), this approach would make the properties self explanatory, no scaling, no skew, nothing complicated.. but after further analysis, Quaternion needs to be converted into matrix representation for camera strafe/view based movement and for almost everything, the only benefits for Quaternions are size and unbeatable rotation calculations. So because of this, I am leaning on to use of position(Matrix4x4) + projection(Matrix4x4), so that the position will save orientation and location for the camera.