<div dir="ltr"><div dir="auto"><div>Here is what I understand how Castle and x-ite instance protos.</div><div><br></div><div>Castle extracts the first node of the protobody and stores the other nodes in a special helper which is considered during traversal. So sibling nodes live in the special helper. ISing is accomplished by adding internal routes from the ProtoInstanceNode with its custom fields to the nodes in the instanced ProtoBody.</div><div><br></div><div>x-ite puts the ProtoDeclaration in a separate ExecutionContext which is more like a Scene. A ProtoInstance just puts the Proto into the upper ExectionContext of the ProtoInstance. So both the main node and sibling nodes live in the separate ExecutionContext. This is more like Inline. The ProtoInstance is given explicitly the node type of the first node. ISing is done by giving fields of nodes the ability to reference fields of other nodes, in general. So a connection is translated to adding such references, one-way or two-way depending on access type. This is a bit like adding internal routes.</div><div><br></div><div>Corrections and feedback very much welcome. Food for thought.</div><div><br></div><div>-Andreas</div><div><br><div data-smartmail="gmail_signature">---on the phone---</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020, 8:16 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">What I did was register locations (fields) in scope, and then set the value of the registered location later, for protos, scripts and “environment.” Then I “ran” the script-route events in a loop I created in my Script.js file. X3DOM should run the other routes.</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><br></div><div dir="auto"><br></div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 6:47 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">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)">I think the idea would be to use a Switch node as a wrapper around the<br>
ProtoBody nodes. Sounds like an idea but Switch nodes only take<br>
X3DChildNodes, so no Material nodes, for example. But perhaps there<br>
was another thought.<br>
<br>
I am trying to read through castle-engine and x-ite solutions but I am<br>
not quite making sense of those. castle has some good and a bit scary<br>
comments abouts ISing.<br>
<br>
-Andreas<br>
<br>
On Fri, May 29, 2020 at 7:36 PM John Carlson <<a href="mailto:yottzumm@gmail.com" rel="noreferrer" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
><br>
> Don suggested a Switch node at one point (thanks Don).<br>
><br>
> On Fri, May 29, 2020 at 1:28 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> Internal namescopes and better parsing made nested ProtoDeclares<br>
>> inside ProtoBody and internal ROUTEs work:<br>
>><br>
>> <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
>> <a href="https://5ed144877a8ae8000756ddd1--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer noreferrer" target="_blank">https://5ed144877a8ae8000756ddd1--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
>><br>
>> I am still not sure how to think about multiple nodes in a ProtoBody<br>
>> template since these are not scenes. Many examples seem to have only<br>
>> one node, and only routes outside of it.<br>
>><br>
>> Conceptually, it is pretty clear that the first node is THE node, and<br>
>> other nodes do not render but are active and can be connected.<br>
>><br>
>> Let's look at the Material Modulator example:<br>
>> <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorIndex.html" rel="noreferrer noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorIndex.html</a><br>
>><br>
>> The main node is the Material node but then there are Script and<br>
>> TimeSensor siblings, and routes.<br>
>><br>
>> So the instance will be of Material node kind, an<br>
>> X3DAppearanceChildNode. This allows the instance to be accepted as a<br>
>> value of the Material field in an Appearance node.<br>
>><br>
>> But the Script and TimeSensor sibling instances will not be able to<br>
>> continue to live as siblings next to the instanced Material node since<br>
>> they are not X3DAppearanceChildNodes. They will need to live somewhere<br>
>> else but still be able to control the instanced Material node.<br>
>><br>
>> So a straight transfer of a one to one instance to the scene seems out<br>
>> of the question.<br>
>><br>
>> I kind of hope I am missing something ? Is there another way to think<br>
>> about Protoinstances ?<br>
>><br>
>> Probably time to look at other code for inspiration.<br>
>><br>
>> -Andreas<br>
>><br>
>> On Fri, May 29, 2020 at 8:39 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> ><br>
>> > I added a few more Proto test examples to<br>
>> ><br>
>> > <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
>> ><br>
>> > and<br>
>> ><br>
>> > <a href="https://5ed100c873166e0006438ab0--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer noreferrer" target="_blank">https://5ed100c873166e0006438ab0--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
>> ><br>
>> > That includes a NIST example which uses internal routing and one which<br>
>> > has ProtoDeclare inside ProtoBody, nested five deep. These are good<br>
>> > targets to get to work before thinking about fields and interface.<br>
>> ><br>
>> > <a href="https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO/index.html" rel="noreferrer noreferrer" target="_blank">https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO/index.html</a><br>
>> ><br>
>> > -Andreas<br>
>> ><br>
>> > On Thu, May 28, 2020 at 8:35 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> > ><br>
>> > > It turns out that github pages does not like serving all the little js<br>
>> > > files making up x3dom separately.<br>
>> > ><br>
>> > > Here is a complete build with the example:<br>
>> > ><br>
>> > > <a href="https://5ed055bd4da4fa0007bf3d0a--x3dom.netlify.app/examples/functional/proto/inline.html" rel="noreferrer noreferrer" target="_blank">https://5ed055bd4da4fa0007bf3d0a--x3dom.netlify.app/examples/functional/proto/inline.html</a><br>
>> > ><br>
>> > > -Andreas<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > On Thu, May 28, 2020 at 6:43 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> > > ><br>
>> > > > I could not resist a proof of concept for the subgraph inclusion part of Protos.<br>
>> > > ><br>
>> > > > <a href="https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html" rel="noreferrer noreferrer" target="_blank">https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html</a><br>
>> > > ><br>
>> > > > This is an absolutely minimal start. There is only creation of<br>
>> > > > instances, using only the first element in the ProtoBody. There is no<br>
>> > > > ProtoInterface or events handling.<br>
>> > > > It should work for all single node Protos.<br>
>> > > ><br>
>> > > > But it only took a few lines in the right place<br>
>> > > > (<a href="https://github.com/andreasplesch/x3dom/commit/1e0ff82c2f7c77adcb521d62ff5172cf159943fb" rel="noreferrer noreferrer" target="_blank">https://github.com/andreasplesch/x3dom/commit/1e0ff82c2f7c77adcb521d62ff5172cf159943fb</a>).<br>
>> > > ><br>
>> > > > I understand that only the first node in a ProtoBody is used for the<br>
>> > > > template. It can be of course a grouping node. Other nodes in the<br>
>> > > > ProtoBody can affect the first node with internal routing.<br>
>> > > ><br>
>> > > > Inline is in effect a grouping node but this will not translate to<br>
>> > > > ProtoInstance. I will have to look at more examples to understand<br>
>> > > > better how multiple nodes are inserted with a single ProtoInstance.<br>
>> > > ><br>
>> > > > -Andreas<br>
>> > > ><br>
>> > > ><br>
>> > > ><br>
>> > > > On Thu, May 28, 2020 at 3:09 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>> > > > ><br>
>> > > > > Let me write down a few notes on ProtoDeclare/Instance.<br>
>> > > > ><br>
>> > > > > - The expander approach would be ok for x3dom as well but I am not<br>
>> > > > > sure if it is easier to implement.<br>
>> > > > > - These are Statements and would be handled separately from Nodes,<br>
>> > > > > similar to ROUTE, in x3dom in NodeNameSpace.js<br>
>> > > > > - in x3dom gltf inlines are handled by translation to a (by default<br>
>> > > > > non-accessible) sub DOM, which is then tree parsed and added as a<br>
>> > > > > subgraph in a child namespace to the main scene. Similar to<br>
>> > > > > ProtoInstance this involves some processing before attaching to the<br>
>> > > > > main scene. So I think it would be not too hard to do the same for<br>
>> > > > > ProtoInstance by looking up the corresponding ProtoBody in a registry.<br>
>> > > > > The registry is populated while parsing, looking for ProtoDeclare<br>
>> > > > > elements.<br>
>> > > > > - the main challenge is how to implement custom fields, and 'IS' ing.<br>
>> > > > > For routing to ProtoInstances there needs to be a crossing of the<br>
>> > > > > namescope boundary.<br>
>> > > > > - ProtoInstances are more like Nodes than Statements, since they need<br>
>> > > > > to be included in traversing the scene.<br>
>> > > > > - not sure if x3dom currently has a way to send events into namescoped<br>
>> > > > > subgraphs (via IS/connect), and capture events from those (via<br>
>> > > > > IS/connect).<br>
>> > > > > - perhaps it makes sense to have the ProtoInstance statement construct<br>
>> > > > > a ProtoInstanceNode node to insert in the scenegraph. The statement<br>
>> > > > > takes care of field definitions for the node, and the node takes care<br>
>> > > > > of ISing and events during travesal.<br>
>> > > > ><br>
>> > > > > -Andreas<br>
>> > > > ><br>
>> > > > ><br>
>> > > > ><br>
>> > > > ><br>
>> > > > ><br>
>> > > > > On Thu, May 28, 2020 at 12:52 AM John Carlson <<a href="mailto:yottzumm@gmail.com" rel="noreferrer" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>> > > > > ><br>
>> > > > > > so perhaps this is the reasoning Leonard had.:<br>
>> > > > > ><br>
>> > > > > > Developers and designers want the full power of the web. If I restrict people to inlines, they can’t use standard tools to inspect the DOM, especially where it’s critical.<br>
>> > > > > ><br>
>> > > > > > 1. Should X3D4 allow all X3D elements in the HTML page or perhaps just a few?<br>
>> > > > > ><br>
>> > > > > > 2. Should X3D4 allow Protos on the main HTML page? Or only in inlines?<br>
>> > > > > ><br>
>> > > > > > John<br>
>> > > > ><br>
>> > > > ><br>
>> > > > ><br>
>> > > > > --<br>
>> > > > > Andreas Plesch<br>
>> > > > > Waltham, MA 02453<br>
>> > > ><br>
>> > > ><br>
>> > > ><br>
>> > > > --<br>
>> > > > Andreas Plesch<br>
>> > > > Waltham, MA 02453<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > --<br>
>> > > Andreas Plesch<br>
>> > > Waltham, MA 02453<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Andreas Plesch<br>
>> > Waltham, MA 02453<br>
>><br>
>><br>
>><br>
>> --<br>
>> Andreas Plesch<br>
>> Waltham, MA 02453<br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div></div>
</blockquote></div></div></div>
</div>