[x3d-public] good example for ECMAScripting and Protos?

John Carlson yottzumm at gmail.com
Tue Aug 7 09:00:49 PDT 2018 

I am just thinking about DEFing a script node, then routing or retrieving
fields from it.  I think this is more typical than a DEFed SFNode.   This
is likely easier to handle without X3DOM modifications.

On Tue, Aug 7, 2018 at 11:50 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> On Tue, Aug 7, 2018 at 11:39 AM John Carlson <yottzumm at gmail.com> wrote:
> >
> > Since I am dealing with a DEFed SFNode, once the SFNode has scenegraph
> values, _vf and getFieldValue on the SFNode should be sufficient.   I don’t
> know if DEFs are allowed on field nodes or not.
>
> Pretty sure they are. After all, all nodes except root nodes, are field
> values.
>
> > I’m not sure how you want to handle script fields.   Do what you feel is
> best/most compatible.   I am thinking you may want getFieldValue and _cf
> and _vf on the script node.
>
> There are no particular plans for x3dom to support a script node and
> its fields. If the gate node idea would be helpful, I could take a
> stab at this.
>
> -Andreas
>
> >
> > On Tue, Aug 7, 2018 at 11:13 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >>
> >> In x3dom, getFieldValue is coded here:
> >>
> >> https://github.com/x3dom/x3dom/blob/master/src/NodeNameSpace.js#L115
> >>
> >> It only deals with attribute fields (_vf). You may be able to redefine
> >> the method, first in the script support code, and add children fields
> >> (_cf), eg. SF/MFNode return values.
> >>
> >> -Andreas
> >>
> >> On Tue, Aug 7, 2018 at 9:54 AM John Carlson <yottzumm at gmail.com> wrote:
> >> >
> >> > I am trying to auto convert X3D script to DOM script in the easiest
> way I can.  Without any human intervention.  Thus getFieldValue would be
> important to have on DEFed  SFNodes in scripts.  Unless there is an
> alternative technique (that you may have suggested).
> >> >
> >> > I will look and see what SFNodes look like in Script,  but I’m
> thinking MFNodes, which might be much more difficult to convert to
> properties.
> >> >
> >> > John
> >> >
> >> >
> >> > On Tue, Aug 7, 2018 at 8:24 AM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> -- AP on the road
> >> >>
> >> >> On Mon, Aug 6, 2018, 11:47 PM John Carlson <yottzumm at gmail.com>
> wrote:
> >> >>>
> >> >>> I guess I hope that by activating script fields for X3DOM (perhaps
> not a script node), we get routing on scripts for free. This may make
> things easier?
> >> >>
> >> >> From a dom scripting perspective, it may make things perhaps more
> complicated as I found below. In a sense, x3dom's scripting is complete
> without requiring additional functionality.
> >> >> From a x3d perspective, it may make things more similar to x3d
> scripts. On the other hand if you are on a web page it is appropriate to
> use dom facilities in the first place.
> >> >> Andreas
> >> >>
> >> >>>
> >> >>>
> >> >>> John
> >> >>>
> >> >>>
> >> >>>
> >> >>> Sent from Mail for Windows 10
> >> >>>
> >> >>>
> >> >>>
> >> >>> From: Andreas Plesch
> >> >>> Sent: Monday, August 6, 2018 11:34 PM
> >> >>> To: Leonard Daly
> >> >>> Cc: John Carlson; Vincent Marchetti; X3D Graphics public mailing
> list; x3dom mlist
> >> >>> Subject: Re: [x3d-public] good example for ECMAScripting and Protos?
> >> >>>
> >> >>>
> >> >>>
> >> >>> SVG might be a model to follow as it is well integrated with html5.
> >> >>>
> >> >>> SVG has defs:
> >> >>>
> >> >>> https://svgwg.org/svg2-draft/struct.html#Head
> >> >>>
> >> >>> and use
> >> >>>
> >> >>> https://svgwg.org/svg2-draft/struct.html#UseElement
> >> >>>
> >> >>> A use element clones a copy of the referenced element. This is
> different from a x3d USE reference which _is_ the referenced element (which
> can have multiple parents). Not sure when and how often the cloning happens.
> >> >>>
> >> >>> I think the only purpose of defs is that included elements are not
> immediately rendered. All elements with an id can be referenced by use.
> >> >>>
> >> >>> Option (1) is also what x3dom does with its parallel tree where the
> actual x3d scenegraph is represented. The dom is only an interface, and the
> dom nodes in the x3d node the data.
> >> >>>
> >> >>> That is why it is possible to use the parallel tree approach for
> X_ITE as well. It is possible to treat dom nodes as data here as well and
> map them on the fly and dynamically to the X_ITE scene graph.
> >> >>>
> >> >>> Some more or less connected observations:
> >> >>>
> >> >>> There is still demand for relatively simple, declarative 3d on the
> web. A-Frame and Xseen are really the only other option in this respect.
> >> >>>
> >> >>> For very performant, fancy 3d raw webgl, or three.js or similar
> engine will be preferred since it allows limitless tweaking and minimal
> overhead. Even glTF is considered basic, and has already a lot of vendor
> extensions. It is used outside of the web also, as a replacement for fbx.
> >> >>>
> >> >>> While it is really nice to have cross-platform compatible
> scripting, x3d scripts and dom scripts are just too similar to justify
> introducing x3d scripts in a web page environment. Then how could routing
> be integrated ?
> >> >>>
> >> >>>
> >> >>>
> >> >>> Let's see.
> >> >>>
> >> >>> from script: We can generate all types of x3d field values with a
> Dom script using x3dom.fields. methods. Then we can use direct output style
> to change values of target node fields. Or we can use strings and HTML
> attributes to set a node field from a script.
> >> >>>
> >> >>> to script: this is more tricky. The currently available pathway is
> the onoutputchange event which is available for out fields of all nodes
> when they are updated. So a 'route' consists of a listener to this event on
> the from node which then makes the output value available to a function -
> the script.
> >> >>>
> >> >>> Another pathway from a x3d node to an external Dom script could be
> through a gate node. It would be in effect a no action x3dscript node which
> defines all userdefined fields. It could be routed to normally without code
> changes. A Dom script could then redefine the gate node instance's
> fieldChanged() method which is called by x3dom each time the node receives
> input. This would be quite similar to the x3d script fieldname functions.
> Then we can use direct output style or the .postMessage  method to generate
> out events which can be routed.
> >> >>>
> >> >>> This seems quite complicated, so why not just use direct
> manipulation of x3d nodes and outputchange dom event to receive output from
> x3d nodes ?
> >> >>>
> >> >>>
> >> >>>
> >> >>> Andreas
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Mon, Aug 6, 2018 at 1:41 PM Leonard Daly <
> Leonard.Daly at realism.com> wrote:
> >> >>> >
> >> >>> > John,
> >> >>> >
> >> >>> > In HTML a node can only appear once in the DOM. It is not
> possible for a DOM node to DEF/USE in the sense that X3D requires it. It is
> not required for the 3D scene graph to be in the DOM. That makes the 3D
> content, data within the HTML page. From that perspective (and speaking of
> X3D here), X3D would be embedded in the HTML page, but not part of the DOM.
> This is somewhat equivalent to using a 'data:' URI for an image. The
> information would be all there, but the individual nodes would not be
> accessible as DOM nodes unless explicitly added by the code processing the
> 'data:' URI.
> >> >>> >
> >> >>> > As far as I have been able to tell (and I have been studying this
> issue for 3+ years), the choice is
> >> >>> >
> >> >>> > 1) Include X3D code (tags, protos, scripts, etc.) as data within
> the HTML page and do have it as nodes in the DOM
> >> >>> > 2) Change X3D so it is compatible with and follows the rules
> HTML5 making X3D nodes full members of the DOM
> >> >>> > 3) Change HTML5 so it is compatible with X3D.
> >> >>> > 4) Decide that X3D and HTML5 exist is two separate spaces and
> should not be integrated.
> >> >>> >
> >> >>> > (1) is certainly an option and (I think, perhaps Andreas should
> comment here) this is similar to what X_ITE does
> >> >>> > (2) has been raised for several years and some people are
> absolutely opposed to this
> >> >>> > (3) not going to happen
> >> >>> > (4) not an expressed desired of the Consortium.
> >> >>> >
> >> >>> > XSeen has taken the (2) approach. It supports the DEF/USE concept
> for selected (proper) subset of node capabilities. It also focuses on
> assembly / integration of scene components rather than modeling objects. It
> is expected that most models will be provided by glTF.
> >> >>> >
> >> >>> > Leonard Daly
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > Leonard, I agree my approach may not work in all environments.
> >> >>> >
> >> >>> > Determining a valid or invalid mime type is extremely difficult
> if done semantically, but extremely easy if done syntactically.  My guess
> is that many of the X3D tags are semantically invalid, unless someone has
> added them to Apache.   I do not know the status of this.   I have to add
> mine types to my server for every new extension I add.  It is not a that
> big of a deal.
> >> >>> >
> >> >>> > One may not need a script tag around X3D script to execute X3D
> script.  One may use eval in a script tag.   One may make script
> inconsequential by making the scripts only functions, and move the
> functions to a string which is evaled.  Essentially you are parsing twice.
> >> >>> >
> >> >>> > If we want script fields handled by X3DOM, we will have to find
> someway to bring them into X3DOM.  X_ITE has shown the way.   We can take
> other approaches than X3DOM, like straight DOM.  I am beginning to think
> this is preferable,  but using DEF to find node which aren’t in the
> scenegraph has kind of been, wtf?
> >> >>> >
> >> >>> > The question has become “Are DEFed SFNodes valid scenegraph
> objects if they are in fields?” This may show a failing of X3DOM, which may
> need to be corrected.  I can probably find the scengraph object using USE,
> but I really want to use DEF.   Can someone show me how to do it in the
> HTML5 environment?
> >> >>> >
> >> >>> > John
> >> >>> > On Mon, Aug 6, 2018 at 12:24 AM Leonard Daly <
> Leonard.Daly at realism.com> wrote:
> >> >>> >>
> >> >>> >> I am replying to an early message in this thread, but I hope to
> capture comments from all messages in the thread. My comments only apply to
> the web browser (HTML5) environment.
> >> >>> >>
> >> >>> >> First, any Script tag (in any case) will be handled by the web
> browser, and the web browser will parse content before anything else. If
> you really need to independently parse some tags, you will need to "read"
> it into a JavaScript variable and handle it that way. If it's in the page
> file, it will be parsed.
> >> >>> >>
> >> >>> >> There was a suggestion to use "text/x3dscript" or some other
> string. The W3C has something to say about this at
> https://www.w3.org/TR/html5/scripting-1.html#the-script-element. The
> value of the type attribute must either be
> >> >>> >>
> >> >>> >> omitted
> >> >>> >> JavaScript MIME type
> >> >>> >> "module"
> >> >>> >> any other valid mime type
> >> >>> >>
> >> >>> >> So the use of an invalid MIME type is not technically valid
> HTML. This may cause a problem with some browsers or validators; or present
> future problems if that string is ever defined to have a particular meaning.
> >> >>> >>
> >> >>> >> X3DOM does not have X3D scripting. If you need scripting to
> correctly process an X3DOM environment; then you need to do it in HTML5
> Javascript. X3DOM does not process the Script tag, that is done by HTML5.
> While X3DOM parser could recognize that tag, it does not; hence, none of
> the X3DOM methods are available to handle interactions on a Script node (a
> Script tag parsed into DOM).
> >> >>> >>
> >> >>> >> The X3D Script / HTML5 Script tag name conflict is a
> long-standing and known issue. To my knowledge no work has been done to
> break the conflict.
> >> >>> >>
> >> >>> >> Leonard Daly
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Here’s my current code for clearing the ECMAScript out of a X3D
> file so that it doesn’t show on the screen:
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>                        $(selector+"
> Script").contents().filter(function () {
> >> >>> >>
> >> >>> >>                             return this.nodeType === 3 ||
> this.nodeType === 4;
> >> >>> >>
> >> >>> >>                        }).remove();
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> This retains the fields.  I may change my code to work with
> fields instead of parsing out the fields into properties (but directOutput
> is nice).  This would mean that X3DOM has to route to and from the script
> fields (is this possible?).
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> John
> >> >>> >>
> >> >>> >> Sent from Mail for Windows 10
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> From: John Carlson
> >> >>> >> Sent: Saturday, August 4, 2018 4:56 AM
> >> >>> >> To: vmarchetti at kshell.com; X3D-Public; x3dom mlist; Andreas
> Plesch
> >> >>> >> Subject: RE: [x3d-public] good example for ECMAScripting and
> Protos?
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> I have a problem with this file in X3DOM, because as far as I
> can tell, the SFNode fields (the node, not the field) do not have
> getFieldValue for point etc. as a function, for example (but one can double
> check me).  In other words, I don’t think this node is an X3DOM node.
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Thus I cannot take a reasonable length in the script.  One would
> have to parse the string.
> >> >>> >>
> >> >>> >>
> >> >>> >> That’s as clear as I can get.  I think this might be because
> x3dom does not process scripts correctly. We would need a script tag
> handler, and a field handler inside that.
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Can you help Andreas?  I’ve created a script tag before, but
> that code is lost. It might be in my GitHub repository somewhere, not sure.
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> We just need a script tag that has fields, but doesn’t execute
> its CDATA section.  I am pretty sure
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> How is V4.0 handling this?
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Alternatively, I can change my nodeUtil code to look at the type
> and do the right thing converting a string to the correct type.
>  Suggestions are welcome.
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Thanks for the great example, Vince,
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Should I adapt my code to deal with this failing in X3DOM, or
> should we change X3DOM?
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> John
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Sent from Mail for Windows 10
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> From: vmarchetti at kshell.com
> >> >>> >> Sent: Wednesday, August 1, 2018 9:04 PM
> >> >>> >> To: John Carlson; X3D-Public
> >> >>> >> Subject: Re: [x3d-public] good example for ECMAScripting and
> Protos?
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> See
> >> >>> >>
> >> >>> >>
> http://www.kshell.com/pages/pointcloudvisualization/SphereDirectedPointSet.x3d
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> It is a X3D file with with a Prototype + ecmascript definition
> of a point cloud, with a vector attached to each point of the cloud.
> >> >>> >>
> >> >>> >> Example used is just points randomly distributed on sphere with
> directs pointed radially outward.
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Potential uses would be to implement the scanning design pattern
> at
> http://x3dgraphics.com/examples/X3dForAdvancedModeling/Scanning/X3dMeshDesignPatternIndex.html
> , or
> >> >>> >>
> >> >>> >> visualizing fluid flow or  electromagnetic field
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> On Jul 31, 2018, at 10:30 PM, John Carlson <yottzumm at gmail.com>
> wrote:
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Is there a good example of ECMAScripting in X3D that I can use
> to test my X3D JSON ECMAScript preprocessor?  Preferably with Protos
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> Thanks!
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> John
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> _______________________________________________
> >> >>> >> x3d-public mailing list
> >> >>> >> x3d-public at web3d.org
> >> >>> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> _______________________________________________
> >> >>> >> x3d-public mailing list
> >> >>> >> x3d-public at web3d.org
> >> >>> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >> >>> >>
> >> >>> >>
> >> >>> >> --
> >> >>> >> Leonard Daly
> >> >>> >> 3D Systems & Cloud Consultant
> >> >>> >> LA ACM SIGGRAPH Past Chair
> >> >>> >> President, Daly Realism - Creating the Future
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Leonard Daly
> >> >>> > 3D Systems & Cloud Consultant
> >> >>> > LA ACM SIGGRAPH Past Chair
> >> >>> > President, Daly Realism - Creating the Future
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Andreas Plesch
> >> >>> Waltham, MA 02453
> >> >>>
> >> >>>
> >>
> >>
> >>
> >> --
> >> Andreas Plesch
> >> Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180807/f5046d94/attachment-0001.html>

More information about the x3d-public mailing list