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

Wed Dec 6 17:13:17 PST 2017

I added another test with the min max clamping:

https://bl.ocks.org/andreasplesch/0894babf2acb9d3afac23c5980d36b7b#PlaneSensorAxisRotation2.x3d

Only x-ite appears to apply axisRotation to the output to produce a
diagonal LineSensor. BS, Instant, and view3dscene do not. WIll look at
the others as well.

pad3 explains for me why axisRotation may be necessary. It does not
help to rotate the local coordinate system because the reported
translation is still relative to it and therefore still has a fixed Y
of 0. It also does not help to rotate the sibling geometry because it
does not affect the local coordinate system of the plane sensor. So
the only way to get rotated translations is with axisRotation.

-Andreas

On Wed, Dec 6, 2017 at 6:39 PM, Andreas Plesch <andreasplesch at gmail.com> wrote:
> Doug,
>
> reading the PlaneSensor spec., I noticed the min/maxPosition clamping
> and how it can be used to make a LineSensor along the X or Y axis of
> the sensor local coordinate system. So perhaps an intended use of
> axisRotation would be a diagonal LineSensor on a rectangle.
>
> But on the other hand, I think the same effect could be achieved by a
> rotated rectangle next to PlaneSensor ?
>
> <Group>
>   <PlaneSensor minPosition='0 -1' maxPosition='0 1'/>
>   <Transform rotation='0 0 1 0.78'>
>     <Shape>
>       <Box size='2 2 0.1' />
>     </Shape>
>   </Transform>
> </Group>
>
> I guess I am still looking for a useful application of axisRotation.
>
> -Andreas
>
>
> On Wed, Dec 6, 2017 at 12:27 PM, doug sanden
> <highaspirations at hotmail.com> wrote:
>> For now I'll harmonize freewrl with the closest compatible interpretations:
>> - view3dscene for cyclinderSensor axisRotation
>> - view3dscene and x3dom for PlaneSensor axisRotation
>> And I'll put a spec comment suggesting it needs clarification.
>> -Doug
>> ________________________________________
>> From: doug sanden <highaspirations at hotmail.com>
>> Sent: December 5, 2017 7:19 AM
>> To: Andreas Plesch
>> Cc: x3d-public at web3d.org
>> Subject: Re: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
>>
>> 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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453

-- 
Andreas Plesch
Waltham, MA 02453