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

John Carlson yottzumm at gmail.com
Tue Aug 7 10:17:27 PDT 2018


In other words, I am more worried about bringing an SFNode into the
scenegraph than I am scripts and fields.

On Tue, Aug 7, 2018 at 12:00 PM John Carlson <yottzumm at gmail.com> wrote:

> 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/8c66a005/attachment-0001.html>


More information about the x3d-public mailing list