<div dir="ltr">Forwarding some comments on other channels<div>Q. should specs > NavigationInfo attempt to abstract input / pointing device terminology</div><div>- so gyros, game controllers/pads, touch screens, 3D pointing devices ?, HMD / AR gyro/view-center - can all be mapped more generically:</div><div><br></div><div>Instead of mouse xy, it would be 'primaryXY channel' or 'primary 2D pointing device'</div><div><br></div><div>Q. And could/should named navigation modes/types be specified in terms of the order and transform element being mapped to:</div><div>WALK: yaw and Z are applied to last yaw-z pose, then pitch-roll applied</div><div>FREEFLY: yaw,z,pitch,roll are applied in any order</div><div>Perhaps something in a table format?</div><div><br></div><div>Thanks,</div><div>Doug Sanden</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 13, 2020 at 12:15 PM GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</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 dir="ltr"><div dir="ltr">"have your ray loop forget about ID=2"</div><div>One notable difference between a touch device and a mouse: a mouse has an up-drag. A touch doesn't. </div><div>- that makes no difference to MultiTouch/MultiDragSensor, which only works with down-drags.</div><div>Where you see the difference: isOver, and navigation modes that assume updrag is available - like proposed GAME mode.</div><div>And what you do when a button / touch is 'released': </div><div>- updrag-capabile input devices: you likely just change a button state, and keep drawing the cursor at the last location</div><div>- updrag-incapable input devices - you likely release/forget/recycle the ID number</div><div>SUMMARY: web3d specs may need more terms to describe input device classes and capabilities more abstractly</div><div>- up-drags</div><div>- drag-ID</div><div>- drag-ID recycling</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 13, 2020 at 11:59 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</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 dir="ltr"><div>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.</div><div>A mouse-friendly use of a MultiDragSensor:</div><div>- your regular pointing device ray might be ID=1</div><div>- 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 </div><div>- 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. </div><div>SUMMARY: yes - it can be abstracted from touch devices, but you still need a per-drag ID.</div><div>-Doug</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">-- 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" rel="noreferrer" 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" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d_web3d.org</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>