[x3d-public] PlaneSensor behavior, was: [x3dom-users] port this example to X3DOM?

[Andreas Plesch]

Here is a version with the expected dragging behaviour of the green sphere
in x3dom:

https://jade-aluminum.glitch.me/

Completely separate from the scripting, the only change necessary was to
add an offset field value to PlaneSensor:

https://glitch.com/edit/#!/jade-aluminum?path=views/index.html:38:7

Cobweb and perhaps other x3d browser do not require this offset value for
expected behaviour. This now raises the question which interpretation of
PlaneSensor is correct, eg. should the offset here be necessary ?

http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#PlaneSensor

says:

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

As a relative translation I would interprete this language to mean that
translation_changed starts out with '0 0 0' and then accumulates from
there. In the example, translation_changed is routed to an transform with
an initial translation value of '1 -1 .01' which means that a '0 0 0'
translation would lead to the previously observed initial jump. Adding an
offset therefore seems necessary. So x3dom behaviour seems correct ?
Generally cobweb is more strict in following the spec, so I am little
surprised.

Here is the example without the offset and initial jumping:

https://warm-nape.glitch.me/

Andreas

On Wed, May 31, 2017 at 10:22 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> John,
>
> I could make pretty quick progress to port this to x3d script over to dom
> scripting style:
>
> https://warm-nape.glitch.me/
>
> You can 'remix' the code here:
>
> https://glitch.com/edit/#!/warm-nape
>
> [I like glitch.com, and it has a built in server side]
>
> The structure is pretty close to the original but probably will need to be
> more generalized for easy reuse. It is a starting point anyways.
>
> There is an initial reset of the green ball translation when it is dragged
> first. Not sure where this is coming from but may only need minor fixing.
>
> For routing, the main idea here is to use the x3dom onoutputchange event
> as trigger. Other ideas are certainly possible or perhaps necessary for
> generalization.
>
> This uses get/setFieldValue rather than getAttribute because it is more
> convenient and closer to SAI as it deals with field objects rather than
> strings.
>
> x3dom does not have methods for SFRotations since all rotations get
> immediately translated to quaternions. But this is a detail at this point.
>
> I think I like the idea of returning an object populated by output fields
> from a main script function.
>
> Take a look and feel free to mangle and reorganize,
>
> Andreas
>
>
> On Wed, May 31, 2017 at 4:26 PM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> Hi John,
>>
>> I am going to take a look but do not wait for anything. I believe x3dom
>> has PlaneSensor.
>>
>> https://gist.github.com/andreasplesch/83771ec5959935d309db417387397952
>> for easy access.
>>
>> -Andreas
>>
>> On Wed, May 31, 2017 at 3:44 PM, John Carlson <yottzumm at gmail.com> wrote:
>>
>>> Can someone port the attached example to X3DOM?  It would help with the
>>> X3DOM upgrade effort.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> X3dom-users mailing list
>>> X3dom-users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>>
>>>
>>
>>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>



-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170601/4d17050d/attachment.html>