[x3d-public] Player inconsistency > CylinderSensor > interpretation of local vs sensor-local

Andreas Plesch andreasplesch at gmail.com
Mon Dec 4 20:09:01 PST 2017


Here is the x3dom PlaneSensor test version:

https://bl.ocks.org/andreasplesch/0894babf2acb9d3afac23c5980d36b7b

It behaves like Instant, eg. dragging horizontally on the left panel
leads to vertical translation of the ball.

BS Contact behaves like Octaga and cobweb.

I think the translation_changed translations have to be relative to
the local coordinate system, not relative to the sensor local
coordinate system since the translations will be applied (in most
cases) to transforms in the local coordinate system (and not in the
sensor local coordinate system).

It seems it will be necessary to clearly state the intent of the
axisRotation field (and not just its effect). Why do we need it ?

-Andreas


On Mon, Dec 4, 2017 at 3:00 PM, <x3d-public-request at web3d.org> wrote:
>
> Message: 1
> Date: Mon, 4 Dec 2017 15:22:43 +0000
> From: doug sanden <highaspirations at hotmail.com>
> To: "x3d-public at web3d.org" <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Player inconsistency > CylinderSensor >
>         interpretation of local vs sensor-local
> Message-ID:
>         <MWHPR1401MB19828209A7806EB323A25583B63C0 at MWHPR1401MB1982.namprd14.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hypothesis (for planesensor inconsistency):
> - some browsers interpret axisRotation to be an xyz axis vector (and ignor the rotation angle)
> -- octaga, instant, cobweb, h3d
> - some browsers interpret axisRotation to be an SF rotation and do nothing if angle is 0
> -- freewrl, view3dscene
>
> ________________________________________
> From: doug sanden <highaspirations at hotmail.com>
> Sent: December 4, 2017 8:05 AM
> To: x3d-public at web3d.org
> Subject: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
>
> Thanks very much Andreas for looking into this.
> > > To me the intended function of the axisRotation field is to control the direction of the rotation output such that rotations other than about the Y axis become available. If that is the case then the rotation_changed output should be affected by the axisRotation field, eg. be rotated.
> > >
> > > A related question is if the axisRotation field is intended to provide functionality which cannot be achieved by wrapping the Sensor in a Transform with the same rotation value which would also result in a rotated sensor local coordinate system. Presumably the answer is yes in order to justify its existence but I am not sure.
>
> That sounds interesting. We can't wrap a sensor in its own transform - it has to be a sibling to the sensitized geometry. So axisRotation might have been designed as a way to give it a bit of transform of its own.
>
> PlaneSensor also has axisRotation. Maybe that's clearer.
> http://dug9.users.sourceforge.net/web3d/tests/sensors/PlaneSensorAxisRotation.x3d
> http://dug9.users.sourceforge.net/web3d/tests/sensors/cobweb_planeAxis.html
> - left planesensor (invisible geometry) is rotated about z 90 by axisRotation
> - right planesensor is rotated about y 90 (so its almost edgewise)
>
> In freewrl, by rotating only the invisible sensor geometry, the translation_changed is still in sensor-local coordinates.
> Dragging on the left planesensor, does the translation_changed come out at 90 (y when you drag x)?
> instant  no
> octaga no
> vivaty no
> h3d no
> cobweb no
> view3dscene yes
> freewrl yes
>
> More inconsistency. Help!
> -Doug
>
> > >>
> > >> Date: Sun, 3 Dec 2017 18:02:47 +0000
> > >> From: doug sanden <highaspirations at hotmail.com>
> > >> To: "x3d-public at web3d.org" <x3d-public at web3d.org>
> > >> Subject: [x3d-public] Player inconsistency > CylinderSensor >
> > >>         interpretation of local vs sensor-local
> > >> Message-ID:
> > >>         <MWHPR1401MB1982C8C77F571F605CDE02DBB63F0 at MWHPR1401MB1982.namprd14.prod.outlook.com>
> > >>
> > >> Content-Type: text/plain; charset="iso-8859-1"
> > >>
> > >> I noticed a bit of inconsistency among players when axisRotation is non-default.
> > >> I wonder what's right.
> > >> -Doug
> > >>
> > >> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#CylinderSensor
> > >> """
> > >> ... pointer motion (e.g., a mouse or wand) into a rotation on an invisible cylinder that is aligned with the Y-axis of the local sensor coordinate system. The local sensor coordinate system is created by applying the axisRotation field value to the local coordinate system.
> > >> ...
> > >> rotation_changed event is sent that equals the sum of the rotation about the +Y-axis vector of the local sensor coordinate system
> > >> ...
> > >> trackPoint_changed events reflect the unclamped drag position on the surface of the invisible cylinder. [Q, in local or sensor-local?]
> > >> """
> > >> Q, Does that mean we should
> > >> - rotate the invisible sensor geometry by axisRotation
> > >> - leave rotation_changed in sensor-local
> > >> - put trackpoint_changed  into local coordinates (not sensor-local)?
> > >>
> > >> more..
> > >>
> > >> http://dug9.users.sourceforge.net/web3d/tests/sensors/CylinderSensorCylinderAxisRotation90.x3d
> > >> (http://dug9.users.sourceforge.net/web3d/tests/sensors/CylinderSensorCylinder.x3d default axisRotation)
> > >> http://dug9.users.sourceforge.net/web3d/tests/sensors/cobweb90.html
> > >> routing:
> > >> - box is rotated by rotation_changed
> > >> - little sphere is translated by trackpoint_changed
> > >>
> > >> player:         rotates:
> > >> octaga - sensor-geometry, rotation_changed, trackpoint_changed
> > >> instant - sensor-geometry, rotation_changed, trackpoint_changed moves diagonally
> > >> H3D     - sensor-goemetry, rotation_changed
> > >> vivaty - nil
> > >> view3dscene - sensor-geometry, trackpoint_changed
> > >> freewrl - sensor-geometry
> > >> cobweb - sensor-geometry, rotation_changed
> > >>
> > >
> > >
> > > Two more players:
> > > BS Contact: does not rotate rotation_changed, little sphere stays with dragging mouse pointer
> >
> > Ok, on a 2014 version the console has an error message that the
> > axisRotation field value could not be set. So no surprise that it had
> > no effect.
> >
> > >
> > > x3dom:  does not rotate rotation_changed, does not translate little sphere (no trackpoint_changed event?)
> >
> > I looked into the implementation. I believe it would be
> > straightforward to apply the axisRotation rotation to the
> > rotation_changed output.
> >
> > >
> > > https://bl.ocks.org/andreasplesch/34d6c24972d37a0ad9e2070cf3a8a2c6
> > >
> > > Focusing on rotation_changed as the principal node output we then have:
> > >
> > > Octaga, Instant, H3D, cobweb : rotate by axisRotation
> > > BS, x3dom, view3dscene, freewrl: do not rotate by axisRotation
> > >
> > > 4:4, a perfect split (!).
> > >
> > > To me the intended function of the axisRotation field is to control the direction of the rotation output such that rotations other than about the Y axis become available. If that is the case then the rotation_changed output should be affected by the axisRotation field, eg. be rotated.
> > >
> > > A related question is if the axisRotation field is intended to provide functionality which cannot be achieved by wrapping the Sensor in a Transform with the same rotation value which would also result in a rotated sensor local coordinate system. Presumably the answer is yes in order to justify its existence but I am not sure.
> > >
> > > For reference, here are the conformance scenes but they do not seem to include non-default axisRotation sensors:
> > >
> > > http://www.web3d.org/x3d/content/examples/ConformanceNist/Sensors/CylinderSensor/index.html
> > >
> > > Perhaps axisRotation was introduced relatively later ?
> >
> > It looks the field was introduced in 2008 with v 3.2 since 3.1 and 3.0
> > do not seem to have it ? So there should be some discussion somewhere
> > ?
> >
> > >
> > > -Andreas
> > >
> > > --
> > > Andreas Plesch
> > > Waltham, MA 02453
> >
> >
> >
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
> >
> >
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 105, Issue 4
> ******************************************




-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list