<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Andreas and Doug,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I haven't experimented with the fiddle
yet, but I was wondering what happens when the virtual world is
displayed in a head-mounted display (HMD). I think it would be OK
in the normal upright position (head straight up, look at the
horizon). <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Now the user tilts her head. Do the
"lines" continue to follow the HMD coordinate system, or is there
something that keeps them aligned with the vertical objects in the
world? Note that vertical virtual objects will need to stay
vertical relative to the external coordinate system; otherwise she
will start to experience significant virtual-induced real motion
sickness.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Leonard Daly</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:CAKdk67u=T0amPPREjd380d1npgSqmOspM3iKhRF3WGKq244BPw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">x3d-public@web3d.org</a><br>
> >> >> <a
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>