[x3d-public] Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
doug sanden
highaspirations at hotmail.com
Tue Dec 5 06:19:08 PST 2017
Andreas
Thanks for the x3dom and BS tests.
I can see freewrl has at least the angle sense wrong to match x3dom and view3dscene.
Q. For planesensor does axisRotation mean
a) sensor virtual geometry plane normal, or
b) a full SFRotation applied to local coords to get to sensor-local-coords
If a), then specs could/should change field type and name to SFVec3f .normal or .planeNormal
if b), then specs could/should change field name to .rotation
-Doug
...
And which ever it is, same treatment/sense/meaning for cylindersensor axisRotation.
...
Planesensor >
- freewrl is rotating opposite direction (-angle) to view3dscene and x3dom, but same concept of using axisRotation as an SFRotation
- (my version of instant does planesensor like octaga, h3d, cobweb. I haven't upgraded in several months)
> 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).
And that's the case when axisRotation is default, or more precisely local-coords == sensor-local-coords.
So if you want to give the translation_changed an extra twist, I think all the browsers (except older vivaty) are doing something and it looks like they are re-oriented the sensor plane virtual geometry.
The difference seems to be in how the axisRotation is being interpreted.
The right pad in the scene (repeat of our scene links:
http://dug9.users.sourceforge.net/web3d/tests/sensors/PlaneSensorAxisRotation.x3d
http://dug9.users.sourceforge.net/web3d/tests/sensors/cobweb_planeAxis.html
https://bl.ocks.org/andreasplesch/0894babf2acb9d3afac23c5980d36b7b
) has axisAngle 0 1 0 1.57, in SFRotation terms its a rotation around the Y axis by 90.
Notice in octaga/cobweb/h3d/oldinstant, when you drag on the right plane vertically, it seems to stick around y=0. That can be explained if they are using the xyz of the axisRotation as a sensor plane normal, so the plane normal is going up the screen (Y).
A drag on the left pad -which has axisRotation 0 0 1 1.57- in (octaga/cobweb/h3d/oldinstant) shows no net rotation. That could be explained by these browsers using only the xyz -which is default 0 0 1- and discarding the angle from axisRotation.
H0: older specs did something different
H1: confusion by the name axisRotation which sounds like an axis
So at least perhaps there could/should be some clarification in the specs for planesensor. It has one sentence:
"""
The local sensor coordinate system is created by applying the axisRotation field value to the local coordinate system.
"""
If the specs mean axisRotation to be the plane normal, then then specs should change the name to SFVec3f .planeNormal
If the specs mean axisRotation to be a full SFRotation perhaps the name should just be SFRotation .rotation.
________________________________________
From: Andreas Plesch <andreasplesch at gmail.com>
Sent: December 4, 2017 9:09 PM
To: X3D Graphics public mailing list
Cc: doug sanden
Subject: Re: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
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