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

Sat Jun 6 10:38:41 PDT 2020

rubik*.x3d provide fairly good testing of nesting, but probably not
perfect.   Have you tested the t1.x3d example yet?

Thanks,

John

On Fri, Jun 5, 2020 at 2:24 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> I added an example of a Prototype generating an output event, an
> IntegerTrigger which only triggers upon receiving true:
>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>
> https://5eda866f96703e0007fba0af--x3dom.netlify.app/examples/functional/proto/inline.html
>
> The implementation adds forwarding of internal node generated events
> to the ProtoInstance pseudo node, using the internal x3dom route
> mechanism.
>
>  I think that concludes this effort for Prototype support in x3dom.
> Most functionality should be available.
>
> Missing features are
>
> - DOM based modification of ProtoInstance field values (probably possible)
> - routing of node value fields (in x3dom in general), but it is
> possible to use ProtoInstance fieldValue for node values.
> - no Script node support (in x3dom in general), unrelated although
> Scripts are very often used in Prototypes.
>
> There are no plans from my side to add support for these missing features.
>
> Builds for testing more thoroughly are available here:
>
> https://5eda866f96703e0007fba0af--x3dom.netlify.app/
>
> In particular, nested situations need testing, eg. ProtoInstances in
> ProtoDeclaration, ProtoInstances in ProtoInstance fields, and
> ProtoDeclarations in ProtoInstances (if that makes sense).
>
> I should check the castle library of examples.
>
> After a period of testing, ExternProto support should be relatively
> less complicated to provide.
>
> Looking forward to any reports,
>
> -Andreas
>
> On Thu, Jun 4, 2020 at 1:56 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >
> > Just another incremental update which enables event routing into
> > ProtoInstances, via forwarding to the internal nodes:
> >
> > https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >
> https://5ed930d641a27700082647b9--x3dom.netlify.app/examples/functional/proto/inline.html
> >
> > Sofar it was possible to treat ProtoInstance as a statement without
> > generating a full X3DNode derived member of the scene graph. This was
> > easier to reason about, following the expansion approach. But I start
> > to think it required essentially reimplementing enough of the X3DNode
> > related functionality that it may be time to try to switch to have a
> > ProtoInstanceNode itself in the scenegraph which then internally
> > represents itself with the Proto definition.
> >
> > What would be a good example to test routing events emitted from a
> > ProtoInstance, without a script node ? Eg. a useful Proto which
> > generates events ? Perhaps a combination of event utilities ?
> >
> > -Andreas
> >
> > On Wed, Jun 3, 2020 at 7:17 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> > >
> > > I could enable custom fields for Protos, eg. ProtoInterface,
> > > IS/connect and ProtoInstance fieldValue, to a usable degree:
> > >
> > >
> https://5ed82885ae201410e81024b3--x3dom.netlify.app/examples/functional/proto/inline.html
> > >
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> > >
> > > ( key 'a' or 'r' of you do not see the fish, to adjust the view. )
> > >
> > > SFNode type fields work, MFNode type fields perhaps also. Initial
> > > value from ProtoInterface, and using the ProtoInstance field value
> > > otherwise should work. Routing from and to a ProtoInstance does not
> > > work yet. Is there an example _without_ Script node which uses routes
> > > from or to a ProtoInstance ?
> > >
> > > I also came across the question what to do if in a ProtoBody a node
> > > which has a IS field connection to a ProtoField with an initial value,
> > > also has a field value for the same field. Here is an example:
> > >
> > > <ProtoInterface>
> > >   <field accessType='inputOutput' name='color' type='SFColor'
> value='0,0,0'/>
> > > ...
> > >
> > > <ProtoBody>
> > >   <Material diffuseColor='1,0,0'>
> > >      <IS>
> > >         <connect protoField='color' nodeField='diffuseColor' />
> > > ...
> > >
> > > Is the initial color 0,0,0 (black) or 1,0,0 (red) ? Probably black.
> > >
> > > To avoid this redundancy, the initial value could only be defined in
> > > the ProtoBody, in a future iteration of X3D.
> > >
> > > All the code is still NodeNameSpace.js. It was possible to keep it
> > > separate from existing functions. The approach for field manipulation
> > > is largely via DOM updates of cloned ProtoBodies. This avoids having
> > > to deal with field value types.
> > >
> > > I have an idea for Routing, so this is next. A good example would be
> > > great. Perhaps animating the table colors is an easy one first.
> > >
> > > -Andreas
> > >
> > > On Mon, Jun 1, 2020 at 8:09 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> > > >
> > > > Ok, true.
> > > >
> > > > If default values are the main reason to have a ProtoInterface, they
> could be just moved into the connect tag as a value attribute.
> > > >
> > > > Alternatively, the spec. could define that default values always
> fall back to the default value of the connected field of a native x3d node.
> The recommendation is any case to provide values for all fields in a
> ProtoInstance since a Proto may not be well documented.
> > > >
> > > > So simplifying protos may be possible by only relying on IS
> connections to define fields and omitting or moving the ability to allow
> custom default values.
> > > >
> > > > ProtoInterface does provide a nice, consolidated place to list all
> parameters for a Proto. But that is really a documentation feature, and
> ProtoDeclares typically are accompanied by an example ProtoInstance
> intended to show how to use Proto parameters/fields.
> > > >
> > > > Lastly, ProtoInterface does allow restricting access to native
> inputoutput fields to only input or only output. But when is that ability
> really useful ? Authors know how a Proto is intended to be used, and
> implementations have to support all access types in any case.
> > > >
> > > > Protos are very verbose in the xml encoding. So not needing a
> ProtoInterface section would help a little with cutting down this verbosity.
> > > >
> > > > Andreas
> > > >
> > > > ---on the phone---
> > > >
> > > > On Sun, May 31, 2020, 7:11 PM John Carlson <yottzumm at gmail.com>
> wrote:
> > > >>
> > > >> 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
> > >
> > >
> > >
> > > --
> > > 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/20200606/69cf3221/attachment-0001.html>