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

Wed Mar 5 14:56:18 PST 2014

Hi, David –

There is a separate binding stack for each of the layers. Therefore, the
mapping between each should be automatic if the geometry is placed in a node
hierarchy acceptable from each layer. Actually, viewports can be place in
any layer and multiple viewports can be overlap each other in screen space.
HUD’s are only one of many different effects that can be achieved.

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: Dave A [mailto:dave at realmofconcepts.com] 
Sent: Wednesday, March 5, 2014 11:57 AM
To: Richard F. Puk; 'Limper, Max'; x3d-public at web3d.org
Subject: Re: [X3D-Public] Common translation tool via X3D PlaneSensor?

Ah, see that's news to me.

So can I transform any point in world space to viewport space and back? Can
I implement a 'drag sensor' in viewport space?

You aren't talking about having geometry parented to the current view, ala
the HUD's of old, right?

Dave A

On 3/5/2014 11:51 AM, Richard F. Puk wrote:

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:  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.
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
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/7153 - Release Date: 03/04/14

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

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