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

[GPU Group]

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>
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>:
> 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]> 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
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230603/872375bc/attachment.html>