In my opinion it would be best to have all scene objects capable of being a parent and to hold children. It will just make object handling a little easier. Something like the following maybe?

class SceneNode
{
	std::list<SceneNode*> children;
	
	/*Add methods here for adding and removing scene 
	nodes and any other common node methods too*/
};

class Bus : public SceneNode
{
	/*Bus related methods*/
};

class Character : public SceneNode
{
	/*Character related methods*/
};

As for physics, you mentioned Bullet...It holds it's own scene structure and feeds your scene objects with updated transforms. So it basically runs independently to your scene graph and you'd be using Bullets interface to move objects around. To create rigid bodies you feed Bullet with raw geometry (or use simple primitives) and positional data. You'd then tell Bullet what rigid bodies are attached to each other (parent/child relationships).

Note: I don't need really advanced physics simulations, just rigid body and collision.

Unfortunately once you start colliding multiple objects together and want correct collision detection and response, it becomes rather tricky, and implementing your own solution basically ends in recreating the wheel so to speak. Bullet will only do what it needs to do in terms of calculations so you wont be loosing out by using it.

my strategy:

the large scale world is divided up into "regions". each region is a fixed sized space (basically like a big cube), and they are laid out in a giant grid. as-is, the regions are 512x512 meters (or 16384 ~1.25 inch "units").

an idea here is that a player may only see into at-most the 4 nearest regions, and anything beyond this can be saved to disk and unloaded (or reloaded again if it comes back into the visible list).

( edit/add: you don't want to aggressively load/unload though, since a player jumping around near the middle of a region would cause considerable loading/unloading, so a list with maybe 16 regions is better, but with only the nearest 4 being "active", and drive loading/unloading via minimum and maximum distances, say, force-load if distance<192 meters, and unload at between 768 and 1536 meters. likewise, if the engine has "chunks", but the unload radius may be smaller. )


within each region (apart from voxels), objects are sorted according to a dynamically build BSP-like structure.
this tree is rebuilt as objects are added/destroyed or move around.
the advantage of a tree like this is that it allows quickly answering questions like "what is the nearest X" or "is there anything in this particular area of space?", without needing to check against every object in the scene.

say, an object is running or falling, do we really want to check against every object in the scene every tick? typically not.
a tree allows quickly identifying and eliminating the vast majority of objects for which there is no chance of colliding with them.

however, this tree is not directly regarded as part of the object (in the same sense as parent/child relationships), but is more sort of a "behind the scenes" type thing, and as an object moves around, the tree might change around under it, or if it crosses a region boundary might actually jump from one BSP to another.

most entities and similar are otherwise treated as more-or-less a flat list. typically, there are not any explicit parent/child relationships, but some relationships may exist informally (for example, projectiles remember who fired them, AIs/NPCs remember who their current enemies are, ...).

during run-time, each entity may also be assigned an "ID number" used to identify it (like, over the network protocol), but this ID number is not persistent.


note though that there is not actually a single unified list of objects for the entire engine, but rather there may be around 4 of them:
the server-side scene-graph, which basically tracks all world objects (and runs all the AI, physics, ...);
the physics-engine graph, which mostly just deals with objects using fancy physics (otherwise, the physics engine is idle);
the client-side scene-graph, which basically contains whatever entities the server is telling the client about (the locally visible collection of entities, which basically holds information like each objects location/velocity/model/frame/effects/...);
the renderer's "modelstate" list, which mostly keeps track of currently-visible scene objects (this may include things like the instance of an entity's skeletal model, its current bone positions, per-frame vertex/normal and triangle-face arrays, ...).

so, for example, if an entity exists on the client, it may be given a modelstate if it is potentially visible, but may not get a full state until it is determined "actually visible" by the renderer (is uses a special visibility-determination pass, employing various checks to try to determine what is/is-not relevant to the current visible scene), and an entity wandering off-camera may well have its modelstate destroyed (the modelstate graph is thus highly volatile, and in some cases the renderer may destroy it at-will, forcing the client-end logic to rebuild it).


the reason for different lists is that they exist in different parts of the engine and deal with different information.
for example, the server-side entities contain lots of fields that have no relevance to the renderer;
and, the renderer contains lots of fields that have no relevance to AIs or physics;
and, for example, the client-side scene-graph knows a model by its model-name, and largely manages communication with the server, whereas the renderer's modelstate knows it via an instance pointer and internal (model-type specific) vtables (and non-visible objects are never given a modelstate);
...

well, and also because my engine is mostly broken up into multiple DLLs, and I prefer not to share structures between different libraries.


or such...

What is making my decision harder is that I don't know what the physics engine will do.(I guess bullet physics)

I'm not sure what it's causing you trouble here. Physics representation must totally be separate from others.

It is worth noticing that for anything that is not a dynamic object (Bullet slang) the physics does absolutely nothing, in the sense the objects will stay still by themselves.

Kinematic objects do move according to application, not physics.

You'd then tell Bullet what rigid bodies are attached to each other (parent/child relationships).

Actually no, they are not parent/child relationships. There's no such thing as a "parent" rigidbody. Connecting rigidbodies by a constraint gives them equal rights.

I actually read a lot of possibly premature optimizations in this thread. Last poster even takes a stab at streaming, client-server architectures and such. My personal suggestion is to use iterative design. Add features after you have the need for them. You cannot design a solution for a need you don't understand.

Actually, my "scene" is a std::vector of batches. Yes, you read it right. I don't even need to make it hierarchical. Yes, I do have problems with my most complex data sets on the lowest end hardware I'm targeting (which is 1st gen Intel Atom FYI). Realistic datasets run just fine.

actually, I was mostly describing how my engine works, as an example...

granted, it does itself use a client/server architecture (both in single and multiplayer), and loads/saves parts of the world dynamically.

actually, in this whole design, the server end is the main authority (pretty much everything on the client-end is streamed over from the server).