"scene tree" should be a "scene forest"

[3b]

lexicon describes

scene tree: A directed acyclic graph that denotes the hierarchical coordinate frame relationships between transform components held by actors.

It might be better to have the basic concept be a "scene forest", where the identity root node is either implicit or represented specially.

If there is a single tree, everything needs to have meaningful coordinates relative to each other purely for the purposes of making the tree coherent, even if there isn't any inherent geometrical relationship between the subtrees.

For example, a security camera might show an otherwise inaccessible room, or a level might be split into multiple disjoint areas that can only be reached by teleports. With a single tree, those areas all need to be moved to non-overlapping areas within the single "scene" space.
With a forest, they could each stay at their natural origin.

benefits:

• no need to manually decide where to put them
  • not much work, but still more than 0
  • risks bugs if someone expands the level and they start overlapping
  • risks numerical issues if the pieces are big
  • risks problems if any code makes assumptions about where the piece would be in the level and it ends up moving.
• engine doesn't need to filter/cull/etc the independent parts
  • for example the pass rendering the security camera never sees the 'main level' subtree, and main camera never sees the 'inaccessible room' subtree
    Again, maybe not much work, but still more than 0. (And less risk of accidentally being lots of work if some edge case like not-quite-watertight geometry breaks the usual optimizations)
  • similarly physics should be independent for each subtree
    Hopefully O(log(n)) on average to reject the other subtrees with single root, but still more than O(0).
• could make it easier to cache things like interiors?
  In an open-world game where building interiors are created/loaded on demand while keeping the outside loaded, if they are all loaded into separate trees, it doesn't matter how many you keep cached. If they need to be non-overlapping in a single tree, space and placement would become an issue.

downsides:
(though devs can still put everything under 1 tree if that works better for them)

• possibly more work to move things between subtrees than within a single tree?
  Spatial index / physics acceleration stuff would probably be most expensive part though, and that would probably be mostly the same either way.
  • to some extent this is just trading per-frame culling/filtering/etc work for per-teleport work, and probably averages out to less

issues:

• editor needs some easy way to show all the pieces being used for a level, either in separate tabs/windows, or possibly temporarily placing things "outside" the level as would be done with a single tree.

orthogonal things:

• portals
  • most ways it would interact with a portal renderer apply for either model. You need to be able to move things between arbitrary nodes in the forest, or render things starting from arbitrary nodes (with possibly arbitrary modifications to transforms per portal).
  • main semantic complication is that it is less clear what are "disjoint" areas when portals are involved. At an extreme, any 2 areas connected only by portals could be considered disjoint, and so could be separate subtrees. In practice most devs would probably author much larger areas as a single tree, and separate trees would only be used for cases where they are "teleport" portals as opposed to "doorway" portals.

[psilord]

Other uses would be things like menus and whatnot that are outside of the game world, or possibly an entire Colony IDE in the game world with a special root node for the app's geometry that places it into a subwindow in the IDE. Turning on and off the IDE en toto would be a trivial task then.