[x3d-public] duplicating scripts inside proto instances?

Tue Apr 26 14:03:23 PDT 2022

I am not sure if Andreas’ proto expander duplicates embedded scripts or
not.  It at least seems like state and routes to/from scripts should be
copied.  Opinions?  Should we meet?  Leonard made the point that scripts
should come before Protos.

John.

On Tue, Apr 26, 2022 at 3:25 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Thanks, I updated the wiki page.
>
> I took a look and found the issue in x3dom. For externprotos it will
> only process the first protodeclare as instructed in the spec, and
> ignore everything else including earlier externprotos for which a
> specific exception is made in the spec. Hopefully, I will find the
> strength to dive into this morass at some point later. It may suffice
> to specifically look for earlier, outside externprotos in externprotos
> since this seems to be a special case. Or it may be necessary to load
> the complete scene in an externproto. For example, it may be ok to DEF
> a node outside the ProtoDeclare used for an externproto and then USE
> it as a default value for a SFNode field in the default
> ProtoInterface. Hopefully, there is no use case for such things. This
> would require loading the complete scene.
>
> Cheers, Andreas
>
> > Date: Tue, 26 Apr 2022 11:34:39 -0600
> > From: GPU Group <gpugroup at gmail.com>
>
> > InstantPlayer was made at Fraunhaufer IDG. Here's how it renders:
> >
> http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_stack_push_and_pop_InstantPlayer.jpg
> >
> >
> >
> > On Tue, Apr 26, 2022 at 10:57 AM GPU Group <gpugroup at gmail.com> wrote:
> >
> > >
> > >
> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules
> > >
> > > "A prototype may be instantiated in a file anywhere after the
> completion
> > > of the prototype definition."
> > > If the specs meant what you are suggesting --protos are self contained
> > > including proto definitions-- then it would have said "context" rather
> than
> > > "file"
> > > "Prototype definitions appearing inside a prototype definition ( i.e.,
> > > nested) are local to the enclosing prototype. "
> > > - refinement of the above file order rule.
> > >
> > >
> > > On Tue, Apr 26, 2022 at 9:51 AM GPU Group <gpugroup at gmail.com> wrote:
> > >
> > >> "I really do
> > >> not think that proto declarations should be required to inherit
> > >> existing declarations from parent execution contexts"
> > >>
> > >> If C++ required each class definition to be self-contained --to
> redefine
> > >> all the types it depends on-- it would be a very messy and onerous
> system.
> > >> If you want a system that can build up types - types on top of types
> to
> > >> make more complex types - then you need a way for a type to use
> previously
> > >> defined types.
> > >> In x3d -a prototyping language- that looks like a new type being able
> to
> > >> use a type defined previously in the file. Extern ProtoDeclares are
> stored
> > >> in scene files as ProtoDeclares. As such they should be able to use
> type
> > >> defined previously in their host file.
> > >>
> > >>
> > >> On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <
> andreasplesch at gmail.com>
> > >> wrote:
> > >>
> > >>> > Date: Tue, 26 Apr 2022 07:56:47 -0600
> > >>> > From: GPU Group <gpugroup at gmail.com>
> > >>> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> > >>>
> > >>> > When I started with freewrl around 2009, it had a text-based
> system for
> > >>> > protos:
> > >>> > - when parsing a scene, if it found a proto declare, it would
> scrape
> > >>> the
> > >>> > text into a buffer. Then as it continued parsing, when it hit a
> proto
> > >>> > instance it pasted, and continued parsing over the pasted text as
> > >>> though it
> > >>> > had been there all along. Extern protos similar, it would pause
> > >>> parsing, go
> > >>> > to the file referenced, look for the proto declare by name, and
> scrape
> > >>> out
> > >>> > the text of the ProtoDeclare, for pasting in-scene.
> > >>> > And it worked a bit. But especially extern protos weren't working
> > >>> reliably.
> > >>> > As a casual volunteer I decided to fix the bugs. How hard could it
> be?
> > >>> A
> > >>> > little debugging and presto, I'd be a hero. As I got into it and
> saw
> > >>> more
> > >>> > scene failure examples there were several emotional stages like
> > >>> grieving
> > >>> > denial, shock, sadness, resistance etc. And a slow dawning
> realization
> > >>> the
> > >>> > whole system needed a rework.
> > >>> > And I didn't have support from others -just silence, perhaps they
> knew
> > >>> it
> > >>> > was a mess and wanted to stay clear.
> > >>> > It was a sickening feeling, and I needed to think for a few weeks
> > >>> whether I
> > >>> > even wanted to be a volunteer programmer if the system was rotten
> from
> > >>> the
> > >>> > core.
> > >>> > So it can not only be a monster task, but precisely because it's a
> > >>> monster
> > >>> > there's little support for those brave enough to tackle it.
> > >>> > (After a few weeks I got to the Acceptance stage of grieving, and
> > >>> spent 6
> > >>> > months of hobby time building the new proto system).
> > >>>
> > >>> Thanks for the story, and for engaging. To me, I became interested
> > >>> when I realized that x3dom is probably flexible enough to allow for
> > >>> parameterized definition and registration of new nodes dynamically
> > >>> which behave then exactly like native nodes. This is different from
> > >>> filling in templates. For example, there is no performance penalty
> > >>> during tree traversal and it enables instancing using xml nodes with
> > >>> the new names, just as in x3dv.
> > >>>
> > >>> I am pretty happy with how it came out. An additional complication is
> > >>> asynchronous loading of remote resources which is standard on the
> web.
> > >>> X3D should rely less on how nodes or statements are ordered in a
> > >>> scene.
> > >>>
> > >>> It is just frustrating that there are ill defined corners. I really
> do
> > >>> not think that proto declarations should be required to inherit
> > >>> existing declarations from parent execution contexts ( DEF/USE name
> > >>> scopes are different but there is still a separated execution context
> > >>> ). That means the protos array of a new execution context should be
> > >>> empty initially. The SAI spec. actually says so.
> > >>>
> > >>> Best, Andreas
> > >>>
> > >>> _______________________________________________
> > >>> 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/20220426/ad3376aa/attachment-0001.html
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 26 Apr 2022 14:37:25 -0400
> > From: Andreas Plesch <andreasplesch at gmail.com>
> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> > Subject: Re: [x3d-public] ProtoBody completeness in nested Protos
> > Message-ID:
> >         <
> CAKdk67t-xRu+PkL4nRAM9NOn8DrMznORyhwYaeG4fweBYgFwvw at mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > > Date: Tue, 26 Apr 2022 10:57:10 -0600
> > > From: GPU Group <gpugroup at gmail.com>
> > >
> > >
> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules
> > >
> > > "A prototype may be instantiated in a file anywhere after the
> completion of
> > > the prototype definition."
> > > If the specs meant what you are suggesting --protos are self contained
> > > including proto definitions-- then it would have said "context" rather
> than
> > > "file"
> > > "Prototype definitions appearing inside a prototype definition ( i.e.,
> > > nested) are local to the enclosing prototype. "
> > > - refinement of the above file order rule.
> >
> > Ok. thanks ! There it is. Time to look into this, then.
> >
> > -Andreas
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
> > ------------------------------
> >
> > End of x3d-public Digest, Vol 157, Issue 107
> > ********************************************
>
>
>
> --
> 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/20220426/fae590b8/attachment-0001.html>