<html>

 <head>

  <meta name="viewport" content="width=device-width">

  <meta http-equiv="Content-Type" content="text/vnd.ui.insecure+html;charset=utf-8">

 </head>

 <body style="overflow-wrap:break-word; word-break: break-word;"><div class="mail_android_message" style="line-height: 1; padding: 0.5em">And we had already enough discussions about "DIS vs. NSN".<br/><br/>I would say, for the time being we should prefer DIS, because the protocol is ready defined and gurantees interoperabiliy among different Web3D browsers.<br/><br/>The NSN might be "something for the future".<br/><br/>--<br/>Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.</div><div class="mail_android_quote" style="line-height: 1; padding: 0.3em"><html><body>Am 03.06.23, 19:24 schrieb Christoph Valentin <christoph.valentin@gmx.at>:</body></html><blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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

  <br> 

  <br> 

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

  <br>  

  <br>  

  <br> 

  <br> Gesendet: Samstag, 03. Juni 2023 um 18:52 Uhr

  <br> Von: "GPU Group" <gpugroup@gmail.com>

  <br> An: "Christoph Valentin" <christoph.valentin@gmx.at>

  <br> Cc: "X3D Graphics public mailing list" <x3d-public@web3d.org>, "Kevin" <klw71@yahoo.com>

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

  <br> 

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

  <br>   

  <br> 

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

  <br> 

  <br> Hi Doug,

  <br> 

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

  <br> 

  <br> Why? See a) to c)

  <br> 

  <br> 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?)

  <br> 

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

  <br> 

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

  <br> 

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

  <br> 

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

  <br> 

  <br> - engine

  <br> - steering

  <br> - jet engine

  <br> - and so on

  <br> 

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

  <br> 

  <br> Just my 2 cent

  <br> 

  <br> Kr,

  <br> CP/V

  <br> 

  <br> --

Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.

  <br> Am 03.06.23, 17:07 schrieb GPU Group <gpugroup@gmail.com[mailto:gpugroup@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.

  <br>  

Would that work?

  <br> -Doug 

  <br> 

  <br> On Sat, Jun 3, 2023 at 8:03 AM GPU Group <gpugroup@gmail.com[mailto:gpugroup@gmail.com][mailto:gpugroup@gmail.com[mailto:gpugroup@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?

  <br> Thanks,

  <br> 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?

  <br>  

  <br>  

  <br>  _______________________________________________ x3d-public mailing list x3d-public@web3d.org[mailto:x3d-public@web3d.org] <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>

  <br> 

  <br> _______________________________________________

  <br> x3d-public mailing list

  <br> x3d-public@web3d.org

  <br> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>

  <br> 

 </blockquote></div></body>

</html>