[x3d-public] [x3dom-users] port this example to X3DOM?

Fri Jun 2 15:08:05 PDT 2017

On Fri, Jun 2, 2017 at 5:33 PM, Leonard Daly <Leonard.Daly at realism.com>
wrote:

> Andreas,
>
> directOutput is tricky and probably not well defined. Since there is only
> language for V3.3- and that does not discuss DOM, I wish to keep this
> discussion strictly in the confines of V3.3. A follow-up message will
> address DOM.
>
>
Yes, there was another thread about directOutput as well.

> In the 8th paragraph (depending on how you count, the one that starts
> "Once the script has access...") of 29.4.1 (http://www.web3d.org/
> documents/specifications/19775-1/V3.3/Part01/components/scripting.html)
> states
>
> "...script may also send events directly to any node to which it has
> access..."
>
> Also 29.2.6 states
>
> *Script
> <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/scripting.html#Script>**
> nodes that have access to other nodes (via SFNode and MFNode fields) and
> that have their **directOutput** field set to **TRUE** may directly post
> events to those nodes. They may also read the last value sent from any of
> the node's fields.*
>
> *When setting a value in another node, implementations shall set values in
> other nodes by sending input events to the corresponding fields. These
> events shall be part of the current event cascade (see **4.4.8.3
> Execution model
> <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#ExecutionModel>*
> *).*
>
>
Indeed, I saw this section but did not remember what is discussed below
which does seem somewhat ambiguous. This section made me prefer the
solution which allows continued routing from output fields in nodes
directly changed by scripts.

> Also section 4.5 of 19775-2 (SAI - http://www.web3d.org/
> documents/specifications/19775-2/V3.3/Part02/concepts.html#Events) has
> stuff to say about events. Section 4.5.1 states:
>
> "Any transient data is carried around the X3D scene graph through the use
> of events."
>
> Which implies that any data that goes from one node to another is through
> events; however, 4.5.2 states:
>
> "If an internal interaction directly writes to an output-capable field of
> another node, no event is generated and therefore does not form part of the
> event cascade."
>
> It is not clear if a Script node's directOutput is an internal interaction
> or not.
>
>
> What else could be an internal interaction ?

> However (again) in section 4.8.3.1, 3rd paragraph
>
> "Internal interactions also permit direct interaction with fields of other
> nodes, or some browser operations without participating in the event
> cascade. This action shall only be allowed dependent on the value of the
> *directOutput* field setting"
>
> So this implies that directOutput data is not an event and happens
> external to the cascade. There is additional text in terms of capabilities
> and restrictions in the rest of that section. I have not been able to fully
> absorb it.
>
I agree, this does seem to imply that.

>
> I would be careful of any conformance suite regarding direct output. The
> spec language is dense and not obviously clear as to what shall happen, may
> happen, and shall not happen.
>
>
> Well, the next best thing is to check what other browsers are doing with
directOutput affect nodes.

-Andreas

On Fri, Jun 2, 2017 at 3:19 PM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> ... Is there a conformance example ?
>>
>>
> There is one which uses directOut:
>
> http://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/
> Script/ScriptNodeFieldControl_EcmaScriptIndex.html
>
> But it does not test event generation and cascading as far as I can see.
> Also, cobweb does not seem to work with it indicating issues somewhere.
>
> -Andreas
>
>
>>
>> On Fri, Jun 2, 2017 at 11:34 AM, Joe D Williams <joedwil at earthlink.net>
>> wrote:
>>
>>> Yes, the script that uses directOut is like a DOM script.
>>> Operationally, I think it is important to recognize that the directOut
>>> in x3d was designed to not produce an event directly. The x3d event is
>>> produced when the target node field is changed. In other worls, see that
>>> you cannot route an event from the directOut. The changed event must be
>>> generated by watching the target field of the node used by the directOut.
>>>
>>> Joe
>>>
>>>
>>>
>>> riginal Message ----- From: "Andreas Plesch" <andreasplesch at gmail.com>
>>> To: "John Carlson" <yottzumm at gmail.com>
>>> Cc: "x3dom mlist" <x3dom-users at lists.sourceforge.net>; "X3D Graphics
>>> public mailing list" <x3d-public at web3d.org>
>>> Sent: Friday, June 02, 2017 8:11 AM
>>> Subject: Re: [x3d-public] [x3dom-users] port this example to X3DOM?
>>>
>>>
>>> John,
>>>>
>>>> I realized that the ported script uses what is equivalent to the
>>>> directOutput style of x3d scripts. This means that it may be possible to
>>>> convert directOutput scripts to x3dom scripts in general using the
>>>> pattern
>>>> in the ported example.
>>>>
>>>> The 'from' portion of Routes into the script would become 'outputchange'
>>>> listeners attached to the fromNodes with event handlers. The 'to'
>>>> portion
>>>> of Routes into the script is used inside the event handler which then
>>>> calls
>>>> the appropriate set script function.
>>>>
>>>> The directOutput nodes can be retrieved by scene.querySelector(). The
>>>> SAI
>>>> node.field syntax can be translated to node.get/setFieldValue or
>>>> perhaps to
>>>> node._x3dom.field (or similar).
>>>>
>>>> intialize() script functions can be run at document.onload time or
>>>> probably
>>>> better using x3dom.runtime.ready
>>>> https://doc.x3dom.org/author/runtime.html#ready
>>>>
>>>> There are probably lots of pitfalls, and does not address regular (non
>>>> directOutput) script nodes. -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/83771ec5959935d309db41
>>>>>> 7387397952
>>>>>> 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
>>>>
>>>>
>>>
>>> ------------------------------------------------------------
>>> --------------------
>>>
>>>
>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>
>>>>
>>>
>>
>>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>
>
> ------------------------------------------------------------------------------
> 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 listX3dom-users at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/x3dom-users
>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - *Creating the Future*
>

-- 
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/20170602/1c622420/attachment-0001.html>