<div dir="ltr">Thanks Christoph. I'll review DIS. (FreeWRL has DIS component). I seem to remember DIS being a bit bureaucratic. <div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 3, 2023 at 9:55 AM Christoph Valentin <<a href="mailto:christoph.valentin@gmx.at">christoph.valentin@gmx.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Hi Doug,<br>
<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>
<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>
--<br>
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.<br>
Am 03.06.23, 17:07 schrieb GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>>:<br>
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.<br>
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>
 <br>
Would that work?<br>
-Doug <br>
<br>
On Sat, Jun 3, 2023 at 8:03 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>[mailto:<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>]> wrote:<br>
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?<br>
Does anyone have their web3d browser working as multi-user?<br>
Is/are there a/some convenient choke-point/s to catch and distribute state changes?<br>
Thanks,<br>
Doug<br>
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.<br>
DIS component is more intrusive / works on specific scene content / not general, (but has detailed peer2peer connectivity design).<br>
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 <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>