<div dir="ltr">Yes I see there's terminology it looks like its is mapping keyboard to work as a pointing device<div>Hypothesis: there could be a way to remap EXPLORE (which is heavy in button / pointing-device-motion specifics)</div><div>a) write it more generally somehow</div><div>b) then as with Appendix G, do some device-specific mappings.</div><div>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?</div><div><br></div><div>Here are some device scenarios</div><div>i) desktop 2 button + wheel mouse, full keyboard with arrow keys, ctrl,shft,alt<br>ii) mobile - gyro, touch screen<br>iii) non-mobile touch screen<br>iv) HMD with gyro and viewport center<br></div><div>v) desktop game controller</div><div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 14, 2020 at 9:36 AM Joseph D Williams <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-8359726348826327737WordSection1"><p class="MsoNormal">For example:</p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><b><span style="font-size:9.5pt;font-family:"Courier New";color:black;background:white">WALK:      forward/backward/left/right<u></u><u></u></span></b></p><p class="MsoNormal"><b><span style="font-size:9.5pt;font-family:"Courier New";color:black;background:white">FLY:       forward/backward/left/right<u></u><u></u></span></b></p><p class="MsoNormal"><b><span style="font-size:9.5pt;font-family:"Courier New";color:black;background:white">EXAMINE:   orbit up/down/left/right around center of rotation<u></u><u></u></span></b></p></div><p class="MsoNormal"><b><span style="font-size:9.5pt;font-family:"Courier New";color:black;background:white">           with camera pointed at center of rotation<u></u><u></u></span></b></p><p class="MsoNormal"><b><span style="font-size:9.5pt;font-family:"Courier New";color:black;background:white"><u></u> <u></u></span></b></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986" target="_blank">Mail</a> for Windows 10</p><p class="MsoNormal"><u></u> <u></u></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:joedwil@earthlink.net" target="_blank">Joseph D Williams</a><br><b>Sent: </b>Sunday, June 14, 2020 8:31 AM<br><b>To: </b><a href="mailto:gpugroup@gmail.com" target="_blank">GPU Group</a>; <a href="mailto:x3d-public@web3d.org" target="_blank">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] [x3d] Spec Comment by dougsanden on 19775-1:X3DArchitecture - V3.0</p></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><ul style="margin-top:0in" type="disc"><li class="gmail-m_-8359726348826327737MsoListParagraph" style="margin-left:0in">Q. And could/should named navigation modes/types be<u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">How about some more work on:<u></u><u></u></p><p class="MsoNormal">Extensible 3D (X3D) Part 1: Architecture and base components<u></u><u></u></p><p class="MsoNormal">Annex G Recommended navigation behaviours<u></u><u></u></p><p class="MsoNormal">(informative)<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/behaviours.html" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/behaviours.html</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Several reasons the annex was informative at that time, or even attempted. <u></u><u></u></p><p class="MsoNormal">Maybe more Is understood now, and this offers some guidance from some point in time.<u></u><u></u></p><p class="MsoNormal">Thanks, <u></u><u></u></p><p class="MsoNormal">Joe<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b>From: </b><a href="mailto:gpugroup@gmail.com" target="_blank">GPU Group</a><br><b>Sent: </b>Sunday, June 14, 2020 6:28 AM<br><b>To: </b><a href="mailto:x3d-public@web3d.org" target="_blank">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] [x3d] Spec Comment by dougsanden on 19775-1: X3DArchitecture - V3.0<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Forwarding some comments on other channels<u></u><u></u></p><div><p class="MsoNormal">Q. should specs > NavigationInfo attempt to abstract input / pointing device terminology<u></u><u></u></p></div><div><p class="MsoNormal">- so gyros, game controllers/pads, touch screens, 3D pointing devices ?, HMD / AR gyro/view-center - can all be mapped more generically:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Instead of mouse xy, it would be 'primaryXY channel' or  'primary 2D pointing device'<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Q. And could/should named navigation modes/types be specified in terms of the order and transform element being mapped to:<u></u><u></u></p></div><div><p class="MsoNormal">WALK: yaw and Z are applied to last yaw-z pose, then pitch-roll applied<u></u><u></u></p></div><div><p class="MsoNormal">FREEFLY: yaw,z,pitch,roll are applied in any order<u></u><u></u></p></div><div><p class="MsoNormal">Perhaps something in a table format?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks,<u></u><u></u></p></div><div><p class="MsoNormal">Doug Sanden<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Sat, Jun 13, 2020 at 12:15 PM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt"><div><div><p class="MsoNormal" style="margin-left:4.8pt">"have your ray loop forget about ID=2"<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">One notable difference between a touch device and a mouse: a mouse has an up-drag. A touch doesn't. <u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">- that makes no difference to MultiTouch/MultiDragSensor, which only works with down-drags.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">Where you see the difference: isOver, and navigation modes that assume updrag is available - like proposed GAME mode.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">And what you do when a button / touch is 'released': <u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">- updrag-capabile input devices: you likely just change a button state, and keep drawing the cursor at the last location<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">- updrag-incapable input devices - you likely release/forget/recycle the ID number<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">SUMMARY: web3d specs may need more terms to describe input device classes and capabilities more abstractly<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">- up-drags<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">- drag-ID<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt">- drag-ID recycling<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:4.8pt"><u></u> <u></u></p></div></div><p class="MsoNormal" style="margin-left:4.8pt"><u></u> <u></u></p><div><div><p class="MsoNormal" style="margin-left:4.8pt">On Sat, Jun 13, 2020 at 11:59 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt"><div><div><p class="MsoNormal" style="margin-left:9.6pt">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.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:9.6pt">A mouse-friendly use of a MultiDragSensor:<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:9.6pt">- your regular pointing device ray might be ID=1<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:9.6pt">- 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 <u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:9.6pt">- 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. <u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:9.6pt">SUMMARY: yes - it can be abstracted from touch devices, but you still need a per-drag ID.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:9.6pt">-Doug<u></u><u></u></p></div></div><p class="MsoNormal" style="margin-left:9.6pt"><u></u> <u></u></p><div><div><p class="MsoNormal" style="margin-left:9.6pt">On Sat, Jun 13, 2020 at 11:18 AM Spec Feedback <<a href="mailto:spec-comment@web3d.org" target="_blank">spec-comment@web3d.org</a>> wrote:<u></u><u></u></p></div></div></blockquote></div></blockquote></div><p class="MsoNormal" style="margin-left:0.2in">-- Submitter indicates that this comment may be public: *Yes* --<br><br>Comment on 19775-1: X3D Architecture - V3.0<br>MultiTouchSensor<br><br><br>-----------------<br>MultiTouchSensor > Touch vs Drag > MutliDragSensor<br>In theory it should be called something that abstracts it from the particular<br>type of input device.<br>Drag is more input device neutral - there could be other device-neutral<br>terms.<br>For example a typical game controller has 2 thumb sticks that could act like<br>2 touches.<br>A combination of device gyro -in HMD or mobile phone or Wii Controller- and<br>freeze-button could shoot one ray, freeze it as one touch, then shoot another<br>ray to drag.<br>Internally, code works with a plane sensor xy origin when a button goes<br>down/a ray is shot, then a drag xy is compared to the orgin xy to see how far<br>in what direction: internally its drag-oriented and doesn't care what device<br>shot the rays.<br>-----------------<br><br>Submitted on Saturday, 2020,  June 13 - 11:18am<br>by dougsanden (dougsanden )<br>IP: 75.159.18.239<br><br>See: <a href="https://www.web3d.org/node/1694/submission/4039" target="_blank">https://www.web3d.org/node/1694/submission/4039</a><br><br><br>_______________________________________________<br>x3d mailing list<br><a href="mailto:x3d@web3d.org" target="_blank">x3d@web3d.org</a><br><a href="http://web3d.org/mailman/listinfo/x3d_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d_web3d.org</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p></div></div></blockquote></div>