[x3d-public] Fwd: web3d MMO > Sensor sharing via DIS

Sun Jun 18 15:02:10 PDT 2023

On a WebGL app, i have mouse clicks/drags going to WebGL.  I believe input
text can be handled through gaining keyboard focus (onfocus event) in a
text field or text area.

While i have written a text field-like thing, see: src/main/data/pp3.x3d in
https://github.com/coderextreme/X3DJSONLD , i am unaware if it’s currently
working or not. As I recall, my extrusions were not working in X3DOM (see
qq3.x3d for extrusion test case.)

TextArea in X3D seems like a lot of work, but I’ve done some work in my
jsondemons repo, with X3DOM, I recall.  The app is pretty inscrutable, but
I might be able to record a demo.

In LIRCom, one could have channels and users in same menu.  Consider a
channel a subclass of user.  Or do what Discord does (it’s a web app
deployed as a native app, AFAIK).

LIRCom is a mess, but check out Channel.java and Kanal.java (Danish for
Channel).  Once a channel sends you a message on join, it’s in your contact
menu (temporarily).  One can have lists of destinations in a message.

It’s been years since i put significant effort into chat, I plan on
revamping the GUI with JavaFX.

If I recall right, VRChat is already linked to Discord.

I’m not really doing any work these days, pull requests welcome.

John

---------- Forwarded message ---------
From: GPU Group <gpugroup at gmail.com>
Date: Sun, Jun 18, 2023 at 3:21 PM
Subject: Re: [x3d-public] web3d MMO > Sensor sharing via DIS
To: John Carlson <yottzumm at gmail.com>

Destination and source are in the header part.  The most detailed specs I
have:
https://freewrl.sourceforge.io/tests/28_Distributed_interactive_simulation/1278.1-200X%20Draft%2016%20rev%2018.pdf

5.6.5.13 Comment PDU
- there's a header part that all Pdus have, and then variable datum records
So it would just be the chat data going into the variable datum records
6.2.19 Datum Specification record
And there's a separate numberOfVariableDatumRecords to say how many
records, and then within each record there's a small header that says how
many 64 bit chunks in the record. So there's lots of room for very long
chat lines.
Lets say your chat line is "Hey what do you think of my art work?" That's
36 chars + \0 = 37 bytes x 8 bits = 286
296/64 = 4.625, rounding up you would need 5 64 bit chunks, so your
variable record length would be 5.
Q. in a web3d browser, how to indicate your keyboard message is intended as
a chat message, and not navigation or other keyboard use?
Would the browser need a separate window / box not part of the scene, and
click the mouse in the box before typing?
Would chat messages be for everyone, or if for a specific other player, how
indicate which player? Would you click on their avatar in the scene, or
would the chat window/panel have something to click?
-Doug

On Sun, Jun 18, 2023 at 12:33 PM John Carlson <yottzumm at gmail.com> wrote:

> My understanding of your explanation is there are some number of 64 bit
> chunks in a single CommentPdu.  I would have trouble fitting destination
> and perhaps source routing into 64 bits, and i don’t know how to deal with
> multiple interleaved Pdu messages yet.  Currently, there’s no validation of
> nickname in chat parlance in my apps.  Recording source, route and
> destination should be sufficient, in my opinion.
>
> I have fields like date-time so i can toss messages that have been in the
> network for too long and message order integer from a source to prevent
> duplicates.  Also source language for chat.  Some of these are probably
> handled by DIS.
>
> I’m thinking i could use a boolean or numeric for a continuation flag.
>
> On Sun, Jun 18, 2023 at 12:58 PM GPU Group <gpugroup at gmail.com> wrote:
>
>> Yes CommentPdu contents arbitrary --can be anything you can pack into the
>> records. The entity 33 is my signal to the receiving app to parse it as
>> sensor events, and if you had another use for CommentPdu you could signal
>> it to be parsed differently in a similar way, or have a standard to put the
>> parsing information in the first record or some technique like that. Its
>> binary data, in 64 bit chunks, so if you wanted it to be interpreted as
>> character data like Chat text, you'd signal that by one of those variables
>> so the receiving app would know how to parse it. That means all the apps
>> participating in an exercise would need to know the signals and how to
>> parse.
>>
>> On Sun, Jun 18, 2023 at 11:42 AM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> Oh, i thought your SensorEvents in a CommentPdu was outside the DIS
>>> standard.   That is, i thought the “body” of a CommentPdu was arbitrary.
>>>
>>> Let me know otherwise.
>>>
>>> John
>>>
>>> On Sun, Jun 18, 2023 at 11:30 AM GPU Group <gpugroup at gmail.com> wrote:
>>>
>>>> Those are nice videos John, artistic.
>>>> I think the DIS is bureaucratic with all its parameters, and if there's
>>>> a standard some day for what of those we use in web3d for what, it won't
>>>> take much work to change.
>>>> -Doug
>>>>
>>>> For the Avatar viaEspdu (EntityState), I made category 77, and EntityID
>>>> == applicationID
>>>> espdu->entityType.category = 77; //SPECIAL CATEGORY 77 FOR AVATARS
>>>> espdu->entityID.entity = fwl_get_DISapplication(); // application 1:1
>>>> avatar, entity = f(application)
>>>> espdu->entityID.application = fwl_get_DISapplication();
>>>> - but there wasn't much processing difference (yet) on the receiving
>>>> end for avatars - just regular EspduTransform
>>>>
>>>> For SensorEvents via CommentPdu I made Entity 33 to signal SensorEvent
>>>> comment (but currently don't check it when reading)
>>>> cpdu->mySimulationManagementFamilyPdu.originatingEntityID.entity = 33;
>>>> //can be a code for sensors
>>>> cpdu->mySimulationManagementFamilyPdu.originatingEntityID.application =
>>>> fwl_get_DISapplication();
>>>> cpdu->mySimulationManagementFamilyPdu.originatingEntityID.site =
>>>> fwl_get_DISsite();
>>>> Because neither Avatar nor SensorEvents has a DIS node just for them, I
>>>> rely on command-line settings for site and application. When running
>>>> multiple instances, I increment the application number.
>>>>
>>>>
>>>> On Sat, Jun 17, 2023 at 7:20 PM John Carlson <yottzumm at gmail.com>
>>>> wrote:
>>>>
>>>>> Here’s the LIRCom demos:
>>>>>
>>>>> https://youtube.com/playlist?list=PLTS-0xyjagy-ZJ8vnR9SfeKfYJM6qMQEO
>>>>>
>>>>>
>>>>> Perhaps we should consider standardizing subclasses of CommentPdu?
>>>>>
>>>>> I can think of one attribute extension off the top of my head,
>>>>> “domain,” like Solitaire/Cards, 3D-Edit or Chat.  Currently, these all ride
>>>>> on the same “bus.” DIS Federation is important, “channels” currently
>>>>> implemented as Entities????
>>>>>
>>>>> Thanks!
>>>>>
>>>>> John
>>>>>
>>>>> On Sat, Jun 17, 2023 at 8:00 PM John Carlson <yottzumm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> https://github.com/coderextreme/lircom
>>>>>>
>>>>>> Wondering how to “port” or rewrite LIRCom in DIS+CommentPdu.
>>>>>>
>>>>>> See:
>>>>>>
>>>>>> https://github.com/coderextreme/lircom/blob/master/src/main/java/lircom/Message.java
>>>>>>
>>>>>> For what might be considered “core” messaging protocol.
>>>>>>
>>>>>> Demo apps:
>>>>>>
>>>>>> I’ve been considering Fediverse/ActivityPub, but if there are enough
>>>>>> platforms running DIS and CommentPdu, that would make the platforms good
>>>>>> for implementations.  Are there Java DIS+CommentPdu implementations?
>>>>>>
>>>>>> Buffering up comments is very interesting to me!
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On Sat, Jun 17, 2023 at 7:46 PM John Carlson <yottzumm at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Interesting, i had considered using CommentPdu in my own apps, but
>>>>>>> I’m a bit freaked out by DIS/VPN/multicast.
>>>>>>>
>>>>>>> I will view the video soon.
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>> On Sat, Jun 17, 2023 at 5:12 PM GPU Group <gpugroup at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> MMO - massively multiplayer online
>>>>>>>> DIS distributed interactive simulation - a web3d component 28
>>>>>>>> CONCEPT: web3d browsers load identical scenes, and share sensor
>>>>>>>> events, and each instance does its own routing diagram after sensor event
>>>>>>>> is shared.
>>>>>>>> https://freewrl.sourceforge.io/tests/28_Distributed_interactive_simulation/elevator/MMO_Sensor_sharing.mp4
>>>>>>>>
>>>>>>>> - 2 instances of freewrl with DIS activated, showing same
>>>>>>>> elevator3.x3d scene
>>>>>>>>
>>>>>>>> https://freewrl.sourceforge.io/tests/28_Distributed_interactive_simulation/elevator/
>>>>>>>> - in video we can see avatar of other instance as green cone
>>>>>>>> - when current scene clicks elevator up button, it relays that
>>>>>>>> sensor click event to other app instance, which triggers the elevator in
>>>>>>>> the other scene to go up at the same time
>>>>>>>> - the avatar in the other scene rides its elevator up, and sends
>>>>>>>> its new avatar pose to the current scene, so appears they are riding up
>>>>>>>> elevator together.
>>>>>>>> - the code sensor intercept point is general enough to capture
>>>>>>>> TouchSensor, GeoTouchSensor, LineSensor, PointSensor (not web3d spec),
>>>>>>>> PlaneSensor, MultiTouchSensor (not web3d spec), CylinderSensor,
>>>>>>>> SphereSensor, ProximitySensor, GeoProximitySensor, Anchor.
>>>>>>>> - it broadcasts sensor events to other app instances via DIS
>>>>>>>> CommentPdu, which has variable number of variable-length records. All
>>>>>>>> sensor hits on a frame are queued, and when processing dis send events, it
>>>>>>>> reads the queue and packs into a single CommentPdu and broadcastes.
>>>>>>>> - other app instances once per frame in dis_receive function parse
>>>>>>>> the pdu stream, and direct all CommentPdus to the pdu2sensor function,
>>>>>>>> which iterates over the CommentPdu variable records and calls the
>>>>>>>> appropriate sensor functions for each sensor event.
>>>>>>>> -Doug
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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/20230618/70efc066/attachment-0001.html>