[x3d-public] PlaneSensor output

[Andreas Plesch]

A current issue on x3dom (https://github.com/x3dom/x3dom/issues/946)
brought up an older discussion:

http://web3d.org/pipermail/x3d-public_web3d.org/2014-March/002773.html

Before clarifying questions about the axisRotation field, perhaps it
is best to confirm my understanding of regular features first.

Only the X-Y plane of the local sensor coordinate system is
considered. Z is ignored. The translation_changed SFVec3f event has
the current displacement from the initial point  as indicated by the
pointing device. This displacement is reported using the local
coordinate system (but perhaps not necessarily the local sensor
coordinate system). This seems to be the only logical coordinate
system to be used but this is not pointed out in the spec. As a
consequence the Z component of the translation_changed value will
always be zero.

Does that sound right sofar ?

One question at this point is what procedure should be used to
determine translation_changed if the local coordinate system changes
during dragging. This happens when the PlaneSensor output is routed to
a parent transform of the PlaneSensor. While probably not appropriate
in most use cases, it appears to be legal.

Presumably, the translation would be still the difference between the
current position of the pointer on the plane and its initial position.
However, a naive implementation could determine the current position
in the updated coordinate system and directly compare it to the
initial position in the initial coordinate system. The net effect
would be probably a very small difference and resulting translation.
So this seems clearly not the right, too naive approach. The actual
difference in position using the same coordinate system needs to be
determined.

Then the question becomes, if the translation_changed event should be
reported in the original local coordinate system, or in the updated,
current local coordinate system.

Thinking further through that it appears that as long as the change in
in the local coordinate system is only a translation, it does not
matter. However, if the change in the local coordinate system (from
other routes) involves a rotation or scale, it would matter. For
rotations, using the updated local coordinate system would result in
translations with a non-zero z component, for example.

So the case where the local coordinate system changes during dragging
may be left undefined by the spec., but the least surprising behavior
may be to report in the original coordinate system. Is that the
intention of the spec. ?

Let's leave it at that. The main question for axisRotation use is, I
think, similarly how the output is reported, eg. in the local sensor
coordinate system (z always 0) or in the local coordinate system (z
not necessarily 0).

Thanks for reading, any feedback welcome,

-Andreas

-- 
Andreas Plesch
Waltham, MA 02453