[x3d-public] [x3d] Spec Comment by dougsanden on19775-1:X3DArchitecture - V3.0

Sun Jun 14 15:40:54 PDT 2020

HOVER vs ISOVER - yes Joe ISOVER seems like a good/more recognizable name
for helping touch devices do an up-drag.
Q.  do you have a name for the following navigation device:
- a device 2D up-drag capability is being used for yaw-pitch. But the
device isn't centered where the user wants it to be centered. Think of the
gyro in a mobile device being used for navigation yaw pitch - seems
natural. But then you're riding on a subway train, and the train goes
around a 90 degree corner. Now you're off center in the scene. So you press
a button named XXXXX, rotate your device and release the button, maybe
repeating a few times, to get it recentered.
What is a good name for the button?
-Doug

On Sun, Jun 14, 2020 at 2:23 PM GPU Group <gpugroup at gmail.com> wrote:

> Yes Joe - great thoughts.
> Keyboard: mobile devices 'pop up' a keyboard or if you pin it its taking
> up valuable screen space. If its not a prompt, then you have to summon the
> keyboard too. Writing a spec so you _have_ to use a keyboard seems like it
> would be limiting to a desktop scenario which would be appropriate in 2006.
> Having said that, if a mobile touch-centric non-keyboard-involking browser
> had a menu bar, they could put 3 toggle buttons for SHIFT, ALT, CTRL and
> then be pretty close to the EXPLORE specs.
> But what about a game controller? They have some buttons that would be
> handier than clicking on a menu bar.
> Something similar for HMDs you might have some wands in your hand, and
> they may have buttons on them, and so you would want to map to those
> triggers some how.
> So I'm still in favor of generalizing input device mappings.
> Having said that, there's a concept of a 'virtual device' which is
> all-encompasing and specs would be written wirt the virtual device, and
> then deployments would map to the virtual device. That's common with games
> - a virtual game controller, and then if you have something else, its 2D,
> scalar and buttons get mapped to the virtual device, and so games can be
> wrtten w.r.t. the virtual device.
> But what would a good all encompassing virtual device look like? something
> that covers multitouch and 2 thumb game controllers, what about HMDs, what
> about future stuff - will we have multi-user on same machine ie 2 game
> controllers?
> -Doug
>
>
>
> On Sun, Jun 14, 2020 at 1:48 PM Joseph D Williams <joedwil at earthlink.net>
> wrote:
>
>> Once I recall maybe gravity should be default part of certain navigations
>> and not others. Like how the nograv of Fly is what you want to do, mostly,
>> unless you are flying by aero, then of course there are other effects.
>> Suppose you are flying and somebody turns gravity on?
>>
>>
>>
>> Also, please look for current x3d ‘name’ for interactions, like maybe
>> hover is isOver and use of select rather than click. Some superset of x3d
>> and html event inOut styles?
>>
>> The important thing is that a competent input/output device must be able
>> to describe itself as to its allowed data and interactions plus the author
>> must be able to describe what is needed to make the show, maybe at various
>> capability levels. Finally, the user must be able to tell what can be done
>> and make some simple tests to observe the results of using various
>> techniques with available tools.
>>
>>
>>
>> X3d recommended optional use of the keyboard and provided keys and events
>> (not normative).
>>
>> However, for implementers there was enough behind it so that most users
>> in 2006 could expect that best browsers would at least do that set of keys.
>> Again, the purpose was not to stop or start anything, just to document some
>> current best practices that were being done by the most interesting tools.
>>
>>
>>
>> This challenge of creating usable abstractions for human user interaction
>> using modern human interface arts was last documented by x3d around 2006, I
>> think. I hope to see great advancements in documenting what will be
>> regarded as World-class best practices for development of an important
>> collection of x3d statements and sensor nodes to support the widest range
>> of human input/output features. We need to get interaction data into the
>> scene, out of the scene , interpreted by the user, then put back into the
>> scene, etc.
>>
>>
>>
>> Thanks,
>>
>> Joe
>>
>>
>>
>> *From: *GPU Group <gpugroup at gmail.com>
>> *Sent: *Sunday, June 14, 2020 11:45 AM
>> *To: *Joseph D Williams <joedwil at earthlink.net>
>> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
>> *Subject: *Re: [x3d-public] [x3d] Spec Comment by dougsanden
>> on19775-1:X3DArchitecture - V3.0
>>
>>
>>
>> My attempt at specifying HELICOPTER and GAME navigationInfo.type
>> generically
>>
>>
>>
>> "SPHERICAL" navigation freezes the location while allowing convenient
>> yaw-pitch look around.
>>
>>
>>
>> "HELICOPTER" navigation is similar to "WALK" except avatar height
>> adjustment is convenient, and "SPHERICAL" style yaw-pitch look around is
>> convenient.
>>
>>
>>
>> "GAME" navigation is like "WALK" except yaw-ptich is done with up-drag
>> primary pointing device, and Z travel with secondary pointing device.
>>
>>
>>
>>
>>
>> On Sun, Jun 14, 2020 at 11:57 AM GPU Group <gpugroup at gmail.com> wrote:
>>
>>
>>
>> Appendix G style mapping
>>
>> Example trigger mapping for desktop keyboard + mouse
>>
>>
>>
>> trigger permutation
>>
>> LMB
>>
>> RMB
>>
>> SHIFT
>>
>> ALT
>>
>> CTRL
>>
>>
>>
>> 1.primary
>>
>> *
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2. secondary
>>
>> *
>>
>>
>>
>>
>>
>>
>>
>> *
>>
>>
>>
>> 3. tertiary
>>
>> *
>>
>>
>>
>> *
>>
>>
>>
>> *
>>
>>
>>
>> 4. quaternary
>>
>> *
>>
>>
>>
>>
>>
>> *
>>
>>
>>
>>
>>
>> 5. quinary
>>
>> *
>>
>>
>>
>> *
>>
>> *
>>
>>
>>
>>
>>
>> 6, senary
>>
>> *
>>
>>
>>
>> *
>>
>>
>>
>>
>>
>>
>>
>> 7. septenary
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 8. octonary
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 9. nonary
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 10 denary
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Jun 14, 2020 at 11:41 AM GPU Group <gpugroup at gmail.com> wrote:
>>
>> my attempt to abstract the EXPLORE NavigationInfo type:
>>
>>
>>
>> "EXPLORE" navigation is used to provide consistent keystroke *input
>> device mapping* navigation for both geospatial and Cartesian modes. Common
>> terms:
>>
>> Drag - moving primary pointing device with a trigger activated, primary
>> trigger unless otherwise specified
>>
>> Click - activating and releasing a trigger, primary trigger unless
>> otherwise specified
>>
>> up/down,left/right - relative to viewport sides
>>
>> trigger button state-permutation names:
>>
>> *1.primary*
>>
>> *2. secondary*
>>
>> *3. tertiary*
>>
>> *4. quaternary*
>>
>> 5. *quinary*
>>
>> *6*, *senary*
>>
>> *7.* *septenary*
>>
>> *8.* *octonary*
>>
>> 9. *nonary*
>>
>> *10* *denary*
>>
>> When "EXPLORE" mode is active:
>>
>>    1. Dragging left and right while holding the left button down causes
>>    viewpoint rotation about a vertical axis that passes through the point of
>>    rotation. This vertical axis is always perpendicular to the viewpoint
>>    vector. Motion in the left direction rotates the viewpoint clockwise (as
>>    viewed from the top) about the vertical axis. Rotation is tied to the
>>    motion of the pointing device; there is no damping or delay.
>>    2. Dragging the up and down while holding the left button down causes
>>    rotation about a horizontal axis that passes through the point of rotation.
>>    Motion in the up direction rotates the viewpoint clockwise (as viewed from
>>    the right) about the horizontal axis. Rotation is tied to the motion of the
>>    pointing device; there is no damping or delay.
>>    3. Holding the Ctrl key (or other key that may be user-selectable)
>>    down modifies the left button down Secondary trigger drag movement such
>>    that up and down (Y-axis) movement causes the viewpoint to zoom
>>    toward and from the point of rotation. Tertiary trigger Left and
>>    right motion while Ctrl is held down has no effect. Shift and Ctrl
>>    (or other keys that may be user-selectable) held at the same time also
>>    enables zoom but disables TouchSensors.
>>    4. Holding the Alt key (or other key that may be user-selectable)
>>    modifies the movement such that motion of the pointing device while the
>>    left button is held down Quaternary trigger movement is translated
>>    into a pan of the viewpoint in a plane passing through the viewpoint
>>    perpendicular to the vector pointing to the point of rotation. Shift
>>    and Alt (or other keys that may be user-selectable) held at the same time
>>    also Quinary trigger enables pan but disables TouchSensors.
>>    5. The point of rotation can be set by holding the Shift key (or
>>    other key that may be user-selectable) while pointing at an object
>>    and clicking the left button senary trigger. To provide feedback that
>>    the point has been selected, the viewpoint shall zoom about twenty percent
>>    of the distance toward that point.
>>    6. If the pointer is positioned over a TouchSensor, the pointer icon
>>    shall change its appearance to indicate that a left primary click
>>    will activate the TouchSensor.
>>    7. Holding the Shift key (or other key that may be user-selectable)
>>    Septenary trigger overrides any TouchSensor that the pointer may be
>>    over and forces the pointing device to function as the viewpoint navigation
>>    tool; *i.e.*, drag operations cause rotation, click operations cause
>>    center of rotation point selection.
>>
>> Whether user-selectable alternatives to the Shift, Ctrl, and/or Alt are
>> provided is browser-dependent. If provided, the method by which such
>> alternatives are specified is also browser-dependent.
>>
>>
>>
>> On Sun, Jun 14, 2020 at 9:45 AM GPU Group <gpugroup at gmail.com> wrote:
>>
>> Yes I see there's terminology it looks like its is mapping keyboard to
>> work as a pointing device
>>
>> Hypothesis: there could be a way to remap EXPLORE (which is heavy in
>> button / pointing-device-motion specifics)
>>
>> a) write it more generally somehow
>>
>> b) then as with Appendix G, do some device-specific mappings.
>>
>> Same with (new v4) HELICOPTER, GAME motions - could they be written
>> generally like the WALK, FLY, EXAMINE - with very little talk about buttons
>> and pointing devices - and then somehow articulate mappings in Appendix G?
>>
>>
>>
>> Here are some device scenarios
>>
>> i) desktop 2 button + wheel mouse, full keyboard with arrow keys,
>> ctrl,shft,alt
>> ii) mobile - gyro, touch screen
>> iii) non-mobile touch screen
>> iv) HMD with gyro and viewport center
>>
>> v) desktop game controller
>>
>>
>>
>> EXPLORE could define 'drag / dragging' in such a way to share with
>> HELICOPTER, GAME and new ones if they can't be specified notion-lessly.
>>
>>
>>
>>
>>
>> On Sun, Jun 14, 2020 at 9:36 AM Joseph D Williams <joedwil at earthlink.net>
>> wrote:
>>
>> For example:
>>
>>
>>
>> *WALK:      forward/backward/left/right*
>>
>> *FLY:       forward/backward/left/right*
>>
>> *EXAMINE:   orbit up/down/left/right around center of rotation*
>>
>> *           with camera pointed at center of rotation*
>>
>>
>>
>>
>>
>>
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>> *From: *Joseph D Williams <joedwil at earthlink.net>
>> *Sent: *Sunday, June 14, 2020 8:31 AM
>> *To: *GPU Group <gpugroup at gmail.com>; X3D Graphics public mailing list
>> <x3d-public at web3d.org>
>> *Subject: *Re: [x3d-public] [x3d] Spec Comment by dougsanden on
>> 19775-1:X3DArchitecture - V3.0
>>
>>
>>
>>
>>
>>    - Q. And could/should named navigation modes/types be
>>
>>
>>
>> How about some more work on:
>>
>> Extensible 3D (X3D) Part 1: Architecture and base components
>>
>> Annex G Recommended navigation behaviours
>>
>> (informative)
>>
>>
>>
>>
>> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/behaviours.html
>>
>>
>>
>> Several reasons the annex was informative at that time, or even
>> attempted.
>>
>> Maybe more Is understood now, and this offers some guidance from some
>> point in time.
>>
>> Thanks,
>>
>> Joe
>>
>>
>>
>>
>>
>> *From: *GPU Group <gpugroup at gmail.com>
>> *Sent: *Sunday, June 14, 2020 6:28 AM
>> *To: *X3D Graphics public mailing list <x3d-public at web3d.org>
>> *Subject: *Re: [x3d-public] [x3d] Spec Comment by dougsanden on 19775-1:
>> X3DArchitecture - V3.0
>>
>>
>>
>> Forwarding some comments on other channels
>>
>> Q. should specs > NavigationInfo attempt to abstract input / pointing
>> device terminology
>>
>> - so gyros, game controllers/pads, touch screens, 3D pointing devices ?,
>> HMD / AR gyro/view-center - can all be mapped more generically:
>>
>>
>>
>> Instead of mouse xy, it would be 'primaryXY channel' or  'primary
>> 2D pointing device'
>>
>>
>>
>> Q. And could/should named navigation modes/types be specified in terms of
>> the order and transform element being mapped to:
>>
>> WALK: yaw and Z are applied to last yaw-z pose, then pitch-roll applied
>>
>> FREEFLY: yaw,z,pitch,roll are applied in any order
>>
>> Perhaps something in a table format?
>>
>>
>>
>> Thanks,
>>
>> Doug Sanden
>>
>>
>>
>>
>>
>> On Sat, Jun 13, 2020 at 12:15 PM GPU Group <gpugroup at gmail.com> wrote:
>>
>> "have your ray loop forget about ID=2"
>>
>> One notable difference between a touch device and a mouse: a mouse has an
>> up-drag. A touch doesn't.
>>
>> - that makes no difference to MultiTouch/MultiDragSensor, which only
>> works with down-drags.
>>
>> Where you see the difference: isOver, and navigation modes that assume
>> updrag is available - like proposed GAME mode.
>>
>> And what you do when a button / touch is 'released':
>>
>> - updrag-capabile input devices: you likely just change a button state,
>> and keep drawing the cursor at the last location
>>
>> - updrag-incapable input devices - you likely release/forget/recycle the
>> ID number
>>
>> SUMMARY: web3d specs may need more terms to describe input device classes
>> and capabilities more abstractly
>>
>> - up-drags
>>
>> - drag-ID
>>
>> - drag-ID recycling
>>
>>
>>
>>
>>
>> On Sat, Jun 13, 2020 at 11:59 AM GPU Group <gpugroup at gmail.com> wrote:
>>
>> Drags need an ID ie 1,2,3 and that comes normally in windows 7
>> desktop WM_TOUCH events, or more precisely you can get an index number in a
>> lookup table of touches.
>>
>> A mouse-friendly use of a MultiDragSensor:
>>
>> - your regular pointing device ray might be ID=1
>>
>> - to create a second ray, you can park/freeze ID=1 with some mouse or
>> keyboard button ie MMB - and push a 2nd one with ID=2 onto a stack
>>
>> - then you would move drag ID= 2, until done with scaling and rotation,
>> and unfreeze / pop to get back to dragging ID=1 - maybe same button- and
>> have your ray loop forget about ID=2 after that, until the user repeats the
>> cycle. Or something like that.
>>
>> SUMMARY: yes - it can be abstracted from touch devices, but you still
>> need a per-drag ID.
>>
>> -Doug
>>
>>
>>
>> On Sat, Jun 13, 2020 at 11:18 AM Spec Feedback <spec-comment at web3d.org>
>> wrote:
>>
>> -- Submitter indicates that this comment may be public: *Yes* --
>>
>> Comment on 19775-1: X3D Architecture - V3.0
>> MultiTouchSensor
>>
>>
>> -----------------
>> MultiTouchSensor > Touch vs Drag > MutliDragSensor
>> In theory it should be called something that abstracts it from the
>> particular
>> type of input device.
>> Drag is more input device neutral - there could be other device-neutral
>> terms.
>> For example a typical game controller has 2 thumb sticks that could act
>> like
>> 2 touches.
>> A combination of device gyro -in HMD or mobile phone or Wii Controller-
>> and
>> freeze-button could shoot one ray, freeze it as one touch, then shoot
>> another
>> ray to drag.
>> Internally, code works with a plane sensor xy origin when a button goes
>> down/a ray is shot, then a drag xy is compared to the orgin xy to see how
>> far
>> in what direction: internally its drag-oriented and doesn't care what
>> device
>> shot the rays.
>> -----------------
>>
>> Submitted on Saturday, 2020,  June 13 - 11:18am
>> by dougsanden (dougsanden )
>> IP: 75.159.18.239
>>
>> See: https://www.web3d.org/node/1694/submission/4039
>>
>>
>> _______________________________________________
>> x3d mailing list
>> x3d at web3d.org
>> http://web3d.org/mailman/listinfo/x3d_web3d.org
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200614/5569fb08/attachment-0001.html>