[x3d-public] Script Illustrative Example [was: X3D Specification Relationshipsdiagram]
Leonard Daly
Leonard.Daly at realism.com
Mon Aug 14 09:50:05 PDT 2017
Andreas,
This message answers my last question in my previous message with the
caveat that you don't know if it works yet.
Leonard Daly
> Hi John, Leonard,
>
> good point. cobweb_dom may not be necessary with
>
> https://x3d-v4-mixed-scripting.glitch.me/
> <https://x3d-v4-mixed-scripting.glitch.me/>
>
>
> since it does not use direct DOM manipulation for the Scene.
>
>
> With cobweb_dom you can in parallel still manipulate the scene via DOM
> API.
>
>
> I remembered that with cobweb_dom all x3d DOM elements get their x3d
> node object exposed as domNode.x3d . And, indeed, the x3d script
> element, x3dScript=document.querySelector("[DEF=INTERP]"), has a
> property .x3d which has the context array I had referred to earlier.
>
>
> So x3dScript.x3d.context.set_fraction is actually available to an HTML
> script and could be redefined. It could be possible to directly
> redefine set_fraction() although I am not sure if there is a benefit.
>
>
> I am not sure if after it is redefined, the same 'with' expanded
> prototype chain (expanded global) still could be made to apply, and
> how the function context would work. Time for some more experiments.
>
>
> -Andreas
>
>
> On Sun, Aug 13, 2017 at 12:52 PM, John Carlson <yottzumm at gmail.com
> <mailto:yottzumm at gmail.com>> wrote:
>
> Thanks Andreas! I would like to add that you can load the Cobweb
> scene from JSON with my extensions with HTML script, via DOM
> (built into Cobweb—No need for Cobweb_dom). Now if only modifying
> the JS Object would modify the X3D scene and vica versa (TODO,
> suggestion to use Cobweb_dom instead).
>
> I am wondering if the only thing that was failing in my attempt to
> put proxies in my JS “scenegraph” was that they only had set
> proxies, and not get proxies, thus I could not read the value from
> the proxy.
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>
> for Windows 10
>
> *From: *Andreas Plesch <mailto:andreasplesch at gmail.com>
> *Sent: *Sunday, August 13, 2017 12:10 PM
> *To: *Leonard Daly <mailto:Leonard.Daly at realism.com>
> *Cc: *X3D Graphics public mailing list
> <mailto:x3d-public at web3d.org>; John Carlson
> <mailto:yottzumm at gmail.com>
> *Subject: *Re: Script Illustrative Example [was: X3D Specification
> Relationshipsdiagram]
>
> And here is a version which mixes x3d and html scripting:
>
> https://x3d-v4-mixed-scripting.glitch.me/
> <https://x3d-v4-mixed-scripting.glitch.me/>
>
> forkable source:
>
> https://glitch.com/edit/#!/x3d-v4-mixed-scripting?path=index.html:69:4
> <https://glitch.com/edit/#%21/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/onoutputchange/index.html
> <https://doc.x3dom.org/tutorials/animationInteraction/onoutputchange/index.html>
>
> for defining a custom interpolator.
>
> -Andreas
>
> On Sat, Aug 12, 2017 at 10:40 AM, Andreas Plesch
> <andreasplesch at gmail.com <mailto: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/
> <https://x3d-v4-scripting-cobweb.glitch.me/>
>
> and
>
> https://glitch.com/edit/#!/x3d-v4-scripting-cobweb?path=index.html:63:1
> <https://glitch.com/edit/#%21/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 <mailto: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/cobweb/Components/Scripting/Script.js
> <https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/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
> <mailto: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/development/WG-Support/2017-08-09/ScriptIllustration.html
> <http://tools.realism.com/development/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
> <mailto:Leonard.Daly at realism.com>>
> To: John Carlson <yottzumm at gmail.com
> <mailto:yottzumm at gmail.com>>, X3D Graphics
> public mailing
> list <x3d-public at web3d.org
> <mailto:x3d-public at web3d.org>>, Web3D
> Consortium <consortium at web3d.org
> <mailto:consortium at web3d.org>>
> Cc: X3D Graphics Working Group <x3d at web3d.org
> <mailto: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
> <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 <mailto:x3d-public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_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 list
>
> x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> <http://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
>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
--
*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/20170814/f92dd920/attachment-0001.html>
More information about the x3d-public
mailing list