[x3d-public] Script Illustrative Example [was: X3D Specification Relationships diagram]

[Andreas Plesch]

Some additional notes:

On Mon, Aug 14, 2017 at 12:47 PM, Leonard Daly <Leonard.Daly at realism.com>
wrote:

> Andreas,
>
> This is very interesting. Cobweb's Script node has access to HTML
> functions. In this case the calculation of the Y position is done in HTML
> script code, while passing values is done in X3D Script code. Since
> JavaScript interprets anything of the form label(...) as a function with
> the name 'label', handles line 69 ("value_changed.y =
> changeY(value_changed.y, time - time0, time);//time is in seconds") just
> fine.
>

As long as 'label' is the name of a reachable function, label() will call
this function. In this case changeY is reachable because it is a global
function.


> This method appears to create a subset of the JavaScript environment where
> the functions all take two arguments (event-data, event-time) and return
> one or more values ('value-changed' in this example).
>

The method is a regular x3d script event function. value_changed is a user
defined output field which is then routed to a transform's translation
field.

Andreas


>
>
> And here is a version which mixes x3d and html scripting:
>
> https://x3d-v4-mixed-scripting.glitch.me/
> forkable source:
> https://glitch.com/edit/#!/x3d-v4-mixed-scripting?path=index.html:69:4
>
> The idea to use a redefinable global function in a x3d field function
> worked fine.
>
> Above now uses regular x3d animation via timesensor and routes. The x3d
> script acts as an interpolator accepting set_fraction input. It does end up
> not using the fraction since the original animation was defined in terms of
> clock time. So the script also uses timestamps and the original changeY and
> linearX global html script functions. The redefinition of changeY via
> button names is unchanged.
>
> It would be nicer to define the interpolators in terms of a fraction but
> that is secondary.
>
> The x3dom approach would be to use its onOutputChange event:
>  https://doc.x3dom.org/tutorials/animationInteraction/onoutp
> utchange/index.html
>
> for defining a custom interpolator.
>
> -Andreas
>
> On Sat, Aug 12, 2017 at 10:40 AM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> Hi Leonard,
>>
>> here is a version of the example which uses cobweb with cobweb-dom for
>> DOM API use.
>>
>> https://x3d-v4-scripting-cobweb.glitch.me/
>> and
>> https://glitch.com/edit/#!/x3d-v4-scripting-cobweb?path=index.html:63:1
>>
>> The necessary changes were minor:
>> - The display area div needed to be replaced with a x3d canvas
>> - The ball div needed to become a sphere shape transform
>> - The ball position is set via the translation attribute rather than
>> position style properties.
>>
>> The viewpoint is at a distance such that 1px in the original div
>> rectangle corresponds to about 1m in the x3d scene when viewed from the
>> viewpoint.
>>
>> Otherwise no changes are needed since full control via the DOM API is
>> possible.
>>
>> I also found that I need to update cobweb-dom to work with the latest
>> cobweb since there were some changes in the cobweb parser. The current
>> cobweb-dom only works with cobweb < 3.0.
>>
>> I suppose the next question is if one can use x3d scripts instead of the
>> html scripts or somehow mix and match. What functionality should be
>> provided in an x3d script ? The tricky thing to try maybe to do the
>> animation inside x3d but replace the x3d interpolator with a custom
>> interpolator from an html script ? Maybe I can think of something.
>>
>> -Andreas
>>
>>
>>
>> On Sat, Aug 12, 2017 at 1:13 AM, Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>>
>>> I went back to the cobweb repo to very carefully read through the rather
>>> mind bending script node code in
>>>
>>> https://github.com/create3000/cobweb/blob/master/cobweb.js/c
>>> obweb/Components/Scripting/Script.js
>>>
>>> and came to the conclusion that the x3d scripts are only evaled once
>>> during initialization, contrary to what I had thought. The script text is
>>> cleverly appended with an array of all defined named functions which then
>>> becomes the return value of the eval call. These functions are then stored
>>> in a local scope this.context object, essentially as methods. Then,
>>> whenever a lifecycle function or a field function needs to be executed, the
>>> context method is called.
>>>
>>> One could probably expose this context object and then redefine its
>>> methods from Dom scripts. However, one would lose the cobweb constructed
>>> "with" "global" object which allows easy and standard access to x3d
>>> functions and user defined fields. It could be probably reconstructed if
>>> needed.
>>>
>>> I may try to convert the example to cobweb dom.
>>>
>>> Andreas
>>>
>>> -The formatting survived the direct mail but not the route through the
>>> list probably because I receive digests.
>>>
>>>
>>> On Aug 11, 2017 9:03 PM, "Leonard Daly" <Leonard.Daly at realism.com>
>>> wrote:
>>>
>>> I was asked by John to construct an example illustrating the items
>>> listed below. I also have replies to Andreas' comments. The original
>>> message is at the bottom (for reference). I've copied the relevant
>>> questions/statements to the top to make reading easier.
>>>
>>> First to the example. It is located at http://tools.realism.com/devel
>>> opment/WG-Support/2017-08-09/ScriptIllustration.html
>>> It does not use Cobweb since I can't begin to figure out how to do this
>>> in Cobweb. OTOH, if X3D is DOM integrated, then the it shouldn't matter
>>> where various functions and methods are located.
>>>
>>> The example is strictly 2D, but I think it clearly illustrates the goal.
>>> The default Y interpolator is nothing (no change). Selecting different
>>> buttons change the interpolator in real-time. Each interpolator is defined
>>> as a function. The variable 'changeY' holds the current interpolator. When
>>> a button is pressed, the value of 'changeY' is set to the selected
>>> interpolator. There is no 'case' statement the uses the correct
>>> interpolator on each pass through the animation loop.
>>>
>>> John if this doesn't illustrate the concept, please explain what you
>>> need to see.
>>>
>>> Andreas, you have done and continue to do a lot in support of web 3D,
>>> especially wrt to X3DOM. I continue to be impressed with your solutions to
>>> problems presented to that list. [I'll have one soon, with a potential
>>> solution.]
>>>
>>>
>>> AP: Mixing DOM and x3d scripts is inherently problematic since x3d
>>> scripts expect their own environment (scope). But let's see.
>>>
>>> AP: Not sure if x3d scripts should be available globally, eg. as
>>> window.foo which means foo is global. This would mean that any other script
>>> or framework needs to be careful not to use the same function names.
>>>
>>> AP: window.x3d should be nicer, as a dedicated namespace. x3dom uses the
>>> x3dom namespace.
>>>
>>> If X3D and HTML are fully integrated then they will be mixed. It is now
>>> common practice to put library methods into their own namescope. This
>>> namescope is not limited, but is prefixed by a known library label (e.g.,
>>> x3dom, THREE, etc.). Mandating that X3D in HTML use the 'x3d' namescope
>>> would cause problems if someone wanted to run two different libraries from
>>> the same HTML context. iframe can fix that, but it seems overly restrictive.
>>>
>>>
>>> function bar(event, time) {
>>>>      window.foo = bar;            // I would (perhaps) settle for
>>>> window.x3d.foo = bar;
>>>> }
>>>>
>>>>
>>> AP: This currently does not work since cobweb goes back to the original
>>> function source each time the script is run. But the x3d script could
>>> probably use internally a global HTML script function which can be
>>> redefined at will, to enable a hook into an x3d script.
>>>
>>> [1]
>>>
>>> <Script ...>    <!-- X3D Script node -->
>>>      function foo (event, time) {
>>>          window.bar = foo;
>>>      }
>>> </script>
>>>
>>>
>>> AP: This probably already works since cobweb evals the function text
>>> almost as is.
>>>
>>> Is this the same as
>>>
>>> [2]
>>>
>>> var foo = function (event, time) {do_work;};
>>> window.bar = foo;
>>>
>>>  ?
>>>
>>> It seems to me that eval the script text each time, especially in an
>>> animation loop, is needlessly expensive.
>>> The two examples (indented if that works in your mail reader) are not
>>> the same. The first example sets window.bar to be 'foo' each time it runs.
>>> The second example only sets window.bar to be 'foo' after the definition is
>>> processed. If there is something else setting window.bar after the 'foo'
>>> function definition is processed, then that definition to 'foo' is never
>>> used.
>>>
>>>
>>> AP: What does the SAI say about manipulating or calling x3d script
>>> functions from the outside ? You may only be able to remove and add
>>> complete script nodes but not work with the script functions ?
>>>
>>> AP: Proposed text would be great. For now, it may be productive to
>>> settle for slightly less integration by keeping x3d scripts pretty much
>>> internal to the x3d context but allow x3d scene control via the DOM, eg.
>>> make x3d nodes similar to svg/html elements.
>>>
>>>
>>> This is my main point. DOM is an API. If X3D chooses to define an API in
>>> HTML, then it must be done so as not to interfere with the DOM API.
>>> Developers will use the DOM API to do things anyway. X3D should only expand
>>> on that, not restrict that. Anything less would not be full integration.
>>> There is no such thing as an SVG Script tag. It is located in the same
>>> space all all HTML scripts.
>>>
>>>
>>> Leonard Daly
>>>
>>> P.S. I hope all of the formatting and styling worked.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 8/11/2017 7:33 AM, Andreas Plesch wrote:
>>>
>>> Date: Thu, 10 Aug 2017 18:31:25 -0700
>>>> From: Leonard Daly <Leonard.Daly at realism.com>
>>>> To: John Carlson <yottzumm at gmail.com>, X3D Graphics public mailing
>>>>         list <x3d-public at web3d.org>, Web3D Consortium <
>>>> consortium at web3d.org>
>>>> Cc: X3D Graphics Working Group <x3d at web3d.org>
>>>> Subject: Re: [x3d-public] [x3d] X3D Specification Relationships
>>>>         diagram
>>>>
>>>
>>> Leonard, thanks for raising this, and I appreciate your attempt to rally
>>> broader support around v4 and web compatibility. I continue to do what I
>>> can which is not too much these days.
>>>
>>> On 8/10/2017 5:17 PM, John Carlson wrote:
>>>> >
>>>> > Leonard wrote:
>>>> >
>>>> > >and node name collisions (i.e., Script).
>>>> >
>>>> > There has been quite a bit of progress with this and X3DJSONLD and
>>>> > X3DOM. It?s been under the covers because I have not advertised it
>>>> > much. I have several scripts running, but not the full complement of
>>>> > my examples.  It does not run the X3D event model yet, except for
>>>> > initialize().
>>>> >
>>>> > Cobweb of course, already handles this, so quit bellyaching.
>>>> >
>>>>
>>>> Cobweb even with Andreas' DOM interface extensions does not integrate
>>>> with the DOM regarding Scripts. A full integration would allow the
>>>> following:
>>>>
>>>>
>>> Mixing DOM and x3d scripts is inherently problematic since x3d scripts
>>> expect their own environment (scope). But let's see.
>>>
>>>
>>>> X3D Script function called 'foo'
>>>> HTML script function called 'bar'
>>>>
>>>> In the body of bar, I should be able to redefine 'foo'. It is (in a
>>>> fully integrated system) available as window.foo. Similarly for inside
>>>> of 'foo' to change 'bar'.
>>>>
>>>>
>>> Not sure if x3d scripts should be available globally, eg. as window.foo
>>> which means foo is global. This would mean that any other script or
>>> framework needs to be careful not to use the same function names.
>>>
>>>
>>>> function bar(event, time) {
>>>>      window.foo = bar;            // I would (perhaps) settle for
>>>> window.x3d.foo = bar;
>>>> }
>>>>
>>>>
>>> window.x3d should be nicer, as a dedicated namespace. x3dom uses the
>>> x3dom namespace.
>>>
>>> This currently does not work since cobweb goes back to the original
>>> function source each time the script is run. But the x3d script could
>>> probably use internally a global HTML script function which can be
>>> redefined at will, to enable a hook into an x3d script.
>>>
>>> and
>>>>
>>>> <Script ...>    <!-- X3D Script node -->
>>>>      function foo (event, time) {
>>>>          window.bar = foo;
>>>>      }
>>>> </script>
>>>>
>>>>
>>> This probably already works since cobweb evals the function text almost
>>> as is.
>>>
>>> Is this the same as
>>>
>>> var foo = function (event, time) {do_work;};
>>> window.bar = foo;
>>>  ?
>>>
>>> I should be able to construct an object with 'foo' as a method. E.g.,
>>>>
>>>> var globalVar = {};
>>>> globalVar.x3d = foo;
>>>>
>>>> // should call the X3D script passing it a reference to the current
>>>> value of 'event' and 'time'.
>>>> globalVar.x3d(event, time);
>>>>
>>>>
>>> It may be possible to 'export' named x3d script functions to window.x3d,
>>> so they can be called. cobweb would currently redefine a named function
>>> each time an x3d script is executed.
>>>
>>>
>>>> Inside 'foo' I should be able to access any DOM element to get it's
>>>> current state or even establish an event listener.
>>>>
>>>
>>> You should be able to do that in cobweb now although it would be strange
>>> to find DOM code in an X3D script. Perhaps for HUD of GUI purposes it could
>>> be useful, actually.
>>>
>>>
>>>> I know there are some things that Cobweb can do, but there has been no
>>>> discussions in the WG for the language that would be necessary to ensure
>>>> HTML/DOM/X3D interaction like I described above.
>>>>
>>>
>>> What does the SAI say about manipulating or calling x3d script functions
>>> from the outside ? You may only be able to remove and add complete script
>>> nodes but not work with the script functions ?
>>>
>>>
>>>> Unrolling scripts on the server (or at least not in the runtime of the
>>>> browser) is all fine and good, but again there has been no discussion in
>>>> the WG as to how to even approach writing that up.
>>>>
>>>> I will be happy to be (relatively) quiet on these points if someone can
>>>> show me working examples and proposed text to make this work.
>>>>
>>>
>>> Proposed text would be great. For now, it may be productive to settle
>>> for slightly less integration by keeping x3d scripts pretty much internal
>>> to the x3d context but allow x3d scene control via the DOM, eg. make x3d
>>> nodes similar to svg/html elements.
>>>
>>> -Andreas
>>>
>>>
>>>>
>>>> --
>>>> *Leonard Daly*
>>>> 3D Systems & Cloud Consultant
>>>> LA ACM SIGGRAPH Chair
>>>> President, Daly Realism - /Creating the Future/
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments
>>>> /20170810/93cc05ca/attachment.html>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of x3d-public Digest, Vol 101, Issue 9
>>>> ******************************************
>>>
>>>
>>> --
>>> Andreas Plesch
>>> 39 Barbara Rd.
>>> Waltham, MA 02453
>>>
>>>
>>> _______________________________________________
>>> x3d-public mailing listx3d-public at web3d.orghttp://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>> --
>>> *Leonard Daly*
>>> 3D Systems & Cloud Consultant
>>> LA ACM SIGGRAPH Chair
>>> President, Daly Realism - *Creating the Future*
>>>
>>>
>>
>>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>
>
> --
> *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/20170814/25425893/attachment-0001.html>