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

John Carlson yottzumm at gmail.com
Tue Aug 7 08:39:43 PDT 2018 

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.

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180807/8fc0a7fa/attachment-0001.html>

More information about the x3d-public mailing list