<div><div dir="auto">Don suggested a Switch node at one point (thanks Don).</div><div dir="auto"><br></div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 1:28 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)">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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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>
</blockquote></div></div>