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

John Carlson yottzumm at gmail.com
Fri May 29 17:16:47 PDT 2020


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.

John


On Fri, May 29, 2020 at 6:47 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> I think the idea would be to use a Switch node as a wrapper around the
> ProtoBody nodes. Sounds like an idea but Switch nodes only take
> X3DChildNodes, so no Material nodes, for example. But perhaps there
> was another thought.
>
> I am trying to read through castle-engine and x-ite solutions but I am
> not quite making sense of those. castle has some good and a bit scary
> comments abouts ISing.
>
> -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200529/43099f8e/attachment.html>


More information about the x3d-public mailing list