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

[Limper, Max]

Dear Dave, Dear Yvonne,

thanks for your friendly offerings. I'm aware of how to work with View/Screen coordinates, I did an example some time ago:
http://x3dom.org/x3dom/example/MovingObjectsWithDOMEvents.html

This example is, however, using DOM events and JavaScript code, no X3D nodes.

The question is: If our approach is _declarative_, and based on X3D, how can we achieve simple draggers (Screen-aligned, like in the example, and axis-aligned, like from my first mail) with an X3D-conformant description?
And, if the answer should be "there is no simple way to do that with X3D", should there be tools to enable such draggers in X3D 4.0?

Regards,
Max

-----Ursprüngliche Nachricht-----
Von: X3D-Public [mailto:x3d-public-bounces at web3d.org] Im Auftrag von Dave A
Gesendet: Mittwoch, 5. März 2014 22:34
An: Jung, Yvonne
Cc: x3d-public at web3d.org
Betreff: Re: [X3D-Public] Common translation tool via X3D PlaneSensor?

Yvonne,

Yes it was based on your help, thank you.

I'm very grateful to you and your team for making so many improvements in this technology!
I hope it becomes standard, one way or another.

Dave A

On 3/5/2014 1:26 PM, Jung, Yvonne wrote:
> Wasn't this based on some code I sent you once? If so, Max already got it.
>
> (BTW: Instant Reality has a SpaceSensor for view-aligned movements.)
>
> Concerning Dick's remark: I don't think that the layering component should be part of X3DOM, at least to my mind it doesn't really fit to HTML.
> >From Max' description it seems more like the PlaneSensor is just underspecified for his special case?
>
> Best, Yvonne
>
> Am 05.03.2014 um 20:41 schrieb "Dave A" <dave at realmofconcepts.com<mailto:dave at realmofconcepts.com>>:
>
> I have implemented a screen-oriented dragger, we can talk.
>
> What X3D (and X3DOM) NEEDS if it doesn't have it, is a 'viewport' space, in addition to 'world' space, and functions to convert EASILY between them. Because most people that want to drag editor-style want to do it parallel to the plane of the screen (perpendicular to the camera 'forward' direction) in many cases. This type of thing is made easy by API's in other systems such as Unity. If X3D/om wants to compete, it better have that stuff available.
> IMHO.
> Dave A
>
> On 3/5/2014 2:10 AM, Limper, Max wrote:
> Dear all,
>
> 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?).
>
>
> 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?
>
> Thanks a lot in advance!
>
> Best Regards,
> Max
>
>
>
>
>
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org<mailto:X3D-Public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com<http://www.avg.com>
> Version: 2014.0.4335 / Virus Database: 3705/7153 - Release Date: 
> 03/04/14
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org<mailto:X3D-Public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4335 / Virus Database: 3705/7156 - Release Date: 
> 03/05/14
>
>
>


_______________________________________________
X3D-Public mailing list
X3D-Public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org