[x3d-public] x3dom prototypes, extern proto

Sat Jun 27 18:38:39 PDT 2020

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200627/fbc6be25/attachment.html>