[x3d-public] duplicating scripts inside proto instances?

Tue Apr 26 15:16:01 PDT 2022

Thanks. Scripts are currently not a target. Better protos may be. My
proto expander is not based on xml or text expanding or substitutions.
It uses the parsed (binary, in-memory) ProtoBody as a template for a
new node which then can be instanced and populated with field values.
So any node including a script node would need to work first outside
of a proto in a regular scene. Once it does, it should just work in a
proto as well.

Andreas

On Tue, Apr 26, 2022 at 5:03 PM John Carlson <yottzumm at gmail.com> wrote:
>
> 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

-- 
Andreas Plesch
Waltham, MA 02453