[x3d-public] x3dom prototypes, extern proto
John Carlson
yottzumm at gmail.com
Sun Jun 28 17:15:43 PDT 2020
Oops, last patch was unnecessary.
Sorry about that.
On Sun, Jun 28, 2020 at 7:14 PM John Carlson <yottzumm at gmail.com> wrote:
> I remembered one more place to patch in X3DOM:
>
> diff --git a/src/Runtime.js b/src/Runtime.js
> index e7e2d5e2..2ca1c756 100755
> --- a/src/Runtime.js
> +++ b/src/Runtime.js
> @@ -1610,7 +1610,9 @@ x3dom.Runtime.prototype.createX3DFromJS = function (
> jsobject, optionalURL )
> {
> if ( optionalURL )
> {
> + /* Waiting for Andreas' proto code to delete this code. TODO
> jsobject = x3dom.protoExpander.prototypeExpander( optionalURL,
> jsobject );
> + */
> }
> var jsonParser = new x3dom.JSONParser();
> return jsonParser.parseJavaScript( jsobject );
>
> On Sun, Jun 28, 2020 at 5:40 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> 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!
>>
>> 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.
>>
>> I'm not checking in my X3DJSONLD proto expander disabling code for now.
>> For now, my copy will remain disabled for testing.
>>
>> There are errors to the X3DJSONLD console if someone wants me to copy and
>> paste.
>>
>> 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).
>> diff --git a/package.json b/package.json
>> index e1e0d501..7043f4f5 100644
>> --- a/package.json
>> +++ b/package.json
>> @@ -10,7 +10,7 @@
>> },
>> "scripts": {
>> "test": "echo \"Error: no test specified\" && exit 1",
>> - "build": "node ./build/src-builder.js",
>> + "build": "node --trace-warnings ./build/src-builder.js",
>> "lint": "eslint \"src/**/*.js\"",
>> "lint-fix": "eslint --fix \"src/**/*.js\""
>> },
>> diff --git a/src/util/json/PrototypeExpander.js
>> b/src/util/json/PrototypeExpander.js
>> index 9bf64e6a..fc1e87e0 100644
>> --- a/src/util/json/PrototypeExpander.js
>> +++ b/src/util/json/PrototypeExpander.js
>> @@ -740,6 +740,8 @@ x3dom.PROTOS.prototype = {
>>
>> prototypeExpander : function ( file, object )
>> {
>> + // Use Andreas' proto code
>> + /*
>> this.protos = {};
>> this.names = {};
>> this.protoField = {};
>> @@ -756,6 +758,7 @@ x3dom.PROTOS.prototype = {
>> object = this.flattener( object );
>> // console.error("SCRIPTS", JSON.stringify(this.scriptField));
>> // console.error("PROTOS", JSON.stringify(this.protoField, null,
>> 2));
>> + */
>> return object;
>> },
>>
>>
>> On Sun, Jun 28, 2020 at 2:38 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> 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!
>>>
>>> https://coderextreme.net/X3DJSONLD/src/main/html/index.html
>>>
>>> This uses your netlify version of x3dom.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> I am following your lead on renaming "sphere" to "sphereproto" in
>>> rubik.x3d
>>>
>>> I will start testing with your netlify version:
>>>
>>> Here is my proto check page with netlify (all examples seem to
>>> work, json proto expander on):
>>> http://coderextreme.net/X3DJSONLD/src/main/html/x3domproto.html for
>>> JSON.
>>>
>>> Here's the equivalent for XML Inlines (please try to get this page or
>>> similar working like the previous!) with netlify.
>>> https://coderextreme.net/X3DJSONLD/src/main/html/xmlproto.html
>>>
>>> The two files should be checked into github for your editing convenience.
>>>
>>> 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?
>>>
>>> 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:
>>> https://coderextreme.net/X3DJSONLD/src/main/html/proto.html (select
>>> ../data/x3domflowers.x3d).
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> On Sun, Jun 28, 2020 at 12:28 AM Andreas Plesch <andreasplesch at gmail.com>
>>> wrote:
>>>
>>>> Thanks, very helpful. Two issues came up. Since 'sphere' is a name of
>>>> a regular node, but then was registered as a new proto node, things
>>>> broke. Not sure what to do about it, maybe just documenting. HTML has
>>>> a requirement for names of custom nodes to avoid such conflicts. I
>>>> renamed the proto to protosphere which fixed the scene. rubikOnFire
>>>> was interesting because it is the only example which has an IS
>>>> connection to a node field of a ProtoInstance. I found a workaround
>>>> which should work most of the time. rubikFurnace does not work, it
>>>> shows just the default spheres, not sure. x-ite has the same problem
>>>> with it, so maybe there is a deeper issue although I think the x3d
>>>> looks ok.
>>>>
>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>>>
>>>> PS: I started to use a chromebook and I think x-ite and x3dom are the
>>>> only x3d browsers for this platform. I looks like freeWrl for android
>>>> would need to be updated to work on it. I am getting used to the
>>>> touchscreen,
>>>>
>>>> On Sat, Jun 27, 2020 at 9:38 PM John Carlson <yottzumm at gmail.com>
>>>> wrote:
>>>> >
>>>> > Here is an example to try:
>>>> >
>>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/rubik.x3d
>>>> >
>>>> > 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.
>>>> >
>>>> > The result of the one in the email should be 27 spheres.
>>>> >
>>>> > John
>>>> >
>>>> > On Sat, Jun 27, 2020 at 6:23 PM Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>> >>
>>>> >> I also start to think the main reason for the ExternProto fields is
>>>> to
>>>> >> enable easier and more performant loading by browsers, using a
>>>> >> template and fill in the details later approach.
>>>> >>
>>>> >> I expanded my working example list to a satisfactory number for x3dom
>>>> >> and will start to clean up and refactor a bit. Almost each example
>>>> >> needed additional attention to the processing so no doubt there are
>>>> >> gaps in coverage which soon will be discovered by actual usage. But
>>>> as
>>>> >> long as the complexity in terms of nesting and async. loading does
>>>> not
>>>> >> exceed the examples, the behaviour should be fairly robust. The
>>>> #name
>>>> >> syntax works. The helicopter (Example16) is fairly complex and works
>>>> >> now, after replacing the script with event utilities. The LogoLetter
>>>> >> example unearthed another interesting bug which triggered exponential
>>>> >> doubling of shapes. Some castle engine examples stress the limits,
>>>> >> mostly by redefining DEFs (usually a no go) but do something
>>>> >> reasonable now.
>>>> >>
>>>> >> The approach taken is to register actual new node types (which
>>>> >> internally use other nodes) and then use more or less the regular
>>>> node
>>>> >> creation and instancing for the ProtoInstances, after converting them
>>>> >> to a more readable syntax. I think this works as well as expanding
>>>> >> templates and feels more natural but tends to uncover implicit
>>>> >> assumptions in the code. For example, x3dom assumes that Material as
>>>> a
>>>> >> X3DAppearanceChild node is always a child of an Appearance node. With
>>>> >> protos, it can be a child of another node as well. So I had to
>>>> >> eventually start to use a try/catch clause.
>>>> >>
>>>> >> Thanks for maintaining the example, they are critical to get uniform
>>>> behaviours.
>>>> >>
>>>> >> Here are the updated working examples:
>>>> >>
>>>> >>
>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>>>> >>
>>>> >> I may be interested in trying a few more examples without script
>>>> nodes
>>>> >> but I think these are a good selection.
>>>> >>
>>>> >> Any feedback welcome,
>>>> >>
>>>> >> -Andreas
>>>> >>
>>>> >> On Fri, Jun 26, 2020 at 2:09 PM Don Brutzman <brutzman at nps.edu>
>>>> wrote:
>>>> >> >
>>>> >> > On 6/26/2020 10:50 AM, Andreas Plesch wrote:
>>>> >> > >
>>>> >> > > Thanks for thinking this through. I am not seeing any
>>>> inconsistencies,
>>>> >> > > only redundancies which could invite authoring errors in the
>>>> first
>>>> >> > > place.
>>>> >> > >
>>>> >> > > I think for now, x3dom will have to go by the garbage in,
>>>> garbage out
>>>> >> > > principle, meaning that inconsistent field statements may cause
>>>> >> > > problems. The spec. actually requires consistent naming.
>>>> >> >
>>>> >> > agreed
>>>> >> >
>>>> >> > > On Fri, Jun 26, 2020 at 10:06 AM Don Brutzman <brutzman at nps.edu>
>>>> wrote:
>>>> >> > >>
>>>> >> > >> Checking ProtoDeclare and ExternProtoDeclare can be tricky, but
>>>> I think it is correctly defined.
>>>> >> > >>
>>>> >> > >> My understanding of the intent of that section was to prevent
>>>> unexpected errors in the case of
>>>> >> > >>
>>>> >> > >> a. ProtoDeclare defined,
>>>> >> > >> b. ExternProtoDeclare and ProtoInstance example work and are
>>>> deployed,
>>>> >> > >> c. ProtoDeclare subsequently adds some additional fields or
>>>> changes default field values,
>>>> >> > >
>>>> >> > > How would that happen ? Externally, by editing the ProtoDeclare
>>>> in the
>>>> >> > > referenced file ? That would seem like a situation which should
>>>> not be
>>>> >> > > in the scope of x3d.
>>>> >> >
>>>> >> > 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.
>>>> >> >
>>>> >> > >> d. ExternProtoDeclare and ProtoInstance example still work OK
>>>> though new ProtoDeclare is retrieved at runtime.
>>>> >> > >
>>>> >> > > Hm, is there a requirement to reload already loaded
>>>> ProtoDeclare's
>>>> >> > > when a new ProtoInstance is added to a scene ?
>>>> >> >
>>>> >> > no, that would be dangerous/unexpected. no hidden dependencies
>>>> here, just stepping through typical use.
>>>> >> >
>>>> >> > >> Certainly the browser loading the original/updated ProtoDeclare
>>>> must honor the behavior defined therein, including default values.
>>>> >> > >>
>>>> >> > >> If the field interfaces within the ExternProtoDeclare (which
>>>> only contain name, type, accessType and not default values) are different,
>>>> that would be an error.
>>>> >> > >
>>>> >> > > yes, exactly, so why have those field interfaces ?
>>>> >> >
>>>> >> > 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.
>>>> >> >
>>>> >> > >> As above, if default values within the ProtoDeclare change,
>>>> this has no impact on ExternProtoDeclare field definitions because they do
>>>> not list default values.
>>>> >> > >
>>>> >> > > I am not sure how the default values could change.
>>>> >> >
>>>> >> > long-term evolution of a published prototype in a library, for
>>>> example.
>>>> >> >
>>>> >> > >> When a ProtoInstance provides fieldValue initializations, they
>>>> of course supersede whatever the default might be in the ProtoDeclare.
>>>> >> > >>
>>>> >> > >> ... so I think this all hangs together cleanly without
>>>> contradiction or ambiguity.
>>>> >> > >
>>>> >> > > Agreed, just potentially confusing redundancy.
>>>> >> >
>>>> >> > it takes some practice to get familiar since the capabilities are
>>>> powerful.
>>>> >> >
>>>> >> > >> Implementation-support notes:
>>>> >> > >> - InstantReality handles cases well, although console warnings
>>>> sometimes include false positives.
>>>> >> > >
>>>> >> > > I am using view3dscene and freeWrl for testing. Most examples
>>>> work
>>>> >> > > well though freeWrl seems to have a problem with the nested spin
>>>> group
>>>> >> > > prototype example.
>>>> >> >
>>>> >> > As an author I avoid nested prototypes, they seem less robust and
>>>> more likely to fail.
>>>> >> >
>>>> >> > >> - X3D-Edit has a feature to check ExternProtoDeclare interfaces
>>>> against ProtoDeclare interfaces.
>>>> >> > >> - Utility methods for such checking would be a good feature to
>>>> add to our Java, Python and JavaScript libraries.
>>>> >> > >>
>>>> >> > >> 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.
>>>> >> > >>
>>>> >> > >> Improvements always welcome. Thanks for close scrutiny and
>>>> thanks for tackling this super valuable capability for X3DOM.
>>>> >> > >
>>>> >> > > You can follow progress here:
>>>> >> > >
>>>> >> > >
>>>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html#Front
>>>> >> >
>>>> >> > impressive setup
>>>> >> >
>>>> >> > > It will be interesting to see how Protos can be used in
>>>> combination
>>>> >> > > with web js based templating.
>>>> >> > >
>>>> >> > > -Andreas
>>>> >> >
>>>> >> > thanks for taking the time to get this part right now. that will
>>>> make future HTML5-X3D4 patterns a lot more stable and understandable.
>>>> >> >
>>>> >> > >> On 6/23/2020 6:10 PM, Andreas Plesch wrote:
>>>> >> > >>> ...
>>>> >> > >>>> The next step would be to support the ExternProtoDeclare
>>>> statement.
>>>> >> > >>>> The main question I have is about the function of the
>>>> additional field
>>>> >> > >>>> statements under ExternProtoDeclare.
>>>> >> > >>>>
>>>> >> > >>>> - Do they replace ProtoInterface field statements ? (No.)
>>>> >> > >>>> - Is the ProtoInterface element still required in the
>>>> external file ? (Yes.)
>>>> >> > >>>> - Are they listed just for convenience (for the author and
>>>> the browser) ? (Yes?)
>>>> >> > >>>> - Can they be ignored ? (Yes?)
>>>> >> > >>>
>>>> >> > >>> I did find the clause "The names and types of the fields of the
>>>> >> > >>> interface declaration shall be a subset of those defined in the
>>>> >> > >>> implementation." in 4.4.5.2 EXTERNPROTO interface semantics.
>>>> This
>>>> >> > >>> means that an ExternProto can restrict access to fields by not
>>>> listing
>>>> >> > >>> them in its field elements. So they should not be ignored. On
>>>> the
>>>> >> > >>> other hand a browser which ignores them would still generate
>>>> the same
>>>> >> > >>> behaviour, minus warnings or errors in an ill-constructed
>>>> scene when a
>>>> >> > >>> ProtoInstance is trying to set non-accessible fields.
>>>> >> > >>>
>>>> >> > >>> So I think as a first cut, it is ok to just load the external
>>>> >> > >>> Protodeclaration and give it the name of the ExternProto and
>>>> not doing
>>>> >> > >>> much or anything with the field elements.
>>>> >> > >>>
>>>> >> > >>>> Thanks for any insight,
>>>> >> > >>>>
>>>> >> > >>>> -Andreas
>>>> >> >
>>>> >> >
>>>> >> > all the best, Don
>>>> >> > --
>>>> >> > Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>> >> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> +1.831.656.2149
>>>> >> > X3D graphics, virtual worlds, navy robotics
>>>> http://faculty.nps.edu/brutzman
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Andreas Plesch
>>>> >> Waltham, MA 02453
>>>> >>
>>>> >> _______________________________________________
>>>> >> x3d-public mailing list
>>>> >> x3d-public at web3d.org
>>>> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>
>>>>
>>>>
>>>> --
>>>> Andreas Plesch
>>>> Waltham, MA 02453
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200628/c4b81fda/attachment-0001.html>
More information about the x3d-public
mailing list