[x3d-public] LineSensor

[Andreas Plesch]

Responding inline but probably already addressed in the thread.

> Date: Thu, 21 Mar 2019 16:54:24 -0700
> From: Leonard Daly <Leonard.Daly at realism.com>
> To: x3d-public at web3d.org
> Subject: Re: [x3d-public] LineSensor
>
> Doesn't? a PlaneSensor degenerate to a (proposed) LineSensor in the case
> where minPosition[x|y] == maxPosition[x|y] (min==max for either X or Y).
> The spec
> (http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#PlaneSensor)
> essentially says that at the end of the 7th paragraph after the node
> definition.

Yes, exactly. There is just a need to address the situation where the
local Z=0 plane (XY) is viewed edge on, and therefore unusable for
picking. This view would be uncommon for regular PlaneSensor use but
quite common for line sensor use. That is why I suggested subsequently
the extended prose for PlaneSensor allowing it to use a tracking plane
other than the XY plane if used as line sensor.

In a way the extended prose may not be even necessary since the end
result is a translation_changed vector which still remains in the XY
plane. The trackpoint_changed position, however, will not be in the XY
plane but somewhere on the browser determined tracking plane. So this
would need to be explained anyways in the prose.

Please let me know if you have questions, suggestions or edits for the
suggested prose here:

 "This technique provides a way to implement a line sensor that maps
 dragging motion into a translation in one dimension. [START EDIT] In
this case, the
 tracking plane can be any plane that contains the one unconstrained
 axis (X or Y). A browser is therefore free to choose a tracking plane
 suitable to robustly determine intersections, in particular when the
 XY plane is unusable. Please note that then the generated trackpoint_changed
 value becomes implementation dependent. [END EDIT]"

> Also rotation of the parent doesn't change the local coordinate system,
> just how it appears on the display. If the parent is rotated so that the
> local coordinate system has Z in one the screen primary direction
> (across or up/down), then all that would be generated is a line sensor
> -- changes in either X or Y (the one into the display) could not be
> detected.

Yes, but this situation is common and needs to be addressed.

Thanks, Andreas

> Leonard Daly
>
> > I now understand the need for LineSensor and may give it a try for
> > x3dom. I know freewrl has it. It may make sense to replicate it.
> >
> > My initial idea would be to use the x axis of the local coordinate
> > system as the Line orientation. Or maybe the y axis since X3D
> > geometries tend to align along y (cylinder, extrusion).
> >
> > Then one can construct an intersection plane which includes the x axis
> > and another direction at a high angle with the viewing direction to
> > get a clean intersection for the inital point and subsequent points
> > during dragging.
> >
> > Is that how freewrl does it ? I think I saw that it may use an
> > additional field for the line orientation but it may be best to avoid
> > it.
> >
> > Andreas
> >
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Past Chair
> President, Daly Realism - /Creating the Future/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190321/3ac29f00/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Mar 2019 23:45:32 -0400
> From: Andreas Plesch <andreasplesch at gmail.com>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Cc: doug sanden <highaspirations at hotmail.com>
> Subject: Re: [x3d-public] LineSensor
> Message-ID:
>         <CAKdk67sRyy9HnuwBsBti38zQ2uoo+YvA9aNAFYzzz_ZEBwqaAg at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I rethought the LineSensor idea and instead opted to add an internal
> line sensor mode to PlaneSensor. The idea is that if the x or y
> components of both minPosition and maxPosition are 0, PlaneSensor acts
> as a LineSensor and is free to use a better intersection plane than
> the default XY plane which can become completely unusable in the case
> when it is viewed on edge.
>
> In the implementation used in the fiddle below, the intersection plane
> normal in line sensor mode is computed as the cross product of the
> line axis (x or y axis) with the cross product of the line axis and
> the view direction when dragging starts:
>
> https://jsfiddle.net/andreasplesch/mzg9dqyc/111/
>
> It seems to work well and allows programming of a translation widget
> in X3D without scripts as shown. On edge view of the PlaneSensor XY
> plane still works because the XY plane is not actually used.
>
> This approach is more spec friendly as it does not require a new node
> and just allows the defacto use as LineSensor to become robust.
> However, since it requires use of another plane than the XY plane, it
> may be necessary to add some language. Perhaps:
>
> "This technique provides a way to implement a line sensor that maps
> dragging motion into a translation in one dimension. In this case, the
> tracking plane can be any plane that contains the one unconstrained
> axis (X or Y). A browser is therefore free to choose a tracking plane
> suitable to robustly determine intersections, in particular when the
> XY plane is unusable. In this case, the generated trackpoint_changed
> value becomes implementation dependent."
>
> I would prefer this over a LineSensor node, and it was pretty
> straightforward to add to the x3dom PlaneSensor implementation.
>
> I think it would be possible to check for other, equal values than 0
> and then use the same approach but I am not sure if it would be
> useful.
>
> If there is feedback, especially on the suggested prose, I will glad
> it to add it to a potential standard comment.
>
> For example, one could tighten the spec. by giving a formula for the
> orientation of a suitable tracking plane in the one dimensional case
> but that may be overreach.
>
> Cheers, -Andreas
>