<div dir="auto"><div>Hi Doug,<br>
<br>based on the bracketed strategy, I added min/maxPosition for screen plane orientation here:<br>
<br>
<a href="https://jsfiddle.net/andreasplesch/mzg9dqyc/201/" rel="noreferrer noreferrer noreferrer" target="_blank">https://jsfiddle.net/andreasplesch/mzg9dqyc/201/</a></div><div dir="auto"><br></div><div dir="auto">Dragging the box is now restricted to a rectangle aligned </div><div dir="auto">to the screen edges aligned.</div><div dir="auto"><br></div><div dir="auto">It feels natural, and I think it would be a good way to use the fields.</div><div dir="auto"><br></div><div dir="auto">Thinking about the semantics, another option would be to make planeOrientation of type SFVec3f holding the normal to the tracking plane, by default 0 0 1. A 0 0 0 value would be special and mean screen parallel.</div><div dir="auto"><br></div><div dir="auto">But offering this flexibility may be more confusing than helpful, so I am not convinced.</div><div dir="auto"><br></div><div dir="auto">There may be another way but introducing a new field may be still necessary.</div><div dir="auto"><br></div><div dir="auto">Another question is what to do with the axisRotation field but I think we had discovered a while ago that browsers already interpret it differently.</div><div dir="auto"><br></div><div dir="auto">Andreas<br><br>
<br>
On Fri, Mar 22, 2019 at 4:45 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> 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 noreferrer 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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 noreferrer 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" target="_blank">x3d-public@web3d.org</a><br>
> >> >> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer noreferrer 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>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</div></div>