[x3d-public] LineSensor and avoiding uncontrolled dragging

[Andreas Plesch]

Ok. I pressed on and added a description of the identified pathologies,
with some suggestions for graceful browser behaviors:

https://bl.ocks.org/andreasplesch/33016fd0918178f5dfcf4632d477f4e4

Spec. prose could be more concise. Also, the view frustum pathology likely
applies more widely. I think the suggested behavior could apply to all drag
sensors.

In addition, I simplified the example and tweaked the issue description and
suggested spec. prose.

Feel free to take a look and comment/edit liberally,

Andreas

---on the phone---

On Mon, Apr 1, 2019, 9:00 AM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu
wrote:

> likewise thanks, glad you think the pathology issues are real.  they are
> perhaps expected by grizzled 3D veterans, but will not be expected or
> understood by non-expert users ("hey everything i try to move around
> disappears!")
>
> let's press on with prose that identifies the issue and provides
> implementation guidelines and requirements (candidates listed before).  As
> your latest prose implies, giving browsers some leeway to adaptively
> respond (and thus "do the right thing") is a good idea.  this will also
> help authors understand how to better avoid interaction difficulties.
>
> once you and Doug and list participants think that this contribution is
> mostly ready, X3D Working Group will be happy to review specification
> inputs for X3Dv4.  less than 100% completion is OK, if the TODO items are
> well defined and open questions are somehow resolvable.  examples like
> yours certainly help!  onward we go.
>
> v/r Don
>
>
> On 3/31/2019 7:12 AM, Andreas Plesch wrote:
> > 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
> >
> >
> >
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190401/12722956/attachment.html>