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

Mon Jun 19 00:07:22 PDT 2023

Note, pp3.x3d contains StringSensor and X_ITE has it, but AFAIK from
looking at local repository, X3DOM does not (lowercase?).  The stand has it
here:

Extensible 3D (X3D), ISO/IEC 19775-1:202x, 21 Key device sensor component
(web3d.org)
<https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/keyDeviceSensor.html#StringSensor>

Unknown if FreeWRL supports it.

I think the code may be broken, it's been years since it worked, will
validate.

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

> 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/20230619/907a5dbd/attachment-0001.html>