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

Sun Jun 14 11:45:24 PDT 2020

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