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

Sun Jun 14 10:57:45 PDT 2020

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/b5b098dd/attachment-0001.html>