This is not the scene manager’s job; the scene graph is an implicit nature of the actors in the scene.
It's job is also to handle the transformation hierarchies of objects and the camera.
Actors themselves can be parents and children of other actors. Actors themselves manage how a parent transform affects their own transforms, etc.
The scene manager will issue a “pre-update” call to each actor, which actors can use to calculate their final transforms taking their local transforms with their parents’ transforms, but to the scene manager this call is a black box. The actors could use it to make spaghetti for all the scene manager cares.
In addition to what has already been said, I would point out that there is no reason to restrict yourself to having only a single scene at a time.
I real-life example that I had where 2 scenes would be the best solution was in a golf game I made in which you spend most of your time on the 3D field, but for swinging the club the golf course is shrunken to fit a certain area of the screen and a 3D guy swinging a club is overlaid on top of it with a different set of projections and view transforms.
Render-queues are a good way to sort objects for rendering inside a single scene, but if we are talking about overlaying the UI, debug text, etc., then you would really want layers.
Usually engines have a fixed and predefined set of layers, each intended to render a specific part of the scene.
Usually there are about 16 layers, but most of them are blank or “reserved” for future use.
An example of a simple set of layers would be:
Layer 0: Player.
Layer 3: Solid 3D objects.
Layer 5: Terrain.
Layer 7: Skybox.
Layer 8: Translucent 3D objects.
Layer 10: Post processing.
Layer 12: UI/HUD.
Layer 15: Debug text.
Layers are drawn in order, so later layers are drawn on top of earlier layers.
The way each layer is drawn is custom. The 3D layers would use render queues, but the terrain layer would use a system specific to terrain (chunks, GeoMipmaps, etc.), and the skybox layer would just be a single standard draw call.
Too bad. That is what you do. If it is slow, it is probably because you are using glBegin() etc., and are otherwise non-optimal.
- Redrawing the entire scene from scratch is very slow
The solution isn’t to try redrawing only what has changed, the solution is to fix the actual bottlenecks.
Issue calls on a per-frame basis. Never assume anything about any future Nth frame. You don’t know when the player is going to hit the button to go to the next stage and all your assets need to be unloaded or exchanged.
The idea is that the scene system would accept requests to have things drawn, either once (during the next frame), or until the drawn object's lifetime runs out (i.e. next N frames).