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