[x3d-public] LineSensor and avoiding uncontrolled dragging

[Andreas Plesch]

Hi Don,

thanks for looking into this issue. I have amended the write-up to
include a more complete draft for a spec. comment:

https://gist.github.com/andreasplesch/33016fd0918178f5dfcf4632d477f4e4#file-readme-md

You are right that there are pathologies with dragging. Some of them
are unavoidable as is the case for dragging in a plane which can only
be seen on edge by a viewer. The equivalent for the line sensor case
would be dragging along the line where only the tip of the line is
visible.

I am not sure if these cases need to be codified since there is not an
expectation by a user to be able to drag for these viewing situations
in the first place. Although I think it is a good idea to add a
provision that dragging should be disabled in these situations. "Ill
defined" could be left fuzzy. I cannot think of another pathology.

But this provision would not address the jumping line sensor, I am afraid.

The difference with line sensor as currently specified is that if the
view is on edge down the tracking plane, generally the line still can
be seen fully (not just the tip) and so there is an expectation that
well defined dragging is still possible. In fact, browsers like
Octaga, x_ite or view3dscene ignore the XY tracking plane in the line
sensor case to allow proper dragging in this case, in contradiction to
the spec.

Any feedback much welcome, Andreas

On Sun, Mar 31, 2019 at 3:21 AM Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu> wrote:
>
> thanks for the in-depth look at these challenges.
>
> yes, good specification preparation really helps a lot... this work all takes time, which is our only limited constraint.
>
> On 3/27/2019 8:07 PM, Andreas Plesch wrote:
> > In preparation for a well presented spec. comment, I developed a
> > minimal but discerning example scene illustrating the problematic on
> > edge view for 1D PlaneSensors:
> >
> > https://gist.github.com/andreasplesch/33016fd0918178f5dfcf4632d477f4e4#file-planesensor1donedge-x3d
>
> In the writeup there you say:
> =============================
> Drag the red cone
> This scene illustrates the difficulty of using a PlaneSensor when the view is parallel to the tracking plane (light blue). Dragging works well in the default view normal to the tracking plane. Press PgUp to change the viewpoint to an on edge view. Dragging cannot work because the intersection of the bearing with tracking the plane becomes ill defined.
> =============================
>
> A not-uncommon 3D pathology when dragging along a direction that is nearly perpendicular to the screen is that translations can become wildly large, moving things behind the user's view, or inside /outside the view frustum clipping planes.  At which point, the selected geometry is not visible and the handle is lost if the drag sensor is released.
>
> A good practice for implementers is "don't do that" but am not sure that is codified anywhere.  Not seeing any cautionary prose like that in the X3D specification.
>
> Perhaps we can come up with a functional limitation on drag sensors that avoids this pathology?
>
> Perhaps
> a. Drag sensors must avoid operating when the tracking geometry becomes ill defined and does not permit positive user control.
> b. Dragging past the boundaries of the view frustum is not allowed.
> c. something else?
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman



-- 
Andreas Plesch
Waltham, MA 02453