[x3d-public] Metaverse > Multiuser web3d-browser > how sync state?

[Christoph Valentin]

maybe it's not a decision of either/or.


maybe we need to support all three options, depending on the actual use case 
 
 

Gesendet: Samstag, 03. Juni 2023 um 18:52 Uhr
Von: "GPU Group" <gpugroup at gmail.com>
An: "Christoph Valentin" <christoph.valentin at gmx.at>
Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>, "Kevin" <klw71 at yahoo.com>
Betreff: Re: [x3d-public] Metaverse > Multiuser web3d-browser > how sync state?

Thanks Christoph. I'll review DIS. (FreeWRL has DIS component). I seem to remember DIS being a bit bureaucratic. 
  

On Sat, Jun 3, 2023 at 9:55 AM Christoph Valentin <christoph.valentin at gmx.at[mailto:christoph.valentin at gmx.at]> wrote:

Hi Doug,

Imho, the scene author should be involved in the decision, whether a scene will be "multiuser-capable" or not.

Why? See a) to c)

a) Theoretically, there might be the possibility of a "browser intrinsic" multiuser capability, as you describe it below - when multiuser function is defined for each and every sensor node and some "MU infrastructure" is defined by the X3D standard, but I guess, nobody has ever tried this (am I right?)

Getting back to your question: imho, it *could* work

b) as far as i know, DIS is well-known by scene authors, however the NSN (network sensor node) might be a similar approach

I.e. -> the scene author has to care for synchronization of each and every entity/state

c) one could "wrap" the DIS/NSN functions with their own nodes, providing a "framework" of more specialized functions, like

- engine
- steering
- jet engine
- and so on

Thus, the model author would just "equip" their models with some "functionality" and need not think about "MU yes or no" in detail.

Just my 2 cent

Kr,
CP/V

--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 03.06.23, 17:07 schrieb GPU Group <gpugroup at gmail.com[mailto:gpugroup at gmail.com]>:
PEER-SENSOR-COMMUNICATION: for file-loaded-identical scenes, mouse and keyboard inputs that aren't consumed locally would be caught by sensor nodes as usual - keysensor, touchsensor, dragsensor. And these nodes would communicate to peers directly or via server, to the same sensor in peers, in sensor-local coordinates, and those peer sensors would act like they had received local touches/keys . TimeSensor time would be sychronized on startup, and left to run. Conceptually there are event source, processing, and destination nodes, and this design would share the source-events only, and the rest of the routing would be done on each client.
Drags and keys consumed locally for navigation would also be sent to peers in world (or for arm motion, avatar-specific) coordinate system to move the client-specific peer avatar.
 
Would that work?
-Doug 

On Sat, Jun 3, 2023 at 8:03 AM GPU Group <gpugroup at gmail.com[mailto:gpugroup at gmail.com][mailto:gpugroup at gmail.com[mailto:gpugroup at gmail.com]]> wrote:
Assuming there's some method to transmit efficiently, how to keep non-avatar states synchronized when there are timeSensors, particlePhysics, touch and dragSensors, scripts etc - a lot of places where states can change?
Does anyone have their web3d browser working as multi-user?
Is/are there a/some convenient choke-point/s to catch and distribute state changes?
Thanks,
Doug
Avatar state changes seem more straightforward, with 1 avatar per other-user joined (and arms for 1st person avatar), easier to keep track of quantity.
DIS component is more intrusive / works on specific scene content / not general, (but has detailed peer2peer connectivity design).
Web3d browsers have been traditionally designed around single user. How hard is it to change them to multi-user?
 
 
 _______________________________________________ x3d-public mailing list x3d-public at web3d.org[mailto:x3d-public at web3d.org] http://web3d.org/mailman/listinfo/x3d-public_web3d.org