[X3D-Public] Common translation tool via X3D PlaneSensor?

[doug sanden]

>
> thanks a lot - something like a specific LineSensor node could indeed be useful. Currently, in the example I sent around, the pointer motion is clamped along x or y to achieve the line-like dragging behavior. But using the sensor-local Z=0 plane 

(in my confusion I thought z=0 meant viewpoint z=0)

> internally for sensing motion still seems to be the main drawback when trying to receive motion along a line: at some point, the user will look perpendicular to the plane normal, and receive weird results. It could maybe be helpful to internally use a view-aligned sensor plane, like for billboards?
>

Max,
OK - that makes sense. 
-Doug

more..
I suspect when they were designing the sensor nodes, they probably thought about doing a line sensor, and probably discounted it as not absolutely necessary because with a few more fields they could constrain plane sensor. And back then, the fewer nodes the better. But they probably didn't think all the way through. If they could be here today they would probably say yes go for it.


?
>
>>
>> it seems many people want some tools to realize common 3D "handles"
>> like known from popular modeling programs (Maya, Blender, .) - here's
>> an example from the three.js folks:
>>
>> http://mrdoob.github.io/three.js/editor/
>>
>> Since there have been many requests for such tools in X3DOM, we have
>> started to implement the PointingDeviceSensor component´, as we didn't
>> want to re-invent the wheel and keep conformant with X3D.
>>
>>
>>
>> However, it turned out that it is quite hard to achieve what we want
>> with the PointingDeviceSensor component, especially for the
>> Transformation tool (please find attached a screenshot, as well as the
>> corresponding X3D file).
>>
>> There are two issues where I would be pleased to hear your opinion:
>>
>>
>>
>> 1.) The axisRotation field lets us track pointer motion mapped onto a
>> different plane than the standard Z=0 plane. This is great to realize
>> the handles: For the X and Y handle, we keep the standard orientation
>> of the virtual sensor plane. For the Z handle, we rotate it.
>> However, since the sensors always fire the _unrotated_ transformations
>> (in the local sensor coordinate system), we need to apply an extra
>> rotation above the target transform in order to translate motion on
>> the Z handle properly. Is this intended?
>> My first impression was that it makes the application actually more
>> complicated. InstantPlayer has changed the behavior towards a rotated
>> output (applying the axisRotation) within the last week (dailybuilds
>> only - this is experimental and can be reverted), while bs contact
>> seems to ignore the axisRotation field (it was added in a later
>> version of the spec?).
>>
>
> There might be a case for a LineSensor node. For a LineSensor, the axisRotation or axisVector would/could be parallel to the desired axis of motion in the local coordinate system, rather than perpendicular to it as with the PlaneSensor. It would/could still use Z=0 plane internally for sensing motion, but map/project that 2D motion onto the projection of the axisVector, something like a dot product in Z=0 plane between the drag vector and the axisVector.
> Then the conundrum would be when you are looking straight down the axisVector - something that's more intuitively acceptable to users, and like that seen in three.js.
> -Doug
>
>>
>> 2.) With the PlaneSensor component, there is an obvious drawback when
>> implementing such axis-aligned transformation handles:
>> Since the sensor tracks motion on a plane, we get in trouble when we
>> have a viewing direction that is perpendicular to the plane normal.
>> For the attached example, you can see the problem if you look into the
>> direction of the x-Axis and trigger the y-Axis' handle - in that case,
>> the viewing direction will be perpendicular to the Z=0 plane used by
>> the PlaneSensor, and you will get random transformation results.
>>
>>
>>
>> Especially the second point seems to be caused by us using the
>> PlaneSensor for things for which it was not originally intended.
>>
>> However, I wasn't able to find any other X3D-conformant way to declare
>> such common translation handles. Do you have any idea how X3D could
>> provide something like that? Is there maybe already a proposal for X3D
>> 4.0, which solves this problem?