[x3d-public] LineSensor

[Andreas Plesch]

Hi Doug,

I think a PointSensor is a good idea if there is currently no other
way to drag a point around in a plane parallel to the screen. Since
dragging is still restricted to a plane, perhaps ScreenSensor would be
a better name ? This is a common and useful dragging method,
especially if you have well defined viewpoints, like a perfect map
view.

To be more specific, the tracking plane is defined by the point on the
sibling geometry first indicated when dragging starts and by the
avatar viewing direction as the plane normal. The avatar viewing
direction is the current viewpoint orientation, or the orientation of
a ray to the center of the screen.

Autooffset, I  think, works the same by just accumulating offsets for
each drag action.

And translation_changed and trackpoint_changed, I think, would still
be reported in the local coordinate system of the sensor.

Would it make sense to have a min. and maxPosition for it ? I think so.

So I think it would be pretty straightforward to implement based on
the existing PlaneSensor. Perhaps it should become a "screen" mode for
PlaneSensor since it would have pretty much the same fields ?

Then it may suffice to add only little prose to the PlaneSensor spec.:

"If the mode field is set to "screen", the tracking plane is not the
XY plane of the local sensor coordinate system. Instead, the tracking
plane is the plane parallel to screen anchored by the initial
intersection point."

On the other hand, such mode fields are generally not used in any X3D
nodes, probably for good reason. Perhaps planeOrientation would be a
better name, with values "XY" (default), "screen", "XZ", "YZ".

Although there is no screen in VR, the vertical plane perfectly ahead
in the viewing direction is still an important plane and would be
useful to drag around things in.

More ideas,

-Andreas

On Fri, Mar 22, 2019 at 9:34 AM GPU Group <gpugroup at gmail.com> wrote:
>
> 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



-- 
Andreas Plesch
Waltham, MA 02453