[x3d-public] Multiplayer strategies

[Valentin Christoph]

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-0001.html>