@supervga, I wish I was using a scenegraph at this point. I decided i want to try something fancier. The game has a simple array of game objects it loops trough for updates. Each object has a transform that has a parent, which makes up my "scene graph". After all the game objects are updated they recalculate their world position, resolve any collisions and are then rendered.
Rendering is done trough a render component, when one is attached to an object it registers with the render manager. After collisions are resolved, the camera determines which objects in render manager are visible. Each visible object gets its mesh data and world matrix passed to opengl to be rendered.
Is this design too convoluted? What might be a better way to manage these entities and still not be dependant on a scene graph when updating an object?
I too think it seems like a fair number of updates (on every object) if you have a low amount of objects.
The peculiar thing with your set up is, that you perform transforms upwards (or, at least, on every item you consider the parent and so forth)
Where you'll find it more straightforward to start from a root node.
I can fully understand if you don't want this; if all your objects are dynamic and independent of oneanother, there's no reason to bind them in a transformation tree.
But this doesn't mean you cannot use optimizations for updates and collisions.
You can also optimize by having
1) a resting flag that is raised when the kinetic energy in the object has run out. (Object stops moving seconds after hitting the ground, etc.)
2) Creating a grid of sectors that each contain a list of references to their contents.
When computing collisions, you can prune objects that are x sectors away from the current object (based on how large objects and sectors are)
If you want to take it a little further, or have a lot of objects, you should look into using Quadtrees (Random, seemingly interesting quadtree article here)