search

microsoft / mixed-reality-extension-sdk

The Mixed Reality Extension SDK enables developers to build 3D world extensions for AltspaceVR, using Node.JS.
MIT License
142 stars 61 forks source link

Feature Request: Player Masking #30

Closed sorenhan closed 5 years ago

sorenhan commented 5 years ago

Need the ability to enable behaviors for one or all users, or possibly user group/teams. Need the ability to enable actors for one user, all users, all users except one, or possibly user group/teams.

must be dynamic (as people join/leave teams) Must support recording+Playback.

some use cases: first person shooter - player sees their own first person rig vs everyone else sees a real 3d model, when players die, they can see everyone? card games - hide cards from anyone but player - but the moment player plays a card, it becomes visible to everyone.

sorenhan commented 5 years ago

137 (single-user actors) would cover the "enable actors for one user" subset of the functionality requested here - especially the " hide cards from anyone but player" scenario

sorenhan commented 5 years ago

This should not change how we synchronize actors - these actors are synchronized across all machines still, it's only about disabling rendering and behavior collision for specific users (physics simulation must still be unaffected, and simulation must still happen).

I see 2 separate mechanisms for this:

  1. UserGroup flags - I imagine this as simple bit mask, set for each actor, and for each user - there are 32 bits, representing 32 groups. each actor has an integer for which user groups should include this actor, and it's and'ed with the user's usergroup flag. If there is no overlap between actor's groups and user's groups, then that actor, and all children recursively are invisible and non-collidable for behaviors. We would probably have a list of default masks (everyone, spectator, participant, team A, team B, team C), Default values for actors: "all" flag, for users: "all|participant|TeamA" flag. 1b. This may be a slight overload, but it could easily be used for low/medium/high quality settings (auto filled in from altspaceVR settings), if AltspaceVR just auto assigns the user a quality setting (go/gear/Daydream=low, pc discrete=high, pc integrated/Quest/2d mobile=medium)

  2. User exclude flag per actor - The actor should also have a "currently excluded" user, which if matching the user, then that actor, and all children recursively are invisible and non-collidable for behaviors. (i.e. follows same rules as when usergroup disables an entity)

sorenhan commented 5 years ago

We would probably want to have 2 separate integers - one for visibility, and one for behaviors. I can see leaving something visible for everyone but not interactable for everyone.

sorenhan commented 5 years ago

There is some overlap in functionality with #30 (as that's also about enabling/disabling different actor components), so plan these together

eanders-ms commented 5 years ago

Since we're getting into implementation details and API design, I'd prefer we didn't use integer bit masks. Application code will read much better if we directly supported named groups/teams/channels/whatever we call them. We can utilize EMCAScript 6's Set class to get all the set operations you mentioned, but it can act on sets of strings.

eanders-ms commented 5 years ago

Let's not assign an owner yet. There's a lot to discuss and iron out.

eanders-ms commented 5 years ago

Assigning back to Steven. Sorry for the churn. We can split some of the network layer responsibilities if necessary. Would be good to start with an API design and get that into a no-merge PR.