[x3d-public] Multiplayer strategies

Thu Mar 7 05:02:15 PST 2019

Hi Christoph,

I admit that it is somewhat uncomfortable to think about single browser MU
requirements but exploring this could be a fertile exercise as it seems
orthogonal to sharing by multiple scene instances.

What constitutes the state of a scene which needs synchronization across
instances ? The main changes which need updating are the progress of time,
and avatar state.

Perhaps it suffices to synchronize avatar generated event cascades and
replay those in the instances ? Would that require an event queue for
recording ?

Another way to think about state synchronization is to have a very complete
description of state and then only with deltas for synchronization and
conflict resolution across instances.

another 2c :)

Andreas

-Andreas

Date: Thu, 28 Feb 2019 16:40:24 +0000
> From: Valentin Christoph <Christoph.Valentin at kapsch.net>
> To: Andreas Plesch <andreasplesch at gmail.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Multiplayer strategies
> Message-ID:
>         <
> VI1PR03MB47038C7653CE09362D433D3EE4750 at VI1PR03MB4703.eurprd03.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Andreas,
>
> Maybe another 2 cents from my side.
>
> If we want to keep it simple, we should keep a 1:1 relationship between
> user and scene graph (I call this the ?personal scene instance? PSI).
>
> Why? Two reasons.
>
> (1) Maybe the scene consists of many ?modules?, which might span a large
> section of the Virtual Universe, an which are loaded and unloaded into each
> scene instance on demand.
>
> One user is ? for some time ? only interested in module A ? so other
> modules need not be loaded in ?his? scene instance ? saving memory and CPU
> resources.
>
> Other user is interested in several modules at the same time --> he will
> need higher performance in his scene instance
>
> So the matter of scalability will be easier to handle, if we keep user :
> PSI = 1 : 1.
>
> (2) The scene might provide different ?views? to different ?users?. One
> user might get a photo realistic 3D graphic, another user might receive a
> topographic illustration of the scene with only symbolic content. Only the
> ?shared state? is the same for all scene instances of a multiuser session
>
> As I said, just my two cent.
>
> All the best.
>
> From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Andreas
> Plesch
> Sent: Thursday, February 28, 2019 4:25 PM
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Multiplayer strategies
>
> 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<
> http://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
> <mailto: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
>
>
>
> The information contained in this e-mail message is privileged and
> confidential and is for the exclusive use of the addressee. The person who
> receives this message and who is not the addressee, one of his employees or
> an agent entitled to hand it over to the addressee, is informed that he may
> not use, disclose or reproduce the contents thereof, and is kindly asked to
> notify the sender and delete the e-mail immediately.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190228/42e8e0ee/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 119, Issue 86
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190307/07ca8e6a/attachment-0001.html>