<div dir="ltr">Looks like I should have pulled in ComposedShader for dealing with fields. Tomorrow perhaps, or later tonight. Perhaps that's why my scripts weren't really functional! LOL!<div><br></div><div>I will probably look at ProtoDeclare or ExternProtoDeclare in gh-pages too!</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 30, 2020 at 10:11 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Looks like many examples work! Congratulations! Andreas, the source file I copied X3DScript.js from was ShaderPart.js. ShaderPart.js has custom fields and url field. But there may be scoping requirements for X3DScript.js? I'm wondering now how to integrate X3DScripts with the ROUTEing mechanism.<div><br></div><div>I've backed my master out to x3dom/x3dom master, because I'm a klutz at git presently. I should probably use a better GUI than bash for git. Hmm. What JavaScript IDE do you recommend for git?</div><div><br></div><div>Looks like you've got a large supply of examples. I hope to provide some scripting examples soon. I have a two pronged approach 1) integrating X3DScript fields with ROUTEs 2) Getting JavaScript functions working in X3DScripts.</div><div><br></div><div>I am proceeding under the assumption that Protos and X3DScripts will work magically with each other :)</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 29, 2020 at 8:43 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/ViewFrustumPrototypeIndex.html" rel="noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/ViewFrustumPrototypeIndex.html</a><br>
<br>
ViewpointNode is a field name of both the ViewFrustrum Proto and also<br>
of the ComputationScript. The code is from registering the new node<br>
defined by the proto. It wants to define the type of the new node's<br>
node fields, here the ViewpointNode field. It needs to be the same<br>
type as the IS connection for which it is used. The IS connects the<br>
field to X3DScript field with the same name. The node type in x3dom<br>
just corresponds to its constructor. If you use the standard pattern<br>
to register a new node the type is automatically assigned.<br>
<br>
X3DScript is similar to ProtoDeclare in that it defines its own<br>
fields. Actually, simultaneously it is also its own instance. There is<br>
not enough information to derive the type of the node field of a<br>
X3DScript. It can be any type. It will be probably ok for x3dom to<br>
just assign the X3DNode node type. This is the default type in the<br>
code below. This should be done in the X3DScript code which generates<br>
the new node for the script. It is also probably wise to guard against<br>
a non-existing type where the error occurs, by checking for it<br>
although this should not happen.<br>
<br>
if ( "field" in ISNode._cf[ nodeField ] ) { type = ISNode._cf[<br>
nodeField ].type; }<br>
<br>
-Andreas<br>
<br>
On Mon, Jun 29, 2020 at 8:06 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
><br>
> I created X3DScript.js as the first attempt at adding a <X3DScript> tag.<br>
><br>
> Example (ViewFrustum) attached.<br>
><br>
> I'm having a bit of a problem with the Viewpoint IS child. An exception is being thrown.<br>
><br>
> Andreas, you don't need to solve any script problems, unless you want to figure out why the url isn't being set.<br>
><br>
> I have an eval where I think the url loading is appropriate for now. We may want to move script loading somewhere else.<br>
><br>
> I don't currently handle embedded scripts. That will require more thinking.<br>
><br>
> I hope you can find this code in X3DOM. I have commented with /// where the issue is<br>
><br>
> //find node type from IS in body<br>
> var ISRoutes = that._protoBody._ISRoutes;<br>
> var ISconnection = ISRoutes[ <a href="http://field.name" rel="noreferrer" target="_blank">field.name</a> ][ 0 ];<br>
> var nodeField = ISconnection.nodeField;<br>
> var ISDomNode = that._protoBody.querySelector( "[DEF=" + ISconnection.nodeDEF + "]" );<br>
> //create temp node to get type<br>
> var type = x3dom.nodeTypes.X3DNode;<br>
> var IStype = ISDomNode.localName.toLowerCase();<br>
> if ( IStype in x3dom.nodeTypesLC )<br>
> {<br>
> var ISNode = new x3dom.nodeTypesLC[ IStype ]( ctx );<br>
> type = ISNode._cf[ nodeField ].type; /// Can't handle nodeField === "ViewpointNode"<br>
> }<br>
><br>
> zip link below with start of X3DScript.js and data files, and package file in x3dom.<br>
><br>
> I think this is the IS that's failing:<br>
><br>
> <IS><br>
> <connect nodeField='visible' protoField='visible'/><br>
> <connect nodeField='ViewpointNode' protoField='ViewpointNode'/><br>
> <connect nodeField='NavigationInfoNode' protoField='NavigationInfoNode'/><br>
> <connect nodeField='aspectRatio' protoField='aspectRatio'/><br>
> <connect nodeField='trace' protoField='trace'/><br>
> </IS><br>
><br>
> Could it be that a trailing "ode" on the fields is throwing things off? IDK.<br>
><br>
> <a href="http://coderextreme.net/script.zip" rel="noreferrer" target="_blank">http://coderextreme.net/script.zip</a><br>
><br>
> It will take me a while to recreate my x3dom repo, so you can diff my x3dom code. I will do that next.<br>
><br>
> John<br>
><br>
> On Mon, Jun 29, 2020 at 5:41 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> Yes, the view frustum example requires a script.<br>
>><br>
>> I have added the t1 example (and found the t.wrl inline) to<br>
>><br>
>> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
>><br>
>> It worked fine.<br>
>><br>
>> I another folder, I converted all examples to the non-standard concise<br>
>> proto instance node syntax which x3dom will support:<br>
>><br>
>> <TwoColorTable legColor="1 0 0" topColor="0 1 0"></TwoColorTable><br>
>><br>
>> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/x3dom.htm" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/x3dom.htm</a><br>
>><br>
>> Take a look at the x3d code below the viewer.<br>
>><br>
>> I discovered one issue doing that which could be resolved. I think all<br>
>> examples work with that more concise syntax. containerField hints for<br>
>> node values may be necessary in cases.<br>
>><br>
>> Any feedback or non-script examples are still very welcome.<br>
>><br>
>> -Andreas<br>
>><br>
>> On Mon, Jun 29, 2020 at 3:28 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> ><br>
>> > I think I concluded that the ViewFrustum (proto3.html) example required a script.<br>
>> ><br>
>> > On Mon, Jun 29, 2020 at 2:26 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Here's another example which I couldn't really get right in X3DOM.<br>
>> >><br>
>> >> <a href="https://coderextreme.net/X3DJSONLD/src/main/html/proto3.html" rel="noreferrer" target="_blank">https://coderextreme.net/X3DJSONLD/src/main/html/proto3.html</a><br>
>> >><br>
>> >> Works okay in X_ITE.<br>
>> >><br>
>> >> On Mon, Jun 29, 2020 at 2:01 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> I am fairly sure:<br>
>> >>><br>
>> >>> <component name='Networking' level='2'/><br>
>> >>><br>
>> >>> Is required for t1.x3d.<br>
>> >>><br>
>> >>><br>
>> >>> On Mon, Jun 29, 2020 at 1:42 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >>>><br>
>> >>>> Here's a link that shows essentially the same results between X_ITE and X3DOM. The spheres are much smaller now?<br>
>> >>>><br>
>> >>>> <a href="https://coderextreme.net/X3DJSONLD/src/main/html/proto2.html" rel="noreferrer" target="_blank">https://coderextreme.net/X3DJSONLD/src/main/html/proto2.html</a><br>
>> >>>><br>
>> >>>> Thanks for double checking!<br>
>> >>>><br>
>> >>>> Go ahead and close the x3dom issue 1044 issue once you check in your changes. I will probably refork my repo, since I overwrote my master.<br>
>> >>>><br>
>> >>>> John<br>
>> >>>><br>
>> >>>> On Mon, Jun 29, 2020 at 12:10 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >>>>><br>
>> >>>>> Here's the issue I was unable to solve in 36 hours of debugging, still related to protos.<br>
>> >>>>><br>
>> >>>>> <a href="https://github.com/x3dom/x3dom/issues/1044" rel="noreferrer" target="_blank">https://github.com/x3dom/x3dom/issues/1044</a><br>
>> >>>>><br>
>> >>>>> I should be able to provide a data file, t1.x3d, if necessary.<br>
>> >>>>><br>
>> >>>>> John<br>
>> >>>>><br>
>> >>>>> On Mon, Jun 29, 2020 at 11:11 AM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >>>>>><br>
>> >>>>>> How does one handle scripts inside a ProtoBody (multiple instances of the same script) is what next on our (or just my) plate.<br>
>> >>>>>><br>
>> >>>>>> On Mon, Jun 29, 2020 at 11:04 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> >>>>>>><br>
>> >>>>>>> Nothing is done to script elements. So the ones with a vrmlscript ( or<br>
>> >>>>>>> any non html standard ) mime type are ignored, and regular script<br>
>> >>>>>>> elements executed by the browser as dom scripts.<br>
>> >>>>>>><br>
>> >>>>>>> -Andreas<br>
>> >>>>>>><br>
>> >>>>>>> On Mon, Jun 29, 2020 at 11:57 AM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >>>>>>> ><br>
>> >>>>>>> > Yeah! Andreas! Once you clean up, I will attempt to add some kind of internal scripting to X3DOM. I’m curious though, what do you currently do with Protos with Scripts? Where does the script go?<br>
>> >>>>>>> ><br>
>> >>>>>>> > John<br>
>> >>>>>>> ><br>
>> >>>>>>> > On Mon, Jun 29, 2020 at 10:31 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> >>>>>>> >><br>
>> >>>>>>> >> After too many hours in the debugger, I added not too many lines to<br>
>> >>>>>>> >> better deal with changes to node value fields, in particular on how to<br>
>> >>>>>>> >> properly transfer these from the proto instance node to the underlying<br>
>> >>>>>>> >> native (or other proto) node.<br>
>> >>>>>>> >><br>
>> >>>>>>> >> rubikFurnace.x3d should work now, in parallel with the logo letter<br>
>> >>>>>>> >> example which was the main challenge.<br>
>> >>>>>>> >><br>
>> >>>>>>> >> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
>> >>>>>>> >> <a href="https://5efa06157960e80256fa5d6b--x3dom.netlify.app/" rel="noreferrer" target="_blank">https://5efa06157960e80256fa5d6b--x3dom.netlify.app/</a><br>
>> >>>>>>> >> <a href="https://5efa06157960e80256fa5d6b--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer" target="_blank">https://5efa06157960e80256fa5d6b--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
>> >>>>>>> >><br>
>> >>>>>>> >> I believe this concludes my substantive efforts. I will now focus on<br>
>> >>>>>>> >> separating out the proto code to a new file and some clean up.<br>
>> >>>>>>> >><br>
>> >>>>>>> >> Andreas<br>
>> >>>>>>> >><br>
>> >>>>>>> >><br>
>> >>>>>>> >> On Sun, Jun 28, 2020 at 6:40 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >>>>>>> >> ><br>
>> >>>>>>> >> > I got some more time to work on this, and the new X3DOM proto code does just as well with JSON as it does for XML. Congratulations!<br>
>> >>>>>>> >> ><br>
>> >>>>>>> >> > I think if Andreas fixes the outstanding rubik*'s errors (hopefully this will stop the BoxEm errors), and the t1.json/t1.x3d error in the x3dom issues, I believe we can declare this successful, and we can move onto "scripts"--whatever we're going to call the new script node, if not Script. If someone has a document on how X3DOM routes work (especially with namescopes), that will help me help with scripts.<br>
>> >>>>>>> >> ><br>
>> >>>>>>> >> > I'm not checking in my X3DJSONLD proto expander disabling code for now. For now, my copy will remain disabled for testing.<br>
>> >>>>>>> >> ><br>
>> >>>>>>> >> > There are errors to the X3DJSONLD console if someone wants me to copy and paste.<br>
>> >>>>>>> >> ><br>
>> >>>>>>> >> > If you want me to check in code for this into x3dom/andreasplesch's gh-pages branch, let me know. I only made change to the PrototypeExpander.js code, which effectively disabled the JSON proto expander, see below patch (patch to package.json unnecessary).<br>
>> >>>>>>> >> > diff --git a/package.json b/package.json<br>
>> >>>>>>> >> > index e1e0d501..7043f4f5 100644<br>
>> >>>>>>> >> > --- a/package.json<br>
>> >>>>>>> >> > +++ b/package.json<br>
>> >>>>>>> >> > @@ -10,7 +10,7 @@<br>
>> >>>>>>> >> > },<br>
>> >>>>>>> >> > "scripts": {<br>
>> >>>>>>> >> > "test": "echo \"Error: no test specified\" && exit 1",<br>
>> >>>>>>> >> > - "build": "node ./build/src-builder.js",<br>
>> >>>>>>> >> > + "build": "node --trace-warnings ./build/src-builder.js",<br>
>> >>>>>>> >> > "lint": "eslint \"src/**/*.js\"",<br>
>> >>>>>>> >> > "lint-fix": "eslint --fix \"src/**/*.js\""<br>
>> >>>>>>> >> > },<br>
>> >>>>>>> >> > diff --git a/src/util/json/PrototypeExpander.js b/src/util/json/PrototypeExpander.js<br>
>> >>>>>>> >> > index 9bf64e6a..fc1e87e0 100644<br>
>> >>>>>>> >> > --- a/src/util/json/PrototypeExpander.js<br>
>> >>>>>>> >> > +++ b/src/util/json/PrototypeExpander.js<br>
>> >>>>>>> >> > @@ -740,6 +740,8 @@ x3dom.PROTOS.prototype = {<br>
>> >>>>>>> >> ><br>
>> >>>>>>> >> > prototypeExpander : function ( file, object )<br>
>> >>>>>>> >> > {<br>
>> >>>>>>> >> > + // Use Andreas' proto code<br>
>> >>>>>>> >> > + /*<br>
>> >>>>>>> >> > this.protos = {};<br>
>> >>>>>>> >> > this.names = {};<br>
>> >>>>>>> >> > this.protoField = {};<br>
>> >>>>>>> >> > @@ -756,6 +758,7 @@ x3dom.PROTOS.prototype = {<br>
>> >>>>>>> >> > object = this.flattener( object );<br>
>> >>>>>>> >> > // console.error("SCRIPTS", JSON.stringify(this.scriptField));<br>
>> >>>>>>> >> > // console.error("PROTOS", JSON.stringify(this.protoField, null, 2));<br>
>> >>>>>>> >> > + */<br>
>> >>>>>>> >> > return object;<br>
>> >>>>>>> >> > },<br>
>> >>>>>>> >> ><br>
>> >>>>>>> >> ><br>
>> >>>>>>> >> > On Sun, Jun 28, 2020 at 2:38 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> I'm showing X_ITE sort of working, select rubikFurnace.json on the below linked page. Perhaps it's the conversion to/from JSON that makes it work? Or perhaps the JSON proto expander? Turning off the proto expander shows spheres for X_ITE/JSON, but green cubes for X_ITE XML/DOM. It appears that X_ITE/JSON/Protos/rubikFurnace needs some work which X3DJSONLD/proto expander magically fixes. I usually run with proto expansion enabled, so I wouldn't normally catch this error! Thanks for the bug report!<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> <a href="https://coderextreme.net/X3DJSONLD/src/main/html/index.html" rel="noreferrer" target="_blank">https://coderextreme.net/X3DJSONLD/src/main/html/index.html</a><br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> This uses your netlify version of x3dom.<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> Pasting XML into the above page with proto expansion on, only the X3DOM/XML/DOM version fails. Other versions show green cubes. Without the proto expansion, the previous example mentioned fails, but the JSON X_ITE version fails with white cubes. Loading XML with a local server shows no differences. I guess I could check the console next. Looks okay.<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> After working on t1.json for a while (see your x3dom issue related to proto expander), I noticed that my changes broke some of the rubik*'s examples. I was not successful at making both t1.json and rubik.json working. I don't know if that helps or not. Making the .x3d versions of these examples work may be tricky.<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> I am following your lead on renaming "sphere" to "sphereproto" in rubik.x3d<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> I will start testing with your netlify version:<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> Here is my proto check page with netlify (all examples seem to work, json proto expander on): <a href="http://coderextreme.net/X3DJSONLD/src/main/html/x3domproto.html" rel="noreferrer" target="_blank">http://coderextreme.net/X3DJSONLD/src/main/html/x3domproto.html</a> for JSON.<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> Here's the equivalent for XML Inlines (please try to get this page or similar working like the previous!) with netlify. <a href="https://coderextreme.net/X3DJSONLD/src/main/html/xmlproto.html" rel="noreferrer" target="_blank">https://coderextreme.net/X3DJSONLD/src/main/html/xmlproto.html</a><br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> The two files should be checked into github for your editing convenience.<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> The xmlproto.html is much better with a locally built x3dom (gh-pages branch) than the remote netlify version. You might want to update the netlify version?<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> Note the presence of a Script in the flowerproto. I'm not expecting that to work yet. It might be fun to get it working, though, which I have kind of done:<br>
>> >>>>>>> >> >> <a href="https://coderextreme.net/X3DJSONLD/src/main/html/proto.html" rel="noreferrer" target="_blank">https://coderextreme.net/X3DJSONLD/src/main/html/proto.html</a> (select ../data/x3domflowers.x3d).<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> If you've got a script instance per flower from your proto implementation, it might be possible. One just needs to rename "scripts"/implement the routes to and from "scripts" (whatever you want to call them), I am pretty sure. This becomes more and more doable, I am thinking now, thanks to your effort with Protos.<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> Don, can you add a check to the X3dToJson.xslt to throw a warning if a proto declare name is the same as a tag?<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> Thanks,<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> John<br>
>> >>>>>>> >> >><br>
>> >>>>>>> >> >> On Sun, Jun 28, 2020 at 12:28 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> >>>>>>> >> >>><br>
>> >>>>>>> >> >>> Thanks, very helpful. Two issues came up. Since 'sphere' is a name of<br>
>> >>>>>>> >> >>> a regular node, but then was registered as a new proto node, things<br>
>> >>>>>>> >> >>> broke. Not sure what to do about it, maybe just documenting. HTML has<br>
>> >>>>>>> >> >>> a requirement for names of custom nodes to avoid such conflicts. I<br>
>> >>>>>>> >> >>> renamed the proto to protosphere which fixed the scene. rubikOnFire<br>
>> >>>>>>> >> >>> was interesting because it is the only example which has an IS<br>
>> >>>>>>> >> >>> connection to a node field of a ProtoInstance. I found a workaround<br>
>> >>>>>>> >> >>> which should work most of the time. rubikFurnace does not work, it<br>
>> >>>>>>> >> >>> shows just the default spheres, not sure. x-ite has the same problem<br>
>> >>>>>>> >> >>> with it, so maybe there is a deeper issue although I think the x3d<br>
>> >>>>>>> >> >>> looks ok.<br>
>> >>>>>>> >> >>><br>
>> >>>>>>> >> >>> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
>> >>>>>>> >> >>><br>
>> >>>>>>> >> >>> PS: I started to use a chromebook and I think x-ite and x3dom are the<br>
>> >>>>>>> >> >>> only x3d browsers for this platform. I looks like freeWrl for android<br>
>> >>>>>>> >> >>> would need to be updated to work on it. I am getting used to the<br>
>> >>>>>>> >> >>> touchscreen,<br>
>> >>>>>>> >> >>><br>
>> >>>>>>> >> >>> On Sat, Jun 27, 2020 at 9:38 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> >>>>>>> >> >>> ><br>
>> >>>>>>> >> >>> > Here is an example to try:<br>
>> >>>>>>> >> >>> > <a href="https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/rubik.x3d" rel="noreferrer" target="_blank">https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/rubik.x3d</a><br>
>> >>>>>>> >> >>> ><br>
>> >>>>>>> >> >>> > Other rubik*.x3d examples in same folder may be useful too, but I can no longer remember all the differences. I know all shapes should be the same in the result, cylinder results are not correct and there are 27 shapes in the result.<br>
>> >>>>>>> >> >>> ><br>
>> >>>>>>> >> >>> > The result of the one in the email should be 27 spheres.<br>
>> >>>>>>> >> >>> ><br>
>> >>>>>>> >> >>> > John<br>
>> >>>>>>> >> >>> ><br>
>> >>>>>>> >> >>> > On Sat, Jun 27, 2020 at 6:23 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> I also start to think the main reason for the ExternProto fields is to<br>
>> >>>>>>> >> >>> >> enable easier and more performant loading by browsers, using a<br>
>> >>>>>>> >> >>> >> template and fill in the details later approach.<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> I expanded my working example list to a satisfactory number for x3dom<br>
>> >>>>>>> >> >>> >> and will start to clean up and refactor a bit. Almost each example<br>
>> >>>>>>> >> >>> >> needed additional attention to the processing so no doubt there are<br>
>> >>>>>>> >> >>> >> gaps in coverage which soon will be discovered by actual usage. But as<br>
>> >>>>>>> >> >>> >> long as the complexity in terms of nesting and async. loading does not<br>
>> >>>>>>> >> >>> >> exceed the examples, the behaviour should be fairly robust. The #name<br>
>> >>>>>>> >> >>> >> syntax works. The helicopter (Example16) is fairly complex and works<br>
>> >>>>>>> >> >>> >> now, after replacing the script with event utilities. The LogoLetter<br>
>> >>>>>>> >> >>> >> example unearthed another interesting bug which triggered exponential<br>
>> >>>>>>> >> >>> >> doubling of shapes. Some castle engine examples stress the limits,<br>
>> >>>>>>> >> >>> >> mostly by redefining DEFs (usually a no go) but do something<br>
>> >>>>>>> >> >>> >> reasonable now.<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> The approach taken is to register actual new node types (which<br>
>> >>>>>>> >> >>> >> internally use other nodes) and then use more or less the regular node<br>
>> >>>>>>> >> >>> >> creation and instancing for the ProtoInstances, after converting them<br>
>> >>>>>>> >> >>> >> to a more readable syntax. I think this works as well as expanding<br>
>> >>>>>>> >> >>> >> templates and feels more natural but tends to uncover implicit<br>
>> >>>>>>> >> >>> >> assumptions in the code. For example, x3dom assumes that Material as a<br>
>> >>>>>>> >> >>> >> X3DAppearanceChild node is always a child of an Appearance node. With<br>
>> >>>>>>> >> >>> >> protos, it can be a child of another node as well. So I had to<br>
>> >>>>>>> >> >>> >> eventually start to use a try/catch clause.<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> Thanks for maintaining the example, they are critical to get uniform behaviours.<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> Here are the updated working examples:<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> I may be interested in trying a few more examples without script nodes<br>
>> >>>>>>> >> >>> >> but I think these are a good selection.<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> Any feedback welcome,<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> -Andreas<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> On Fri, Jun 26, 2020 at 2:09 PM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > On 6/26/2020 10:50 AM, Andreas Plesch wrote:<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > Thanks for thinking this through. I am not seeing any inconsistencies,<br>
>> >>>>>>> >> >>> >> > > only redundancies which could invite authoring errors in the first<br>
>> >>>>>>> >> >>> >> > > place.<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > I think for now, x3dom will have to go by the garbage in, garbage out<br>
>> >>>>>>> >> >>> >> > > principle, meaning that inconsistent field statements may cause<br>
>> >>>>>>> >> >>> >> > > problems. The spec. actually requires consistent naming.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > agreed<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > > On Fri, Jun 26, 2020 at 10:06 AM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
>> >>>>>>> >> >>> >> > >><br>
>> >>>>>>> >> >>> >> > >> Checking ProtoDeclare and ExternProtoDeclare can be tricky, but I think it is correctly defined.<br>
>> >>>>>>> >> >>> >> > >><br>
>> >>>>>>> >> >>> >> > >> My understanding of the intent of that section was to prevent unexpected errors in the case of<br>
>> >>>>>>> >> >>> >> > >><br>
>> >>>>>>> >> >>> >> > >> a. ProtoDeclare defined,<br>
>> >>>>>>> >> >>> >> > >> b. ExternProtoDeclare and ProtoInstance example work and are deployed,<br>
>> >>>>>>> >> >>> >> > >> c. ProtoDeclare subsequently adds some additional fields or changes default field values,<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > How would that happen ? Externally, by editing the ProtoDeclare in the<br>
>> >>>>>>> >> >>> >> > > referenced file ? That would seem like a situation which should not be<br>
>> >>>>>>> >> >>> >> > > in the scope of x3d.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > correct. have seen this occur with long-term re-use of valuable prototypes that continue to evolve, it is important to find external instances or modify/evolve them with backwards compatibility in mind.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > >> d. ExternProtoDeclare and ProtoInstance example still work OK though new ProtoDeclare is retrieved at runtime.<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > Hm, is there a requirement to reload already loaded ProtoDeclare's<br>
>> >>>>>>> >> >>> >> > > when a new ProtoInstance is added to a scene ?<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > no, that would be dangerous/unexpected. no hidden dependencies here, just stepping through typical use.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > >> Certainly the browser loading the original/updated ProtoDeclare must honor the behavior defined therein, including default values.<br>
>> >>>>>>> >> >>> >> > >><br>
>> >>>>>>> >> >>> >> > >> If the field interfaces within the ExternProtoDeclare (which only contain name, type, accessType and not default values) are different, that would be an error.<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > yes, exactly, so why have those field interfaces ?<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > Having ExternProtoDeclare allows a browser to load and set up all connections with type information in mind, allowing remote loading of ProtoDeclare to occur in parallel. Thus performance speedup.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > >> As above, if default values within the ProtoDeclare change, this has no impact on ExternProtoDeclare field definitions because they do not list default values.<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > I am not sure how the default values could change.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > long-term evolution of a published prototype in a library, for example.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > >> When a ProtoInstance provides fieldValue initializations, they of course supersede whatever the default might be in the ProtoDeclare.<br>
>> >>>>>>> >> >>> >> > >><br>
>> >>>>>>> >> >>> >> > >> ... so I think this all hangs together cleanly without contradiction or ambiguity.<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > Agreed, just potentially confusing redundancy.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > it takes some practice to get familiar since the capabilities are powerful.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > >> Implementation-support notes:<br>
>> >>>>>>> >> >>> >> > >> - InstantReality handles cases well, although console warnings sometimes include false positives.<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > I am using view3dscene and freeWrl for testing. Most examples work<br>
>> >>>>>>> >> >>> >> > > well though freeWrl seems to have a problem with the nested spin group<br>
>> >>>>>>> >> >>> >> > > prototype example.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > As an author I avoid nested prototypes, they seem less robust and more likely to fail.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > >> - X3D-Edit has a feature to check ExternProtoDeclare interfaces against ProtoDeclare interfaces.<br>
>> >>>>>>> >> >>> >> > >> - Utility methods for such checking would be a good feature to add to our Java, Python and JavaScript libraries.<br>
>> >>>>>>> >> >>> >> > >><br>
>> >>>>>>> >> >>> >> > >> Loading and checking for such consistency is typically not performed by any of our Quality Assurance (QA) tools since they tend to perform validations in an offline manner. For X3DOM, I think this gap in testing coverage means that you should carefully check for consistency because if ProtoDeclare and ExternProtoDeclare differ then an incompatible interface is expected and model errors are likely.<br>
>> >>>>>>> >> >>> >> > >><br>
>> >>>>>>> >> >>> >> > >> Improvements always welcome. Thanks for close scrutiny and thanks for tackling this super valuable capability for X3DOM.<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > You can follow progress here:<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html#Front" rel="noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html#Front</a><br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > impressive setup<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > > It will be interesting to see how Protos can be used in combination<br>
>> >>>>>>> >> >>> >> > > with web js based templating.<br>
>> >>>>>>> >> >>> >> > ><br>
>> >>>>>>> >> >>> >> > > -Andreas<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > thanks for taking the time to get this part right now. that will make future HTML5-X3D4 patterns a lot more stable and understandable.<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > >> On 6/23/2020 6:10 PM, Andreas Plesch wrote:<br>
>> >>>>>>> >> >>> >> > >>> ...<br>
>> >>>>>>> >> >>> >> > >>>> The next step would be to support the ExternProtoDeclare statement.<br>
>> >>>>>>> >> >>> >> > >>>> The main question I have is about the function of the additional field<br>
>> >>>>>>> >> >>> >> > >>>> statements under ExternProtoDeclare.<br>
>> >>>>>>> >> >>> >> > >>>><br>
>> >>>>>>> >> >>> >> > >>>> - Do they replace ProtoInterface field statements ? (No.)<br>
>> >>>>>>> >> >>> >> > >>>> - Is the ProtoInterface element still required in the external file ? (Yes.)<br>
>> >>>>>>> >> >>> >> > >>>> - Are they listed just for convenience (for the author and the browser) ? (Yes?)<br>
>> >>>>>>> >> >>> >> > >>>> - Can they be ignored ? (Yes?)<br>
>> >>>>>>> >> >>> >> > >>><br>
>> >>>>>>> >> >>> >> > >>> I did find the clause "The names and types of the fields of the<br>
>> >>>>>>> >> >>> >> > >>> interface declaration shall be a subset of those defined in the<br>
>> >>>>>>> >> >>> >> > >>> implementation." in 4.4.5.2 EXTERNPROTO interface semantics. This<br>
>> >>>>>>> >> >>> >> > >>> means that an ExternProto can restrict access to fields by not listing<br>
>> >>>>>>> >> >>> >> > >>> them in its field elements. So they should not be ignored. On the<br>
>> >>>>>>> >> >>> >> > >>> other hand a browser which ignores them would still generate the same<br>
>> >>>>>>> >> >>> >> > >>> behaviour, minus warnings or errors in an ill-constructed scene when a<br>
>> >>>>>>> >> >>> >> > >>> ProtoInstance is trying to set non-accessible fields.<br>
>> >>>>>>> >> >>> >> > >>><br>
>> >>>>>>> >> >>> >> > >>> So I think as a first cut, it is ok to just load the external<br>
>> >>>>>>> >> >>> >> > >>> Protodeclaration and give it the name of the ExternProto and not doing<br>
>> >>>>>>> >> >>> >> > >>> much or anything with the field elements.<br>
>> >>>>>>> >> >>> >> > >>><br>
>> >>>>>>> >> >>> >> > >>>> Thanks for any insight,<br>
>> >>>>>>> >> >>> >> > >>>><br>
>> >>>>>>> >> >>> >> > >>>> -Andreas<br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> ><br>
>> >>>>>>> >> >>> >> > all the best, Don<br>
>> >>>>>>> >> >>> >> > --<br>
>> >>>>>>> >> >>> >> > Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
>> >>>>>>> >> >>> >> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
>> >>>>>>> >> >>> >> > X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> --<br>
>> >>>>>>> >> >>> >> Andreas Plesch<br>
>> >>>>>>> >> >>> >> Waltham, MA 02453<br>
>> >>>>>>> >> >>> >><br>
>> >>>>>>> >> >>> >> _______________________________________________<br>
>> >>>>>>> >> >>> >> x3d-public mailing list<br>
>> >>>>>>> >> >>> >> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>> >>>>>>> >> >>> >> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>> >>>>>>> >> >>><br>
>> >>>>>>> >> >>><br>
>> >>>>>>> >> >>><br>
>> >>>>>>> >> >>> --<br>
>> >>>>>>> >> >>> Andreas Plesch<br>
>> >>>>>>> >> >>> Waltham, MA 02453<br>
>> >>>>>>> >><br>
>> >>>>>>> >><br>
>> >>>>>>> >><br>
>> >>>>>>> >> --<br>
>> >>>>>>> >> Andreas Plesch<br>
>> >>>>>>> >> Waltham, MA 02453<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> --<br>
>> >>>>>>> Andreas Plesch<br>
>> >>>>>>> Waltham, MA 02453<br>
>><br>
>><br>
>><br>
>> --<br>
>> Andreas Plesch<br>
>> Waltham, MA 02453<br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>
</blockquote></div>