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

Andreas Plesch andreasplesch at gmail.com
Wed Dec 6 15:39:29 PST 2017 

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

More information about the x3d-public mailing list