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

Mon Aug 6 20:47:32 PDT 2018

I have used many routing techniques similar to this, especially by adding proxies. I am just trying to box all the ECMAScript code into a single Function, possibly for all X3DOM browsers on a page, to avoid cross Function shared scoping (is this possible?), then enable the X3D Event model in the code, if we have to.

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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180806/f804b0ab/attachment-0001.html>