[x3d-public] x3d-public Digest, Vol 157, Issue 107

Tue Apr 26 13:24:10 PDT 2022

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