<div dir="ltr">Requirements for Mutli-Player system:<div>1. every player should be able to open / close a door / operate touch sensors</div><div>2. other avatars, and 1st person arms, rendered</div><div>3. option: survive elevator test - other and 1st person avatars should ride up on animated elevator or ride cart, not fall through floor (re-parenting?)</div><div>4. ability to communicate 2-way > a function of range a) vocally, b) writing/chat</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 3, 2023 at 8:03 AM GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</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"><div dir="ltr">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?<div>Does anyone have their web3d browser working as multi-user?</div><div>Is/are there a/some convenient choke-point/s to catch and distribute state changes?</div><div>Thanks,</div><div>Doug</div><div>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.</div><div>DIS component is more intrusive / works on specific scene content / not general, (but has detailed peer2peer connectivity design).</div><div>Web3d browsers have been traditionally designed around single user. How hard is it to change them to multi-user?</div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div>