[x3d-public] ProtoBody completeness in nested Protos

Tue Apr 26 09:58:17 PDT 2022

Oh, probably not.  I thought you were talking about externprotos.   I
stumbled in extern PROTOs for some time.

John

On Tue, Apr 26, 2022 at 11:54 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> On Tue, Apr 26, 2022 at 12:38 PM John Carlson <yottzumm at gmail.com> wrote:
> >
> > ArtDeco examples, irc.
>
> I do not think they do this, eg. use ProtoInstance inside Protos. Do they ?
>
> Andreas
>
> >
> > On Tue, Apr 26, 2022 at 11:13 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >>
> >> Hi Don,
> >>
> >> Thanks for chiming in.
> >>
> >> On Tue, Apr 26, 2022 at 11:44 AM Brutzman, Donald (Don) (CIV)
> >> <brutzman at nps.edu> wrote:
> >>
> >> > Wanted to point out that embedding ExternProtoDeclare within
> ProtoDeclare only impacts scoping (visibility) of the ExternProto.
> >> >
> >> >
> >> >
> >> > Common design pattern for large scenes is to put all
> ExternProtoDeclare statements at top of model, so that ProtoInstances might
> be used anywhere.  Also avoids repeated loading of such prototypes.
> >> >
> >>
> >> Do you have more examples of such a design, eg. putting
> >> ExternProtoDeclare at the top, and then using ProtoInstances inside
> >> other ProtoDeclare ProtoBodys ? The CircleFishLod proto is the only
> >> example I could find sofar.
> >>
> >> Such design may not function very reliably due to the separated
> >> Execution Contexts inside Protos as discussed. In fact, the spec.
> >> would discourage such a design as far as I understand it unless
> >> Execution Contexts are meant to be inherited down from parents/hosts
> >> (which may lead to DEF/USE name conflicts).
> >>
> >> > Alternatively for reliability an author might put ExternProtoDeclare
> within ProtoDeclare so that it is always available.  If embedded, that
> ExternProtoDeclare will not be visible outside of the ProtoDeclare.  This
> might be preferable or undesirable, depending on modeler’s re-use plans (or
> possibly ProtoDeclare author’s design intentions).
> >> >
> >> > Of note is that ProtoBody content model does allow inclusion of
> ExternProtoDeclare as valid.  See bottom of following diagram to confirm.
> >> >
> >>
> >> Yes. I could not think of a reason why it should not be allowed.
> >>
> >> All the best, Andreas
> >>
> >> > From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of GPU
> Group
> >> > Sent: Monday, April 25, 2022 6:09 AM
> >> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> >> > Subject: Re: [x3d-public] ProtoBody completeness in nested Protos
> >> >
> >> >
> >> >
> >> > freewrl loads extern proto scenes as whole scene files, but as 'dead'
> scenery like a library file: in binary form, ready to binary deep copy
> parts to live scenery, but node initialization functions not yet called,
> and not rendered. Subsequent # references to the same scene file use the
> same loaded library scene. So any ProtoDeclares outside the ProtoBody would
> be resolved.
> >> >
> >> > -Doug
> >> >
> >> > PS this relates to:
> >> >
> >> > PROTOTYPE STYLE IMPORTS
> >> >
> >> > I had mentioned a prototype style import for gltf use:
> >> >
> >> > Shape { url=”library.gltf#shapeName” }
> >> >
> >> > Similar to how we load extern protos as a whole ‘dead’ scene, and
> then do binary deep copies where used in the live scene to make live.
> >> >
> >> > But interestingly, the same goes for x3d scenery – don’t need glTF,
> don’t need extern protos in library scene, don’t need Inline or IMPORT.
> >> >
> >> > So the concept could be tested first with x3d scenery.
> >> >
> >> > Shape { url=’library.x3dv#shapeName }
> >> >
> >> > And then extended to gltf.
> >> >
> >> > /PROTOTYPE STYLE IMPORTS
> >> >
> >> >
> >> >
> >> > On Sun, Apr 24, 2022 at 10:43 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
> >> >
> >> > Actually please look a little more closely at that (admittedly tricky)
> >> > example.
> >> >
> >> > * CircleFish is an ExternProto, separately defined in another file
> >> > * CircleFishLod is a ProtoDeclare defined in that first file,
> >> > CircleFishLodPrototype.x3d
> >> > * CircleFishLod ProtoBody contains two ProtoInstance copies of
> CircleFish
> >> > * CircleFishLod ProtoDeclare is then followed by a CircleFishLod
> >> > ProtoInstance (again  in CircleFishLodPrototype.x3d)
> >> >
> >> > So I would expect an X3D Browser to
> >> >
> >> > a. load ExternProtoDeclare      CircleFish
> >> > b. build ProtoDeclare                CircleFishLod
> >> > c. create inner ProtoInstance  CircleFish for use
> >> > d. create outer ProtoInstance CircleFishLod
> >> >
> >> > Order of steps might vary a bit, but those are the dependencies.
> Good luck
> >> > sir.
> >> >
> >> > 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 https://
> >> > faculty.nps.edu/brutzman
> >> >
> >> > -----Original Message-----
> >> > From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Andreas
> Plesch
> >> > Sent: Sunday, April 24, 2022 9:08 PM
> >> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> >> > Subject: [x3d-public] ProtoBody completeness in nested Protos
> >> >
> >> > ProtoDeclarations may use ProtoInstances of other Protos inside their
> >> > ProtoBody definitions.
> >> >
> >> > For example, the CircleFishLod proto here:
> >> >
> >> >
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphic
> >> > s.com
> %2Fexamples%2FX3dForWebAuthors%2FKelpForestExhibit%2FCircleFishLodProto
> >> > typeIndex.html&data=05%7C01%7Cbrutzman%40nps.edu
> %7C0b4a867ba9874e371f9b0
> >> >
> 8da267152fa%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637864565880708349%
> >> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> >> >
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=upr4eckI8axT7MO5fAUvAWfyBzUJfhTwqcp
> >> > BuH7tZjc%3D&reserved=0
> >> >
> >> > uses ProtoInstances of the CircleFish proto.
> >> >
> >> > A more extreme case of nesting is:
> >> >
> >> >
> https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PRO
> >> > TO/fivedeepnestingIndex.html
> >> >
> >> > where Proto1 uses ProtoInstance of Proto2 inside its ProtoBody. Proto2
> >> > itself uses a ProtoInstance of Proto3 inside its ProtoBody. And so on
> to
> >> > five levels deep.
> >> >
> >> > The second example with the deep nesting currently works with x3dom
> but the
> >> > seemingly simpler CircleFishLod proto does not.
> >> >
> >> > The reason is that x3dom expects the complete definition of a proto
> to be
> >> > contained in its ProtoBody. However, The CircleFishLod proto only
> contains
> >> > the CircleFish ProtoInstances in the body but not the associated
> CircleFish
> >> > ProtoDeclaration which for some reason occurs outside the
> CircleFishLod
> >> > ProtoBody (and outside the CircleFishLod ProtoDeclaration).
> >> >
> >> > Expecting the ProtoBody to be complete and self-contained seems rather
> >> > natural. Is x3dom too strict in this regard, or is there an oversight
> in the
> >> > example ? There is not much guidance in the spec., if any.
> >> >
> >> > Thanks, Andreas
> >> >
> >> > --
> >> > Andreas Plesch
> >> > Waltham, MA 02453
> >> >
> >> > _______________________________________________
> >> > 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
> >>
> >>
> >>
> >> --
> >> 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/20220426/23d0a244/attachment-0001.html>