Background / Low Resource Mode

[misslivirose]

Is your feature request related to a problem? Please describe. Currently, Hubs provides (up to) three mechanics for being present in various forms in a Hubs room:

• Chat-only presence in a bridged Discord room, with ability to view media added to the room but not interact with it
• Audio, chat, and view-only presence in the lobby of a room
• Full presence with avatars in a room

However, there are scenarios where users may want to be in a 'background' mode that provides synchronous access to the audio in a room while not using rendering resources. This is especially helpful for users who are on the go during a meeting and want to listen in, but may not want to use additional device resources (data, power) to render the scene and avatars.

Describe the solution you'd like When entering the lobby, in addition to the view-only mode, Hubs could have an additional "listen-only" mode that would cut out rendering. It should have a route back into the lobby so that the user could decide to enter in fully present. Their display name should appear as a lobby user. Optionally, chat could still be enabled in this mode.

Additional context The use case of having a Hubs room open in a background tab seems to be quite common and is easy to handle on powerful computers but is a resource drain unnecessarily on other types of devices.

┆Issue is synchronized with this Jira Task

[johnshaughnessy]

I suggest making this mode available from within the room as well, so that you can have a light-weight hubs session open while talking with people in a room and doing something else on your device. Perhaps we can show an icon like an eye mask (or something that looks less like a VR headset, which might be misinterpreted) in the user's nametag (like the admin badge).

or

Edit: Woops, I did not realize those images were so big.

[misslivirose]

Great point - do you think that should be two modes (renderless lobby and renderless scene) or just have it be a function of being in a room but mimicking more of a video call style interaction?

[johnshaughnessy]

If I imagine this as a second "full screen view" on the room that a user could take, and maybe video call style interaction would make a third "full screen view". For a first pass, I think disabling the render loop (while in the lobby or the room) would significantly decrease the cost of running hubs. Pausing other systems may be a good idea in this mode too, but there may be such a perf gain from not rendering that doing that alone might be good enough to release. We will have to try it to find out.

Things like chat, the user list, the object list and audio controls still seem useful in this mode to me, but I'm not sure if there are perf or ux benefits to hiding them in this mode.

I suspect we will still spend the resources required to keep the room state up to date (and we could do less work here too, by disabling interpolation or running tick less frequently), so if we knew a way to render a "simplified view" cheaply this might be better than rendering nothing at all.

One issue might be that the app doesn't "slow down" when there's nothing to be done - instead it may submit a blank frame and then run again as soon as possible when the browser is ready for another animation frame. We may have to do a little work to purposefully slow down the app. (Up until now the app is only slow by accident! :joy: )

[blairmacintyre]

I think @johnshaughnessy's comment is important

One issue might be that the app doesn't "slow down" when there's nothing to be done - instead it may submit a blank frame and then run again as soon as possible when the browser is ready for another animation frame. We may have to do a little work to purposefully slow down the app. (Up until now the app is only slow by accident! 😂 )

A low resource mode cannot run a full webgl/webxr rAF a full speed; we may want to consider a "2D view" that is more "webby" (i.e., implemented entirely in React or whatever) with no 3D at all.

One question would be if there could quite literally be a 2D overhead view in such a mode, so you could still get some spatialization, etc., by moving near others. BUT, this seems difficult as it wouldn't work in general, and would require figuring out how to represent the "2D folks" to the 3D folks. I suspect this would only make sense in "flat" spaces (e.g., one level, no flying).