<div dir="ltr"><div>Andreas - tried your x3dom sample - screen mode works great! Great work!</div><div>For freewrl looks like I was clamping to min, max in 3D - ie if your max < min, then it ignors, otherwise it clamps in 3D space and I think that's in Sensor node space. Whether that's useful I don't know.Probably I just copied and pasted from PlaneSensor without testing or thinking too deep.</div><div>-Doug</div><a href="https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/input/SensInterps.c">https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/input/SensInterps.c</a> <div> - line 1500 do_PointSensor<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2019 at 2:46 PM 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,I took the plunge and added a planeOrientation='screen' field<br>
in this exploration:<br>
<br>
<a href="https://jsfiddle.net/andreasplesch/mzg9dqyc/158/" rel="noreferrer" target="_blank">https://jsfiddle.net/andreasplesch/mzg9dqyc/158/</a><br>
<br>
The idea seems to work as advertised. In addition to dragging the<br>
colored axis arrows, it is now possible to drag the grey box itself in<br>
the screen plane whatever the current view may be.<br>
<br>
One thing I noticed is that the min/maxPosition field would need to<br>
have a slightly different meaning since the X and Y axis of the local<br>
coordinate system are not useful in this case.<br>
<br>
Did you have a min/maxPosition field for PointSensor ?<br>
<br>
One possible meaning would be to limit translation in the screen plane<br>
along the horizontal axis and the vertical axis of the screen. I<br>
thought a bit about that and I think it may be very doable but could<br>
not quite finish [The problem I am a bit stuck on is how to project<br>
the intersection point from local coordinates to the new coordinate<br>
system. Perhaps back to world, then world to camera space using the<br>
view matrix, then just setting z=0. Presumably this could work for the<br>
translation directly. Then clamp the translation, and project back:<br>
inverse view matrix and local transform.]<br>
<br>
Another option is to just ignore the field in this case.<br>
<br>
Cheers,<br>
<br>
-Andreas<br>
<br>
<br>
On Fri, Mar 22, 2019 at 11:25 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
> -Doug<br>
><br>
> On Fri, Mar 22, 2019 at 9:12 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> 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>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>