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

Joe D Williams joedwil at earthlink.net
Sat Jun 3 14:29:24 PDT 2017 

     > I forget if I ever really want to use my current this as a 
directOut object ...

      https://www.ecma-international.org/ecma-262/5.1/#sec-10.3

      ThisBinding:

      "It is impossible for an ECMAScript program to access an 
execution context."

      This probably means I ahouldn't try to use my current this as a 
directOut object.

      Joe



----- Original Message ----- 
From: "Joe D Williams" <joedwil at earthlink.net>
To: "Joe D Williams" <joedwil at earthlink.net>; "Andreas Plesch" 
<andreasplesch at gmail.com>; "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 12:02 PM
Subject: Re: [x3d-public] [x3dom-users] port this example to X3DOM?


>> Yes, the script that uses directOut is like a DOM script.
>
> i guess that is the long way of talking about some detail, just that 
> whether or not the this includes the directOut reference? And, maybe 
> shouldn't have mentioned dom because after all, i may not be all up 
> to date with the dom.
>
> I think the x3d script node as a special sensor node much like any 
> other node, designed so that all events are sent at the time of 
> completion of the script, all with the same time stamp the 
> initiating event thaat started our this. (And special script 
> functions like initialize, shutdown, etc. available but that is not 
> discussed here.)
>
> DirectOut gives a way around that basic x3d script node feature, 
> which is very confining for some introductory applications where you 
> either don't care about exact timing or are not provided with the 
> concept of the x3d timestamp and event cascade - where all events in 
> the author's intended cascade are executed as 'instantaneously' like 
> all at the same time and all in the same frame and then evaluation 
> of the next set of events used to create the next frame can begin to 
> be processed.
>
> So, again, am i reasonable in understanding the overall maybe minor 
> detail that the script is, well, can I say, not responsible for 
> emitting the _changed event for the field update caused by use of 
> directOut in the script? Nor can I use a script interface to 
> directly route an event into a field of a node used as directOut.
>
> It is the field in the node that gets changed that must be source of 
> the _changed event. For all other script interfaces the def of the 
> script is the this and can use this.name in routes.
>
> All except the stuff involved by use of directOut node in the this.
> Please discuss with me here if any of x3d script, of the this, by 
> the this, and for the this is unclear.
>
> Because those are also why there is the idea that x3d script 
> directOut is intended to generate the directOut updates 'outside' 
> the current cascade, like immediately when viable; use of timestamps 
> can get complicated but trackable. For instance, when the target 
> field update is produced immediately then the author can then detect 
> the _changed event maybe independently of current this script 
> events.
> Maybe other stuff, maybe details associated with end/beginupdate 
> features of the SAI?
>
> So, i do need some help, but the way it is that, ok all is running 
> well but maybe a bit of drift or something, maybe like sort of 
> calibrating some mechanical device such as some sort of distribution 
> thing with the big end of the screwdriver. You know, the little 
> special turn that needs to be done only when specially needed to 
> make it sound best or just right; then I can give it a hit with a 
> directOut and I may be able to find out what was done to the target 
> node maybe without waiting for the script to complete? Well, why 
> would I want a script running with some sort of potential loop 
> 'outside' the this anyway? I forget if I ever really want to use my 
> current this as a directOut object ...
>
> Thanks and Best,
> Joe
>
>
>
>
>
>
> .
>
>
>
> ----- Original Message ----- 
> From: "Joe D Williams" <joedwil at earthlink.net>
> To: "Andreas Plesch" <andreasplesch at gmail.com>; "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:34 AM
> Subject: Re: [x3d-public] [x3dom-users] port this example to X3DOM?
>
>
>> 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/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
>>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>
>

More information about the x3d-public mailing list