The scene illustrates the proposed screen mode for PlaneSensor. In screen mode, the plane sensor allows dragging of an object in the current plane of the screen. This allows for free manipulation of an objects position.
Drag the red box from the default view point. It will be dragged in the XY (vertical) plane.
Then rotate the view to a map view, or choose the alternative view point pressing PgUp or the button. Drag the box and it will be dragged in the XZ (map) plane.
https://bl.ocks.org/andreasplesch/f196e98c86bc9dc9686a7e5b4acede7d https://gist.github.com/andreasplesch/f196e98c86bc9dc9686a7e5b4acede7d
A common and useful dragging method is to constrain dragging to a plane parallel to the current orientation of screen. This is very intuitive and often what is expected if there is no obvious surface or plane to constrain dragging to. It also allows for flexible yet accurate dragging based on viewpoints with known viewing directions such as a map view or east-west cross-sectional view.
However, X3D currently does not offer such functionality. It has been previously suggested as the function of a PointSensor (implemented in freeWrl). or a SpaceSensor (http://doc.instantreality.org/documentation/nodetype/SpaceSensor/#).
Such a feature is clearly desirable, and would work internally as a regular PlaneSensor where the tracking plane is aligned with the current screent orientation. As in fact it is still a plane which is sensed and PlaneSensor features such as autooffset and min/maxPosition constraints (see below) apply, it would make sense to extend the PlaneSensor node with a new field rather than specifying a new node. Implementation is expected to be straightforward since it is just the orientation of the tracking plane which needs to be reconsidered. Such straightforward implementation has been demonstrated in two browser (x3dom and freeWrl). The proposed extension has the additional advantage that it will allow for other surface based dragging modes in the future.
It is proposed to extend PlaneSensor with a 'planeOrientation' field with this signature:
SFString [out] planeOrientation "XY" ["XY", "screen" ..]
Other potential names for such a field include "trackingPlane" or "trackSurface" or "trackMode".
The default value of "XY" instructs the browser to use the XY plane as the tracking plane (except when in implicit line sensor mode). This default will make the field backward compatible. A value of "screen" instructs the browser to instead use a plane normal to the initial (and normally unchanged) viewing direction when dragging begins. The requirement that the tracking plane is anchored at the intersection of the initial bearing with the sensor's sibling geometry remains unchanged.
min/maxPosition currently is defined as:
"minPosition and maxPosition may be set to clamp translation_changed events to a range of values as measured from the origin of the Z=0 plane of the local sensor coordinate system..."
Since translation_changed would not be restricted to the Z=0 plane of the local sensor coordinate system, in case of a screen tracking plane orientation, the min/maxPosition fields need to be slightly reinterpreted for this case.
translation_changed would be restricted to the screen parallel tracking plane. So clamping of translation_changed should refer to this plane. The limits set by min/maxPosition refer to an X and Y axis, normally to those of the local sensor coordinate system. It is proposed that instead the limits would refer to axes parallel to screen edges. X would refer to the horizontal, and Y to the vertical screen edge, with the origin at the center of the screen. These are the natural directions for these axes, and are given by the view frustum, or clip space.
20.4.2 has this paragraph (http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#PlaneSensor)
"Upon activation of the pointing device (e.g., mouse button down) while indicating the sensor's geometry, an isActive TRUE event is sent. Pointer motion is mapped into relative translation in the tracking plane, (a plane parallel to the local sensor coordinate system Z=0 plane and coincident with the initial point of intersection). For each subsequent movement of the bearing, a translation_changed event is output which corresponds to the sum of the relative translation from the original intersection point to the intersection point of the new bearing in the plane plus the offset value. The sign of the translation is defined by the Z=0 plane of the local sensor coordinate system. trackPoint_changed events reflect the unclamped drag position on the surface of this plane. When the pointing device is deactivated and autoOffset is TRUE, offset is set to the last translation_changed value and an offset_changed event is generated. More details are provided in 20.2.2 Drag sensors."
Here is a version which introduces planeOrientation="screen":
"Upon activation of the pointing device (e.g., mouse button down) while indicating the sensor's geometry, an isActive TRUE event is sent. Pointer motion is mapped into relative translation in the tracking plane. The tracking plane is defined by the planeOrientation field. If the planeOrientation field has a value of "XY", the tracking plane is a plane parallel to the local sensor coordinate system Z=0 plane. If it has a value of "screen", the tracking plane is a plane parallel to the current orientation of the screen or normal to the current viewing direction. In both cases, the tracking plane is coincident with the initial point of intersection.
For each subsequent movement of the bearing, a translation_changed event is output which corresponds to the sum of the relative translation from the original intersection point to the intersection point of the new bearing in the plane plus the offset value. The sign of the translation is defined by the Z=0 plane of the local sensor coordinate system, or the screen plane. ..."
The min/maxPosition paragraph currently reads:
"minPosition and maxPosition may be set to clamp translation_changed events to a range of values as measured from the origin of the Z=0 plane of the local sensor coordinate system. If the X or Y component of minPosition is greater than the corresponding component of maxPosition, translation_changed events are not clamped in that dimension. If the X or Y component of minPosition is equal to the corresponding component of maxPosition, that component is constrained to the given value. This technique provides a way to implement a line sensor that maps dragging motion into a translation in one dimension."
A version which defines min/maxPosition for screen mode could read:
"minPosition and maxPosition may be set to clamp translation_changed events to a range of values. These limits are measured from the origin of the Z=0 plane of the local sensor coordinate system if the planeOrientation field has a value of "XY". If the planeOrientation field has a value of "screen", the limits are measured from the origin of the tracking plane in the direction of the screen edges, horizontally for the x axis components, and vertically for the y axis components. ..."