[x3d-public] Fw: Avatar Handling / non-standard movementstrategies/ input of key strokes ------ Was: Mac-unawarePageUp/PageDown, Viewpoint list, navigation keys?

[Joseph D Williams]

➢ I was thinking about keyboard input or even about any character stream from external equipment (e.g. game controller)

KeySensor for a ‘standard’ keyboard text entry when the scene can use system? 
Otherwise, communication with external is supposed to be same as if the events were generated internal. 
The external is sending string(s) of x3d SAI events into the live scene, to be processed just like internal events when the external tells the scene to update. There are certain rules about what is acceptable as an x3d SAI event but essentially, if everything works fine, then you can treat external(s) as Sensor or Script node(s) that expect to trade information in the form of x3d SAI [in,out](s).

➢ Text input to billboards e.g. if the billboard has the focus then the avatar stands still and concentrates on the text input.
How does the billboard get focus? Has the user interacted, has author decided? Is the avatar seeing it or are you looking over its shoulder? 
The billboard has a default behavior that can be controlled. There are a couple of different ways to display scene stuffs on and off. Billboard children can be anything, sensors and all. Both billboard and ‘avatar’ can have some built-in and some triggered behaviors. I think best to upgrade to idea of Avatar to Humanoid, then you can get more functionality from the device. 
All of x3d is just a supporting structure for the x3d hanim – True, all the rest of vrml/x3d is done just to create a realistic realtime/yourtime environment for a realistic humanoid having realistic features doing realistic interactions. 

Good Luck, 
Joe

From: Christoph Valentin
Sent: Wednesday, January 23, 2019 2:47 PM
To: Joseph D Williams; Doug Sanden
Cc: x3d-public at web3d.org
Subject: RE: [x3d-public] Fw: Avatar Handling / non-standard movementstrategies/ input of key strokes ------ Was: Mac-unawarePageUp/PageDown,Viewpoint list, navigation keys?

Hi there,

>>>>>Maybe I haven’t looked enough, but I am thinking about Anchors and TouchSensors and Layers?


I was thinking about keyboard input or even about any character stream from external equipment (e.g. game controller)

Text input to billboards e.g. if the billboard has the focus then the avatar stands still and concentrates on the text input. 

I was thinking of mixing the character stream with special control characters ('left', 'right', 'faster', 'slower') . Control characters would support the X3D navigation paradigm. However the scene author could build avatars with custom semantics ('jump', 'punch', ......)

Just associating and phantasizing, of course :-)
-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 23.01.19, 23:21, Joseph D Williams <joedwil at earthlink.net> schrieb:
➢ <field accessType='inputOutput' name='canHaveFocus' type='SFBool' value='false'/>
 
Hi Doug, That is real nice demo (I hope I can find it again) and shows a lot of work and understanding. Maybe I haven’t looked enough, but I am thinking about Anchors and TouchSensors and Layers? 
 
➢ but the avatar gets the focus any time, when no other geometry has the focus, even, if the avatar is invisible currently.
Why then, do I want to treat my avatar like any other piece of the scene? I lose focus if nothing else has focus and avatar not visible, then must be no focus available and browser must show Panic button? In any event, nothing should have focus-power over my avatar… rant rant 
You are doing fine in recommending several layers of automation of select and unselect and taking care of actives and inactives for what might seem to be a specialized application that might be served better as a prototype. I recommend showing some example user code to show how these interfaces are used to aid selection and navigation, even as viewed through the eyes of the avatar, or without the avatar aspect. Especially when you are showing browsers drawing things and working through hierarchies to turn sensors on and off automagically … 
➢ highlighting or by drawing a 2-dimensional "frame" around the geometry.
 
Those two suggestions offer a wide range of options which is why there are no default hlghlighting or selection options for anchors or any environmental.  Compared to html, x3d does not have any style in this at all, and the author has to do it all. Same with other sensors. 
 
Fine Work and Best Regards.
Joe
 
 
From: Christoph Valentin
Sent: Wednesday, January 23, 2019 9:14 AM
To: Doug Sanden
Cc: x3d-public at web3d.org
Subject: [x3d-public] Fw: Avatar Handling / non-standard movement strategies/ input of key strokes ------ Was: Mac-unaware PageUp/PageDown,Viewpoint list, navigation keys?
 
Hi Doug, Hi all,
 
After the latest discussions at the thread "Question VR Cafe + X3D", I am feeling free to explain the intentions behind the below cited proposal from last weekend (e-mail "Avatar Handling / non-standard movement strategies / input of key strokes").
 
Regarding an avatar that rides a locomotive, I was considering two different approaches:
 
1) Human body avatar is moved by the "WALK" paradigm of X3D.
The locomotive contains a "ProximitySensor" and a "Viewpoint" as well as a "NavigationInfo", all of which are moving with the locomotive. Also a <Group> node is contained, which takes the avatar as child. The avatar contains a "Transform" node, whose "translation" and "orientation" are fed by the "ProximitySensor".
 
1.a) The model of the locomotive has got touchable controls ("faster", "power up", "whistle", ......), which are used to control the model.
 
2) As soon as the avatar is attached to the locomotive --> use key strokes to directly control the locomotive
Thus the "combined" avatar "locomotive + human body avatar" becomes the "real" avatar, which takes the input from the keyboard (or from somewhere else)
I am not "riding" the locomotive, but I "am" the locomotive
 
I followed approach (1), but now, when it might come to having "real cockpit" and "virtual cockpit", I am not sure, whether approach (2) wouldn't be better.
 
Just to have it nailed down on the mailing list :-)
 
Kind regards,
Christoph
  
Sorry for writing so many e-mails for just one idea. Now I have seized the lunch break to summarize the suggestion, maybe it can explain the idea better:
1. Is there anything in X3D that makes the following DRAFT proposal obsolete?
2. DRAFT Proposal for simplified handling of keystrokes or other input of character streams via KeySensor and StringSensor.
a) Each X3D grouping node defines two additional fields
<field accessType='inputOutput' name='canHaveFocus' type='SFBool' value='false'/>
<field accessType='inputOutput' name='isAvatar' type='SFBool' value='false'/>
b) the behaviour is as follows:
b.1) canHaveFocus == false: well-known "old" behaviour, no change
b.2) canHaveFocus == true && isAvatar == false: the browser may select this group together with all static and dynamic children to get the "focus" by some means. Only one group and its children can have the focus at any time. Having the focus means all StringSensor nodes and KeySensor nodes contained in the group are enabled regardless of the value of their "enabled" field. The browser SHOULD graphically indicate, which geometry has got the focus, e.g. by highlighting or by drawing a 2-dimensional "frame" around the geometry.
b.3) canHaveFocus == true && isAvatar == true: same behaviour as with b.2), but the avatar gets the focus any time, when no other geometry has the focus, even, if the avatar is invisible currently.
Have a nice day
Christoph
Gesendet: Donnerstag, 17. Januar 2019 um 09:44 Uhr
Von: "Christoph Valentin" <christoph.valentin at gmx.at>
An: "Christoph Valentin" <christoph.valentin at gmx.at>, "Leonard Daly" <Leonard.Daly at realism.com>, x3d-public at web3d.org
Betreff: Re: [x3d-public] Mac-unaware PageUp/PageDown, Viewpoint list, navigation keys?
Maybe its silly, but I thought: 1) I can *ride* a locomotive and * use* its controls or 2) I can *be* a locomotive

Like a Horse + Rider = a single entity
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 17.01.19, 09:28, Christoph Valentin <christoph.valentin at gmx.at> schrieb: 
Plus a "special handling" for avatars, where the pilot avatar can have an "always on" focus to supersede Standard navigation by avatar specific movement Strategy..........
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 17.01.19, 07:45, Christoph Valentin <christoph.valentin at gmx.at> schrieb: 
Each grouping node would need a new field:

<field accessType='inputOutput' type='SFBool' name='canHaveFocus' value='false'/>

and the rest was up to the browser.
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 17.01.19, 07:25, Christoph Valentin <christoph.valentin at gmx.at> schrieb: 
And what about a concept of "having the focus":

If a grouping node "had the focus", then all KeySensor and StringSensor nodes within this group would become "enabled".

KR
Christoph
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 16.01.19, 23:22, Christoph Valentin <christoph.valentin at gmx.at> schrieb: 
Maybe my opinion is not important, but I think these concrete hints which key to use for which navigation function should be completely avoided in X3D Spec.

Isn't it enough to have the abstract/virtual concepts of "indicating forward/backward/left/right/up/down", "fast/slow", "touch", "drag" by "some means that are up to the Browser"?

The Events that are created by the sensor nodes have to be specified well, on the other hand. 

A different story is the Network Sensor, where the protocol should be specified to the bits. 

Just my opinion and just Two Cent:-)
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
 
_______________________________________________ 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/20190124/41610e71/attachment-0001.html>