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

Richard F. Puk puk at igraphics.com
Wed Mar 5 11:51:33 PST 2014

Hi, Dave –


X3D does have a ‘viewport’ space. Please review the Layering component.
Simply put the viewport in front of the normal world and make the viewport
background transparent.


n  Dick



| Richard F. Puk, Ph.D., President

| Intelligraphics Incorporated

| 7644 Cortina Court

| Carlsbad, CA  92009-8206

| Tel: +1-760-753-9027  Mobile:  +1-760-809-9027

| Email:   <mailto:puk at igraphics.com> puk at igraphics.com





From: X3D-Public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Dave A
Sent: Wednesday, March 5, 2014 11:41 AM
To: Limper, Max; x3d-public at web3d.org
Subject: Re: [X3D-Public] Common translation tool via X3D PlaneSensor?


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.
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:


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,


X3D-Public mailing list
X3D-Public at web3d.org

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4335 / Virus Database: 3705/7153 - Release Date: 03/04/14


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20140305/40250c41/attachment.html>

More information about the X3D-Public mailing list