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

Andreas Plesch andreasplesch at gmail.com
Thu Dec 7 18:48:35 PST 2017


Hi Doug,

On Thu, Dec 7, 2017 at 12:26 PM, doug sanden
<highaspirations at hotmail.com> wrote:
> Andreas,
> I'll do another spec comment to update the stale parts of my yesterday comment.
> -Doug
>
> Andreas found the Linesensor configuration of planesensors in all/most browsers did use the rotation angle of axisRotation.
>
> PlaneSensorAxisRotation2.x3d
> - shows plansensor in 'linesensor' mode, with minPosition y = 0, maxPosition y = 0;
> x3dom:
> https://bl.ocks.org/andreasplesch/0894babf2acb9d3afac23c5980d36b7b#PlaneSensorAxisRotation2.x3d
> cobweb:
> http://dug9.users.sourceforge.net/web3d/tests/sensors/cobweb_planeAxis2.html
> native:
> http://dug9.users.sourceforge.net/web3d/tests/sensors/PlaneSensorAxisRotation2.x3d
>
>
> Left Pad:
> sensor axisRotation 0 0 1 .79
> A. Freewrl, x3dom, view3dscene:
> - clamping/minmax range is rotated
> - translation_changed comes out in sensor-local (not local) coords, so is not rotated, but is clamped.
> B. H3D, Octaga, cobweb
> - clamping/minmax range is rotated
> - translation_changed comes out on an angle / in local coords
> C. Instant, Vivaty
> - clamping not rotated
> - translation_changed not rotated
>
> Middle Pad 1:
> no sensor or transform rotation
> All browsers do default planesensor the same
>
> Right Pad 2:
> default (no) axisRotation, attempt to do Linesensor mode using (old fashioned) 2 transforms
> - as a way to reverse engineer the need/purpose for axisRotation field
> Transform rotation 0 0 1 .78
>    Transform rotation 0 0 1 -.79
>       shape
>    /Transform
>    Sensor - no axisRotation
> /Transform
> x3dom, cobweb, freewrl, H3D, instant, octaga, vivaty, view3dscene:
> - 'linesensor' clamp axes are rotated, and output translation is not rotated
> - similar to interpretation A of Left Pad above
> Andreas:
>> 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.
> Doug:
> -for above tests, the translated spherelet/trackingpoint was at the scene root.
> -By putting trackpoint transform inside the right pad 3 transform you can get an angled drag
> -- see lower pad 4 in
>         http://dug9.users.sourceforge.net/web3d/tests/sensors/PlaneSensorAxisRotation3.x3d
> - so a bit more scene plumbing but then even older player vivaty (H: no axisRotation) can do angled linesensor drag
> - therefore linesensor-rotation-convenience-needs not an absolute/definitive answer to need for axisRotation field in PlaneSensor, although its a good/prime hypothesis.
>
>

https://bl.ocks.org/andreasplesch/0d59b7c769565b0e2d1880562fbff1b0

is the x3dom version of PlaneSensorAxisRotation3.x3d

Yes, I suppose it may always be possible to apply what would be the
axisRotation as a transform rotation around the target of the sensor
output translation instead. So I agree that this means there is still
no real need for axisRotation. But would it not have been introduced
for a reason other than convenience ?

In any case, it seems safest to avoid use of axisRotation currently.

-Andreas
>
> ________________________________________
> From: Andreas Plesch <andreasplesch at gmail.com>
> Sent: December 6, 2017 6:56 PM
> To: doug sanden
> Cc: x3d-public at web3d.org
> Subject: Re: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
>
> Octaga behaves like x-ite, eg. produces a diagonal line sensor,
> freeWrl like the other browsers.
>
> To me the Octaga, x-ite behaviour makes the most sense. I think it
> means applying the axisRotation rotation to the local coordinate
> system to produce the sensor local coordinate system but then
> reporting translations with respect to the local coordinate system,
> not the sensor local coordinate system.
>
> I think strictly the same outcome is achieved by applying the
> axisRotation rotation to the sensed translation and reporting the
> rotated translation as output. If this is the case, then I suggest
> that the language in the spec. is adjusted by getting rid of the
> sensor local coordinate system, and instead saying that
> translation(trackpoint)_changed is the result after applying
> axisRotation rotation. To me that would be friendlier and less
> ambiguous for implementers.
>
> Let's see if something similar is also applicable to CylinderSensor ...
>
> -Andreas
>
>
> On Wed, Dec 6, 2017 at 8:13 PM, Andreas Plesch <andreasplesch at gmail.com> wrote:
>> 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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list