[x3d-public] Multiplayer strategies

[Andreas Plesch]

Thanks for all the thoughtful response. Various ideas were offered. The DIS
component is dedicated to communication and synchronization between
browsers in a peer to peer fashion but has its own limitations. Outside of
X3D various web technologies such as webRTC, websocket or socket.io exist
which can be used with ad hoc protocols and SAI or DOM based scene
updating. I think Firebase is designed to push realtime updates of a json
store to all connected clients, and could fit well. Synchronization of
multiple avatars and persistent avatar registration on a dedicated service
was suggested.

It is a wide field. To narrow the domain, let's perhaps consider the local,
single game console/browser with multiple controllers and split
screen/multiple headsets case, say up to 4 actors, no servers.
Using a projector or a large TV, there is natural sharing which is
eliminated with HMDs. Replicating the screen, one mode is just mirroring of
a master render to other HMDs but this is very unpleasant in VR. Another
mode is one actor with sensing, and other viewers, passive but still moving
and looking. Another mode is full access to the scene for all locally
connected.

WebXR allows for multiple HMDs and controllers. I am not sure if web
browsers can deal with multiple mice/keyboards but I suspect they can;
there is a gamepad API.

Brainstorming a multiple avatar, client only design:

- a list of render surfaces, for each avatar, perhaps layout, layer related
- a list of active avatars, linked to a render surface
- a way to add and remove an avatar
- an active viewpoint per avatar
- touchsensor, other sensors linked to a list of avatars

Very fuzzy but perhaps a start for thinking about such a case.

I was looking around castle engine for inspiration from a gaming
perspective but could not find much.

It may be that dealing with multiple avatars in a single browser is
actually more complicated than a local one browser per avatar, plus a
synchronized scene from a scene server design which has to deal with
updates to the shared scene, the synchronization, and distribution.

Was there a VRML approach to shared experiences ?

>From a practical standpoint, simply mirroring from a master HMD to a second
connected HMD using webVR in x3dom would be a first step to explore.
And perhaps exploring Firebase, eg. if it can store a json X3D scene, and
how multiple X3DOM or X-ITE instances would receive it, perhaps in an
inline.

-Andreas



On Tue, Feb 26, 2019, 5:33 AM Andreas Plesch <andreasplesch at gmail.com wrote:

> With VR it may become more common to share a live, dynamic experience
> using multiple headsets and controllers. At first glance this seems to call
> for multiple, active viewpoints rendered by a single browser. The layering
> and layout components seem relevant.
>
> Another strategy would be having multiple browsers with identical scenes
> and keeping scenes in sync with an additional process and SAI methods.
>
> What are the strategies offered by X3D to support sharing a live, dynamic
> world ?
>
> This came up as a x3dom GitHub issue and I thought may be more generally
> interesting.
>
> Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190228/7119cbf5/attachment-0001.html>