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

[doug sanden]

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
> 
>