[x3d-public] LineSensor

GPU Group gpugroup at gmail.com
Fri Mar 22 06:34:28 PDT 2019


Freewrl also does a PointSensor. I think I submitted that to spec comments,
or I should have/meant to, for v4 consideration. Internally PointSensor is
a planesensor aligned to the screen. So if you EXAMINE around something
that's a PointSensor, you can drag it in a plane parallel to the screen
from the current avatar viewing angle, and it feels like you can drag it
any direction you want by changing the avatar pose.That's unlike a
PlaneSensor that's not following/moving with the avatar.
And confirming what Andreas said -and in freewrl code for drag sensors it
mentions Max Limper complaining about x3dom PlaneSensor the same thing
about it failing when viewed on-edge.
-Doug Sanden


On Thu, Mar 21, 2019 at 9:46 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> 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
>
> On Thu, Mar 21, 2019 at 6:06 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >
> > 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
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190322/b17aa7c5/attachment-0001.html>


More information about the x3d-public mailing list