[x3d-public] [x3dom-users] Whither protoexpander in X3DOM? umm, just define input-to-output and write code

Sun May 31 16:10:49 PDT 2020

We need protointerface for default values.

On Sun, May 31, 2020 at 4:50 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> I adopted the idea to put the helper/sibling nodes of a ProtoInstance
> into a Switch node, which is added as a root node to the main scene.
> See the new MaterialBlinker proto here:
>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>
> https://5ed41e4b7244550007f7272f--x3dom.netlify.app/examples/functional/proto/inline.html
>
>
> https://github.com/andreasplesch/x3dom/blob/gh-pages/test/functional/proto/MaterialBlinker.x3d
>
> The added switch node exists only in the x3d graph, not in the dom
> graph, so is kind of hidden.
>
> This is starting to have wider use compared to DEF/USE instancing.
>
> The next step would be routable fields. It would be nice to break down
> that functionality into smaller units.
>
> One way to think about IS/connect is to ignore the ProtoInterface
> definition initially and use directly the field names mentioned in the
> connect tag to establish additional internal routes. It may be
> preferable to modify routes since sofar there is no actual
> ProtoInstanceNode node with actual fields. An idea may be to define
> such a node which does not do anything other than define the custom
> fields and forward events to the internal nodes.
>
> Would it be possible to autogenerate a ProtoInterface definition from
> a ProtoBody with IS connections ? The fields names are all there and
> the access types just follow the types from the native nodes. Do we
> actually need a ProtoInterface definition ?
>
> -Andreas
>
> On Sat, May 30, 2020 at 12:30 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >
> > Sorry, I misunderstood how Switch could help. I missed the expanded
> example:
> >
> >
> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorPrototypeExpandedIndex.html
> >
> > The Switch node containing the sibling/helper nodes is just appended
> > to the end of the main scene, not after the main node. Does that work
> > in general ? It may (but nesting?). It also means that the siblings
> > nodes can only be X3DChildNodes which also may be ok. Could there be
> > non child nodes which are used as helpers nodes ? I cannot think of
> > any right now although the spec. does not seem to restrict what is
> > inside a Proto definition.
> >
> > Let's think about nesting and DEF/USE. USE of ProtoInstance may work
> > by just placing a USE instance of the main node, upon expansion or
> > scene construction. I think it could.
> >
> > But where would the sibling Switch go for a nested ProtoInstance,
> > inside a ProtoBody ?
> >
> > I will try to add some diagrams but this will be quite dizzying.
> > Apologies for that.
> >
> > If the ProtoInstance is or is inside the first, main node, upon
> > expansion a potential sibling Switch would be appended after the
> > siblings of the first node, as another sibling:
> >
> > ProtoBody
> >   main node: ProtoInstance
> >   siblings
> >
> > expansion ->
> >
> > ProtoBody
> >   main node: ProtoInstanceExpandedMain
> >   siblings
> >   ProtoInstanceExpandedSwitch
> >
> > Then, the expansion of the ProtoBody would place a Switch node
> > containing all siblings which now includes the inner sibling Switch at
> > the end of the main scene. That sounds right to me.
> >
> > If the ProtoInstance is a sibling the first, main node, upon expansion
> > a potential sibling Switch would be appended after the siblings of the
> > first node, as another sibling, along with the main node:
> >
> > ProtoBody
> >   main node
> >   siblings
> >   ProtoInstance
> >
> > expansion ->
> >
> > ProtoBody
> >   main node
> >   siblings
> >   ProtoInstanceExpandedMain
> >   ProtoInstanceExpandedSwitch
> >
> > Then, the expansion of the ProtoBody would place a Switch node
> > containing all siblings which now includes both the inner main and the
> > inner sibling Switch at the end of the main scene. That looks also
> > reasonable at first glance.
> >
> > In that sense ProtoInstance would require ProtoDeclare or ProtoBody to
> > be recognized similar to Scene, for expansion purposes. That is
> > similar to how x-ite works. For x-ite a ProtoDeclaration is a
> > ExecutionContext.
> >
> > Well, I think this helped me understand Protos a bit better in any case,
> >
> > -Andreas
> >
> > On Fri, May 29, 2020 at 7:36 PM John Carlson <yottzumm at gmail.com> wrote:
> > >
> > > Don suggested a Switch node at one point (thanks Don).
> > >
> > > On Fri, May 29, 2020 at 1:28 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> > >>
> > >> Internal namescopes and better parsing made nested ProtoDeclares
> > >> inside ProtoBody and internal ROUTEs work:
> > >>
> > >>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> > >>
> https://5ed144877a8ae8000756ddd1--x3dom.netlify.app/examples/functional/proto/inline.html
> > >>
> > >> I am still not sure how to think about multiple nodes in a ProtoBody
> > >> template since these are not scenes. Many examples seem to have only
> > >> one node, and only routes outside of it.
> > >>
> > >> Conceptually, it is pretty clear that the first node is THE node, and
> > >> other nodes do not render but are active and can be connected.
> > >>
> > >> Let's look at the Material Modulator example:
> > >>
> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorIndex.html
> > >>
> > >> The main node is the Material node but then there are Script and
> > >> TimeSensor siblings, and routes.
> > >>
> > >> So the instance will be of Material node kind, an
> > >> X3DAppearanceChildNode. This allows the instance to be accepted as a
> > >> value of the Material field in an Appearance node.
> > >>
> > >> But the Script and TimeSensor sibling instances will not be able to
> > >> continue to live as siblings next to the instanced Material node since
> > >> they are not X3DAppearanceChildNodes. They will need to live somewhere
> > >> else but still be able to control the instanced Material node.
> > >>
> > >> So a straight transfer of a one to one instance to the scene seems out
> > >> of the question.
> > >>
> > >> I kind of hope I am missing something ? Is there another way to think
> > >> about Protoinstances ?
> > >>
> > >> Probably time to look at other code for inspiration.
> > >>
> > >> -Andreas
> > >>
> > >> On Fri, May 29, 2020 at 8:39 AM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> > >> >
> > >> > I added a few more Proto test examples to
> > >> >
> > >> >
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> > >> >
> > >> > and
> > >> >
> > >> >
> https://5ed100c873166e0006438ab0--x3dom.netlify.app/examples/functional/proto/inline.html
> > >> >
> > >> > That includes a NIST example which uses internal routing and one
> which
> > >> > has ProtoDeclare inside ProtoBody, nested five deep. These are good
> > >> > targets to get to work before thinking about fields and interface.
> > >> >
> > >> >
> https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO/index.html
> > >> >
> > >> > -Andreas
> > >> >
> > >> > On Thu, May 28, 2020 at 8:35 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> > >> > >
> > >> > > It turns out that github pages does not like serving all the
> little js
> > >> > > files making up x3dom separately.
> > >> > >
> > >> > > Here is a complete build with the example:
> > >> > >
> > >> > >
> https://5ed055bd4da4fa0007bf3d0a--x3dom.netlify.app/examples/functional/proto/inline.html
> > >> > >
> > >> > > -Andreas
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Thu, May 28, 2020 at 6:43 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> > >> > > >
> > >> > > > I could not resist a proof of concept for the subgraph
> inclusion part of Protos.
> > >> > > >
> > >> > > >
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> > >> > > >
> > >> > > > This is an absolutely minimal start. There is only creation of
> > >> > > > instances, using only the first element in the ProtoBody. There
> is no
> > >> > > > ProtoInterface or events handling.
> > >> > > > It should work for all single node Protos.
> > >> > > >
> > >> > > > But it only took a few lines in the right place
> > >> > > > (
> https://github.com/andreasplesch/x3dom/commit/1e0ff82c2f7c77adcb521d62ff5172cf159943fb
> ).
> > >> > > >
> > >> > > > I understand that only the first node in a ProtoBody is used
> for the
> > >> > > > template. It can be of course a grouping node. Other nodes in
> the
> > >> > > > ProtoBody can affect the first node with internal routing.
> > >> > > >
> > >> > > > Inline is in effect a grouping node but this will not translate
> to
> > >> > > > ProtoInstance. I will have to look at more examples to
> understand
> > >> > > > better how multiple nodes are inserted with a single
> ProtoInstance.
> > >> > > >
> > >> > > > -Andreas
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Thu, May 28, 2020 at 3:09 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> > >> > > > >
> > >> > > > > Let me write down a few notes on ProtoDeclare/Instance.
> > >> > > > >
> > >> > > > > - The expander approach would be ok for x3dom as well but I
> am not
> > >> > > > > sure if it is easier to implement.
> > >> > > > > - These are Statements and would be handled separately from
> Nodes,
> > >> > > > > similar to ROUTE, in x3dom in NodeNameSpace.js
> > >> > > > > - in x3dom gltf inlines are handled by translation to a (by
> default
> > >> > > > > non-accessible) sub DOM, which is then tree parsed and added
> as a
> > >> > > > > subgraph in a child namespace to the main scene. Similar to
> > >> > > > > ProtoInstance this involves some processing before attaching
> to the
> > >> > > > > main scene. So I think it would be not too hard to do the
> same for
> > >> > > > > ProtoInstance by looking up the corresponding ProtoBody in a
> registry.
> > >> > > > > The registry is populated while parsing, looking for
> ProtoDeclare
> > >> > > > > elements.
> > >> > > > > - the main challenge is how to implement custom fields, and
> 'IS' ing.
> > >> > > > > For routing to ProtoInstances there needs to be a crossing of
> the
> > >> > > > > namescope boundary.
> > >> > > > > - ProtoInstances are more like Nodes than Statements, since
> they need
> > >> > > > > to be included in traversing the scene.
> > >> > > > > - not sure if x3dom currently has a way to send events into
> namescoped
> > >> > > > > subgraphs (via IS/connect), and capture events from those (via
> > >> > > > > IS/connect).
> > >> > > > > - perhaps it makes sense to have the ProtoInstance statement
> construct
> > >> > > > > a ProtoInstanceNode node to insert in the scenegraph. The
> statement
> > >> > > > > takes care of field definitions for the node, and the node
> takes care
> > >> > > > > of ISing and events during travesal.
> > >> > > > >
> > >> > > > > -Andreas
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > On Thu, May 28, 2020 at 12:52 AM John Carlson <
> yottzumm at gmail.com> wrote:
> > >> > > > > >
> > >> > > > > > so perhaps this is the reasoning Leonard had.:
> > >> > > > > >
> > >> > > > > > 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.
> > >> > > > > >
> > >> > > > > > 1.   Should X3D4 allow all X3D elements in the HTML page or
> perhaps just a few?
> > >> > > > > >
> > >> > > > > > 2.  Should X3D4 allow Protos on the main HTML page?  Or
> only in inlines?
> > >> > > > > >
> > >> > > > > > John
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > --
> > >> > > > > Andreas Plesch
> > >> > > > > Waltham, MA 02453
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Andreas Plesch
> > >> > > > Waltham, MA 02453
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Andreas Plesch
> > >> > > Waltham, MA 02453
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Andreas Plesch
> > >> > Waltham, MA 02453
> > >>
> > >>
> > >>
> > >> --
> > >> Andreas Plesch
> > >> Waltham, MA 02453
> >
> >
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200531/f9e87d65/attachment-0001.html>