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

Joseph D Williams joedwil at earthlink.net
Sun Jun 14 12:48:40 PDT 2020


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
Sent: Sunday, June 14, 2020 11:45 AM
To: Joseph D Williams
Cc: X3D Graphics public mailing list
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:
a. 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.
b. 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.
c. 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.
d. 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.
e. 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.
f. 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.
g. 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 for Windows 10
 
From: Joseph D Williams
Sent: Sunday, June 14, 2020 8:31 AM
To: GPU Group; X3D Graphics public mailing list
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
Sent: Sunday, June 14, 2020 6:28 AM
To: X3D Graphics public mailing list
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/895e9567/attachment-0001.html>


More information about the x3d-public mailing list