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

Tue Aug 7 05:24:11 PDT 2018

-- AP on the road

On Mon, Aug 6, 2018, 11:47 PM John Carlson <yottzumm at gmail.com> wrote:

> 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?
>
>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/e59d4103/attachment-0001.html>