<div dir="ltr">Great ideas and PlaneOrientation "screen" sounds intuitive, I like it. And saves a node definition, and you Andreas having solved the linesensor via planesensor, it makes sense to keep going that way, packing more in the PlaneSensor node. Keep up the great work.<div>-Doug</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2019 at 9:12 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Doug,<br>
<br>
I think a PointSensor is a good idea if there is currently no other<br>
way to drag a point around in a plane parallel to the screen. Since<br>
dragging is still restricted to a plane, perhaps ScreenSensor would be<br>
a better name ? This is a common and useful dragging method,<br>
especially if you have well defined viewpoints, like a perfect map<br>
view.<br>
<br>
To be more specific, the tracking plane is defined by the point on the<br>
sibling geometry first indicated when dragging starts and by the<br>
avatar viewing direction as the plane normal. The avatar viewing<br>
direction is the current viewpoint orientation, or the orientation of<br>
a ray to the center of the screen.<br>
<br>
Autooffset, I  think, works the same by just accumulating offsets for<br>
each drag action.<br>
<br>
And translation_changed and trackpoint_changed, I think, would still<br>
be reported in the local coordinate system of the sensor.<br>
<br>
Would it make sense to have a min. and maxPosition for it ? I think so.<br>
<br>
So I think it would be pretty straightforward to implement based on<br>
the existing PlaneSensor. Perhaps it should become a "screen" mode for<br>
PlaneSensor since it would have pretty much the same fields ?<br>
<br>
Then it may suffice to add only little prose to the PlaneSensor spec.:<br>
<br>
"If the mode field is set to "screen", the tracking plane is not the<br>
XY plane of the local sensor coordinate system. Instead, the tracking<br>
plane is the plane parallel to screen anchored by the initial<br>
intersection point."<br>
<br>
On the other hand, such mode fields are generally not used in any X3D<br>
nodes, probably for good reason. Perhaps planeOrientation would be a<br>
better name, with values "XY" (default), "screen", "XZ", "YZ".<br>
<br>
Although there is no screen in VR, the vertical plane perfectly ahead<br>
in the viewing direction is still an important plane and would be<br>
useful to drag around things in.<br>
<br>
More ideas,<br>
<br>
-Andreas<br>
<br>
On Fri, Mar 22, 2019 at 9:34 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
> 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.<br>
> -Doug Sanden<br>
><br>
><br>
> On Thu, Mar 21, 2019 at 9:46 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> I rethought the LineSensor idea and instead opted to add an internal<br>
>> line sensor mode to PlaneSensor. The idea is that if the x or y<br>
>> components of both minPosition and maxPosition are 0, PlaneSensor acts<br>
>> as a LineSensor and is free to use a better intersection plane than<br>
>> the default XY plane which can become completely unusable in the case<br>
>> when it is viewed on edge.<br>
>><br>
>> In the implementation used in the fiddle below, the intersection plane<br>
>> normal in line sensor mode is computed as the cross product of the<br>
>> line axis (x or y axis) with the cross product of the line axis and<br>
>> the view direction when dragging starts:<br>
>><br>
>> <a href="https://jsfiddle.net/andreasplesch/mzg9dqyc/111/" rel="noreferrer" target="_blank">https://jsfiddle.net/andreasplesch/mzg9dqyc/111/</a><br>
>><br>
>> It seems to work well and allows programming of a translation widget<br>
>> in X3D without scripts as shown. On edge view of the PlaneSensor XY<br>
>> plane still works because the XY plane is not actually used.<br>
>><br>
>> This approach is more spec friendly as it does not require a new node<br>
>> and just allows the defacto use as LineSensor to become robust.<br>
>> However, since it requires use of another plane than the XY plane, it<br>
>> may be necessary to add some language. Perhaps:<br>
>><br>
>> "This technique provides a way to implement a line sensor that maps<br>
>> dragging motion into a translation in one dimension. In this case, the<br>
>> tracking plane can be any plane that contains the one unconstrained<br>
>> axis (X or Y). A browser is therefore free to choose a tracking plane<br>
>> suitable to robustly determine intersections, in particular when the<br>
>> XY plane is unusable. In this case, the generated trackpoint_changed<br>
>> value becomes implementation dependent."<br>
>><br>
>> I would prefer this over a LineSensor node, and it was pretty<br>
>> straightforward to add to the x3dom PlaneSensor implementation.<br>
>><br>
>> I think it would be possible to check for other, equal values than 0<br>
>> and then use the same approach but I am not sure if it would be<br>
>> useful.<br>
>><br>
>> If there is feedback, especially on the suggested prose, I will glad<br>
>> it to add it to a potential standard comment.<br>
>><br>
>> For example, one could tighten the spec. by giving a formula for the<br>
>> orientation of a suitable tracking plane in the one dimensional case<br>
>> but that may be overreach.<br>
>><br>
>> Cheers, -Andreas<br>
>><br>
>> On Thu, Mar 21, 2019 at 6:06 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> ><br>
>> > I now understand the need for LineSensor and may give it a try for<br>
>> > x3dom. I know freewrl has it. It may make sense to replicate it.<br>
>> ><br>
>> > My initial idea would be to use the x axis of the local coordinate<br>
>> > system as the Line orientation. Or maybe the y axis since X3D<br>
>> > geometries tend to align along y (cylinder, extrusion).<br>
>> ><br>
>> > Then one can construct an intersection plane which includes the x axis<br>
>> > and another direction at a high angle with the viewing direction to<br>
>> > get a clean intersection for the inital point and subsequent points<br>
>> > during dragging.<br>
>> ><br>
>> > Is that how freewrl does it ? I think I saw that it may use an<br>
>> > additional field for the line orientation but it may be best to avoid<br>
>> > it.<br>
>> ><br>
>> > Andreas<br>
>> ><br>
>> > --<br>
>> > Andreas Plesch<br>
>> > Waltham, MA 02453<br>
>><br>
>><br>
>><br>
>> --<br>
>> Andreas Plesch<br>
>> Waltham, MA 02453<br>
>><br>
>> _______________________________________________<br>
>> x3d-public mailing list<br>
>> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>