This may be good to think about for the future, possibly implementing a scenegraph system into Blaze?

Perhaps you can convince Erin Catto over at box2d.org to implement it, or if it seems easy do it yourself.

However, a scenegraph is not the easiest task, and it has the possibility to make the whole project too complex.

I think a scenegraph would be really helpful if it was implemented directly into blaze and allow for Parent + Child nodes + rotation + translation and handling all the calculations needed to accomplish this correctly.

I think scenegraph would be more appropriate being directly built-in to a physics engine than it would be to use as an 'add-on,' since scenegraph deals with the position , rotation, and translation of a given group of objects.

If it can be pulled off, great! I myself don't need this feature anytime soon, but if I do I may try to help out with it myself. Maybe even allowing invisible 'key points' that blaze keeps track of within itself would also be a good idea, so these points can be placed anywhere on an object and would rotate and translate with objects. An example would be placing such a key point on an object and use it as a weapon firing point, or a point to place a lighting effect or particle effect on, while the physics engine will keep track of its position on a given object automatically.

Bodies already keep track of the rotation and translation of their child geometric shapes, so I don't think this would actually be that bad. The code's probably already there, cleverly disguised as something else.

Bodies already keep track of the rotation and translation of their child geometric shapes, so I don't think this would actually be that bad. The code's probably already there, cleverly disguised as something else.
I'll look into this.

Box2D / Blaze uses an island system whereby groups of colliding contacts are connected via a contact graph. The sequential impulse solver traverses the graph and applies an impulse to all connected objects in the island.

Is this what you refer to as a scenegraph? If so, it's implemented via. a linked list.

A scenegraph would be used to represent a 'scene' in graphics. The parent scene would be composed of the entire scene, where the children in the scene would be represented as objects (rocks, trees, vehicles). Each child may also have children (vehicle tire, vehicle windshield, etc.). Each node keeps track of its own rotation + translation. If the car rotates 90 degrees, all its children will be rotated 90 degrees as well. If the car moves, all its children (tires, windows) will move with it.

I think that the best one could hope for with combining a physics engine and a scenegraph is to isolate rigid bodies in the scene and register them with the physics engine independently, and have the phyiscs engine adjust the x,y,z,r and the dx,dy,dz,dr as things it sees fit.

A scenegraph is good for combining objects into rigid bodies that move in unison. A physics engine is good for independent, non-combined objects. Am I right?

A scenegraph is good for combining objects into rigid bodies that move in unison. A physics engine is good for independent, non-combined objects. Am I right?

It really depends upon the physics engine. Box2D allows you to attach individual shapes to a rigid body, all of which move in unison along with the parent body's transform. You could build in additional complexity by adding a bounding volume hierarchy that compliments the broad phase collision detection, which as a whole would probably constitute a scene graph.