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

Andreas Plesch andreasplesch at gmail.com
Sun Dec 3 14:17:52 PST 2017


>
> 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
x3dom:  does not rotate rotation_changed, does not translate little sphere
(no trackpoint_changed event?)

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 ?

-Andreas

-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171203/67850f63/attachment.html>


More information about the x3d-public mailing list