[x3d-public] ProtoBody completeness in nested Protos

[GPU Group]

https://www.instantreality.org/story/what-is-it/

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.html>