[x3d-public] duplicating scripts inside proto instances?

Tue Apr 26 16:20:04 PDT 2022

I’m speaking of ProtoInstances including Script nodes with to and/or from
fields to routes, etc.   I am fully aware of fan-in fan-out, but assume you
are handling random transforms of an animated shapes inside the
ProtoInstances.  With one script state, I don’t know how to get several
different random shapes with protoinstances.

If the same fields can be used across Scripts. Ok.  Otherwise we need
something like fieldValue’s in ProtoInstances to maintain state.  Maybe
duplicated ROUTEs can maintain state?

Thanks for your efforts.  I guess I’m limited to being a fan at this
juncture.  I hope my health improves.  Maybe over time, with practice I can
regain coding and debugging skill.  I used to build hierarchies from
relational databases like eating lunch, along with mark and sweep.

We do need a good design for this.  I have one design, but it requires the
proto expander to “duplicate” Scripts with fields and rewire routes.

With enough effort we can look at other examples.

I don’t really want my working code to break!

Thanks

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

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