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

John Carlson yottzumm at gmail.com
Tue Aug 7 06:54:29 PDT 2018 

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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>> *From: *Andreas Plesch <andreasplesch at gmail.com>
>> *Sent: *Monday, August 6, 2018 11:34 PM
>> *To: *Leonard Daly <Leonard.Daly at realism.com>
>> *Cc: *John Carlson <yottzumm at gmail.com>; Vincent Marchetti
>> <vmarchetti at kshell.com>; X3D Graphics public mailing list
>> <x3d-public at web3d.org>; x3dom mlist <x3dom-users at lists.sourceforge.net>
>> *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/20180807/02ab4747/attachment-0001.html>

More information about the x3d-public mailing list