You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature is to introduce the idea of a "layer" number to each media element in hubs and spoke. (Layer may or may not be the right term, but will use it for here.) The layer is a number, and when using hubs there is exactly one active layer. The active layer can be set by the owner or any promoted user. When users pin objects, they are added to the active layer.
The goal of this feature would be to enable the following use cases:
Dynamic presentations or tours - you could create several layers to give a talk (spawning in/out media)
Ease of clearing all objects, or 'saving' sets of objects
The ability to use room as long term collections, which can support storage of hundreds of media
Improving the story on low end devices: instead of having a ton of media in the room, break it up into layers
One question around this is how it interfaces with scenes. My suggestion to keep it simple would be that media in both scenes and rooms would have a layer (in room, the layer is only relevant when the object is pinned.) The objects in a room that are seen when a layer N in active is the union of the scene's media on that layer as well as the pinned objects on that layer.
Alternatively, layers could be a hubs-only concept, but this would prevent the re-usability of layers across multiple rooms. One problem with that idea is if we ever have hubs -> scene export, it's unclear what is to be done with the layers. (Presumably today without layers, all pinned objects would be populated into the exported scene.) Another question is if the scene selection itself should or shouldn't be considered part of the layer. For example, if you wanted to give a talk, one could imagine it being necessary to transition scenes as you move through the preso (though perhaps not every layer change would warrant a scene transition.)
Another implementation detail is what layers actually do under the hood, we could:
Completely avoid loading anything related to non-active layers
Load, but not spawn objects from inactive layers
Load and spawn, but disable rendering for objects from inactive layers
Each of these had tradeoffs, to me it seems like loading (ie downloading) but not spawning objects from inactive layers seems like a nice balance in terms of complexity, efficiency, and UX. Another bit of complexity comes from the fact that some media, like videos, need to transition play state and other on-object state as layer transitions happen.
This feature is to introduce the idea of a "layer" number to each media element in hubs and spoke. (Layer may or may not be the right term, but will use it for here.) The layer is a number, and when using hubs there is exactly one active layer. The active layer can be set by the owner or any promoted user. When users pin objects, they are added to the active layer.
The goal of this feature would be to enable the following use cases:
One question around this is how it interfaces with scenes. My suggestion to keep it simple would be that media in both scenes and rooms would have a layer (in room, the layer is only relevant when the object is pinned.) The objects in a room that are seen when a layer N in active is the union of the scene's media on that layer as well as the pinned objects on that layer.
Alternatively, layers could be a hubs-only concept, but this would prevent the re-usability of layers across multiple rooms. One problem with that idea is if we ever have hubs -> scene export, it's unclear what is to be done with the layers. (Presumably today without layers, all pinned objects would be populated into the exported scene.) Another question is if the scene selection itself should or shouldn't be considered part of the layer. For example, if you wanted to give a talk, one could imagine it being necessary to transition scenes as you move through the preso (though perhaps not every layer change would warrant a scene transition.)
Another implementation detail is what layers actually do under the hood, we could:
Each of these had tradeoffs, to me it seems like loading (ie downloading) but not spawning objects from inactive layers seems like a nice balance in terms of complexity, efficiency, and UX. Another bit of complexity comes from the fact that some media, like videos, need to transition play state and other on-object state as layer transitions happen.
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: