more control over lobby view, perhaps using Waypoints

[blairmacintyre]

Is your feature request related to a problem? Please describe. The current lobby view is a single view with a slow motion. That's problematic if you want to have people stay in the lobby.

Describe the solution you'd like We should be able to control the slow motion (i.e., it's range of motion, perhaps turn it off entirely). And multiple lobby viewpoints would be nice.

Describe alternatives you've considered While chatting with the hubs team, it occured to us that perhaps we can add a "lobby view" checkbox to waypoints, and if there are more then one checked, allow the user to cycle between them in the lobby.

Beyond that, being able to turn off the slow pan, would be great. Perhaps a compromise could be that the slow pan is used until you switch waypoints, at which point there is no more pan. Beyond that, being able to directly control it for each waypoint would be nice, but may not be necessary.

Additional context In the conferencing domain, being able to have people stay in the lobby when the room is full may be required. Until more elaborate approaches to large groups are implemented, controlling the lobby view would be very useful.

For our next conference, IEEEVR, we plan on having multiple video streams per room. So multiple lobby views will be needed. Aside from that, if some people block the lobby view of the important content, multiple views would allow people to move around to get a different viewpoint.

┆Issue is synchronized with this Jira Task

[gfodor]

I suggest we add a room option here to allow fly mode in the lobby (and perhaps a "enter vr mode" button when the main panel is closed.)

[gfodor]

This also could be a site-wide on/off switch, if we think the social system tradeoff is best made by the site administrator for all rooms.

[blairmacintyre]

Yes, I like this. For my use, I'd probably just have an overflow room that allows moving the camera, but has no people in it, so people should go there for "lobby view", and otherwise disable it in rooms where people are ... perhaps?

Is there any way to limit rooms to not allowing people to enter?

Hmmm, no, having empty rooms with people just watching and chatting in text seems pointless. May as well just go to twitch.

Better to just tell people "people in the lobby can be anywhere, so don't assume chat's are private just because you're off alone"

[gfodor]

Yep, the issue you highlight is a big part of the reason we decided against lobby fly mode on hubs.mozilla.com. However, it does seem like a sane trade-off to defer to others (like 3rd party hub administrators) to decide on their own if they think for their use-cases that trade-off in favor of lobby viewers (vs the privacy of room members) is the right one. I agree disclosure is important, i'm not sure how we can work that in exactly. (The best affordance we have right now for such a thing is the tip above the chat box which can be closed.)

The slippery slope here would be to start adding more visual indicators of presence about lobby members, where they are looking, etc, but I think we need to avoid going down that road, since then it reduces down to just having more people in the room effectively and all the set of problems involved in making that work UX/tech wise.

[blairmacintyre]

I think the best path is probably to put lots of detail near the button in the admin console to make sure the admins are aware of the risks, and suggest ways of ameliorating it (such as educating users).

[netpro2k]

We could allow you to position the lobby cam explicitly in spoke. If a scene has a lobby cam defined it would be used instead of the default panning camera we have now. This would allow a scene creator to frame the key elements of a scene (like the video screen and audience) and would not create the freedom of movement design issues discussed above.

Maybe slightly more work but still pretty simple and doesn't alter the lobby semantics very much.

[gfodor]

Wrt having more lobby cam placement, that could work too, some of the reasons I suggested lobby locomotion instead:

• The viewpoints of a room that are relevant are often not single, nor fixed. Ie, if there are multiple screens playing content, or there is Q&A, etc, the single camera mode breaks down quickly for anything behind the 'let me take a peek at what is going on' that is the design intent of the current default camera. Note that Camera Mode addresses this since the camera operator is acting as the director of the camera.

• All other things being equal, adding more glTF components we support is almost always the most long-term expensive option vs other state or behavior, since it results in us having to have future file compatibility and burns in semantic meaning we need to be committed to mapping forward.

• In general, lobby locomotion is likely to solve implicitly more use-cases for people -- if we ignore the social system tradeoffs or UX challenges it's by definition a superset of functionality over a scene-author based approach to camera placement.

[blairmacintyre]

The issue with a fixed lobby camera is that is that if some random room occupant stands in front of the camera, you're hosed.

Also, I've found the lobby cam can be annoying because you hear audio from near it. So people who don't think anyone is near are chatting, and you hear it REALLY LOUDLY.

[gfodor]

A compromise on this between observers and participants that I've suggested before is allowing lobby locomotion (if its enabled) but in the interest of privacy having it have a more 'rubber band' like behavior, where the lobby observer can use WASD controls to move the camera around, but there are extents where they cannot move past and also, if they let go sufficiently long enough, the camera begins to return to the lobby camera origin. You'd have to play around with it a bit, but the idea is to give the lobby users more agency but a) reduce the degree to which they could inadvertently spy on side conversations and b) ensure that if they are not actively watching, the neutral state of a computer with the lobby open can be assumed to be the well-understood lobby camera position.

[gfodor]

Adding to the above, if we did that behavior, and provided scene affordances, that would potentially mitigate 2 of the 3 concerns I had above (the one about glTF being the obvious one regardless if we add it to scene definitions.) If we gave the scene author control over the extent radius lobby observers can move, that would potentially provide a strong hedge against privacy violations, because for those who cared the scene creator could design things in a way where private convos would have dedicated regions designed to be out of range by lobbyists (haha)

[gfodor]

Such a radius could also serve as the often cited audio 'earshot bubble' concept for lobby observers, where they'd be unable to hear people outside that bubble in addition to not being able to move the camera to those locations.

[gfodor]

OK so concretely, how about this proposal:

• We add a new site-wide flag "Allow lobby camera control", off by default

• When on, if users go into the full screen lobby mode, the panning behavior stops and WASD and arrow keys move the camera. The range of the camera is limited to a default radius of tens of meters, and drifts back to the origin of the lobby camera origin. This does mean the Spoke scene author exhibits significant control over this behavior, since the thumbnail vantage point grounds the lobby camera.

I did just realize that my concern about glTF is not warranted: we're already storing a camera position (though its a singleton.) Perhaps the thing to do on the Spoke side is introduce the "preview camera" concept as an object in the scene akin to one of the system objects like the skybox or the floor plan, in lieu of the current method of using the viewport camera position at publish time for the thumbnail. My guess is to support this, you'd want to have a button in Spoke to "set current viewport to preview camera", instead of the usual free-form transform tools to place it. This object in the scene could have the radius parameter needed for tuning the extents lobbyists can move.

[blairmacintyre]

That all sounds good to me ... is it doable in the near future? :) (or can the site-wide flag be done first, if not?)

[gfodor]

Yeah this seems pretty do-able, particularly if we punt on the Spoke bits. The main thing will be to make sure we're collectively OK with expanding the social systems in this direction. My 2c is that if it's off by default, and turned on by the site administrator, given the constraints above it's not a huge breach. (We wouldn't enable it on hubs.mozilla.com either.)

[emclaren]

Just coming in here to say that I agree that the automatically moving lobby camera on hubs.mozilla.com makes it hard for people who are trying to watch from outside of the room. Being able to set multiple viewing points, and turn off the motion would be very helpful for when people are trying to watch something going on inside of a full room.

Another alternative that I would be very interested in, is being able to set up an actual camera in the room, set it to track a presenter, and then broadcast that camera's viewpoint to the lobby. As it is, the camera person has to be paying close attention to the presentation to ensure folks in the lobby dont miss anything if the presenter goes out of view. Further, it means that the designated camera person (who is also often the moderator) can't turn around to see how many folks are in the space, or take screencaptures, because it would interrupt the presentation for the folks in the lobby.