[x3d-public] Multiplayer strategies

Thu Mar 7 09:11:15 PST 2019

Hi Andreas,

Please find another 2c inline :-)

All the best
Christoph

Gesendet: Donnerstag, 07. März 2019 um 14:02 Uhr
Von: "Andreas Plesch" <andreasplesch at gmail.com>
An: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Betreff: Re: [x3d-public] Multiplayer strategies

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.
[Christoph:] Agree. Maybe I am just prejudiced, because I started with my project from the MU example on Bitmanagement's Homepage (is it still there?), where they used the "sessionId"(SFInt32) to identify the users and their avatars.
Now, when we think about single browser MU requirements, then the users should rather be identified by "sessionId + userId" (where userId would be a local identifier of a user of the local scene instance).
Next step would be to investigate environment sensors. E.g. touch sensor should not deliver "touchTime"(SFTime) but "touchedByUser"(SFInt32) instead, true? 

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. 
[Christoph:] This depends on the use case. If you had a museum like world(with predefined animation), where only the avatars would interactively move, then you were right.
I prefer to dream of arbitrary animated and/or simulated interactive worlds/universes with moving models (cars, trains, houses, doors,......), where anything could be an avatar (even a locomotive could be an avatar)

Perhaps it suffices to synchronize avatar generated event cascades and replay those in the instances ? Would that require an event queue for recording ?
[Christoph:] What do you mean by "avatar generated event cascade"? I do not understand this term.
When you talk about recording, do you mean LI requirements? I think LI will be a topic, in particular with respect to avatar position, and in particular when it comes to mixed reality.

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.
[Christoph:] I think the complete state must be stored persistently on a server, because anytime a new scene instance can join the session and must receive the complete state for initialization (do you know, how the Network Sensor of Bitmanagement works? I recommend to check it out).

another 2c :)

Andreas

-Andreas

Date: Thu, 28 Feb 2019 16:40:24 +0000
From: Valentin Christoph <Christoph.Valentin at kapsch.net[mailto:Christoph.Valentin at kapsch.net]>
To: Andreas Plesch <andreasplesch at gmail.com[mailto:andreasplesch at gmail.com]>
Cc: X3D Graphics public mailing list <x3d-public at web3d.org[mailto:x3d-public at web3d.org]>
Subject: Re: [x3d-public] Multiplayer strategies
Message-ID:
        <VI1PR03MB47038C7653CE09362D433D3EE4750 at VI1PR03MB4703.eurprd03.prod.outlook.com[mailto: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[mailto: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[mailto: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]<http://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]<mailto: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[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[mailto:x3d-public at web3d.org]
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

------------------------------

End of x3d-public Digest, Vol 119, Issue 86
*******************************************_______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org[http://web3d.org/mailman/listinfo/x3d-public_web3d.org]