Multi-scene support

[BearishSun]

Add the ability to have multiple separate scene hierarchies loaded at once. This is useful for tools/editors that need to have preview boxes and similar. Currently similar functionality can be achieved by using layers for rendering/physics filtering but a multi-scene approach would be more intuitive to use and would provide better and less error-prone design.

The implementation would likely involve:

• Frontend - Extend the SceneManager to support multiple scene roots. Each SceneObject should be aware in which scene they are in using some sceneID. We will likely want to prevent scene objects being moved across scenes (as this will likely cause implementation complications with the backend systems and user can just clone the objects nearly as easily if required).
• Backend - Systems that need modification that come to mind are Renderer, Physics and perhaps Audio.
  • Renderer - Renderer internally already works using the concept of scenes through RendererScene. currently there is only one ever allocated but it should be simple enough to create multiple (See RenderBeast). Renderer::notify* methods should then be modified so they work on objects in the appropriate scene using the sceneID. sceneID should probably be part of the SceneActor class since all renderer related objects implement it, and it can be taken from the relevant SceneObject. Then when rendering just iterate over all scenes and things should hopefully just work.
  • Physics - PhysX internally support scenes, but similarly to the renderer we only currently ever create one. This needs more investigating but a likely approach is similar to the renderer - propagate sceneID with relevant physics objects (likely once again through SceneActor) and then just add objects to different scenes based on the ID. Collision filtering and reporting might need tweaks so they also work on per-scene basis. Scene queries will likely need an additional sceneID parameter as well.
  • Audio - Potentially no modifications required, or limit the audio to just one scene.

[christianclavet]

Hi, Is that mean, that we could have ways for example, to manage the preload/unload from a transition from one scene to the other? (as for background loading of scenes, for seamless levels).
I'm not sure reading at your description, as it also seem to load scenes in the background to give live previews of them (I used to create a screenshot to have a preview, but it was static)

[BearishSun]

I mean preview windows like in the Inspector in an editor, where you can see a 3D model, or a material in separate window, purely for preview purposes.

Loading scenes in the background should already be supported using the async loading feature, although I haven't properly tested that yet so it might need some tweaks. I will be enabling async scene loading in the editor fairly soon, for purposes of testing this feature as well as making editor handle scene loading without freezing the GUI.

[jonesmz]

This would be useful for multi-monitor games where each monitor can be a different, totally unrelated, scene. E.g. a map view on one screen, part editor (e.g. mech lab from various Mechwarrior titles, vehicle assembly building from kerbal space program) on a second, and direct character control on a third.

[hhyyrylainen]

I also very much need this feature. So far I'm only using the rendering part so I don't need the physics or audio part of this issue to be fixed. I'm trying to workaround the limitations of a single scene by using layers, but for example, lights, seem to not have a method for setting the layer they are on.

[HeadClot]

Hey - Just thought I would chime in on the physics side of things.

May be worth looking into shifting the scene origin. Since Banshee already uses PhysX we could use the built in function for shifting the scene origin. :)

https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/OriginShift.html

[reductor]

Origin shifting in PhysX can be expensive and "recommend to use it only in the case where distance related precision issues may arise in areas far from the origin.", not to mention the other issues it would cause in specifying offsets everywhere, and doesn't solve the issue of multiple scenes, as origin shifting adjusts the whole scene.

I think it would be ideal to have all APIs associated with the scene, instead of more global like functions where you specify a scene id, this would help create a more clear ownership relationship for scene related systems, it potentially requires more rearchitecting of things but worth the additional cost.

[BearishSun]

Physics system was already refactored to support multi-scene, with most of the global API moved to PhysicsScene and physics objects can take different scene ownership.

What is left is the renderer, which also mostly supports multi-scene, and then it's just a matter of exposing all this to the user through scene objects and the scene manager.