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

Tue Jun 16 06:19:40 PDT 2020

I am switching to a new implementation of Protos in x3dom. Most basic proto
examples in

https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html

started to work with the new implementation but routing in and out of a
protoinstance is still missing.

The new implementation defines a new node type for each ProtoDeclare which
then can be used like a native node. As a consequence, it will be possible
to optionally use a different syntax for ProtoInstance nodes. One can just
the the regular syntax for nodes:

< nodename fieldname="fieldvalue" >
  < childnode />
</ nodename >

This is more similar to the vrml encoding of protoinstances.

-Andreas

On Mon, Jun 8, 2020 at 5:34 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> I could identify the scoping and other issues to get working spin group
> and proto_nested examples:
>
>
> https://5edeabda853f6d72e3a951a8--x3dom.netlify.app/examples/functional/proto/inline.html
>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> <https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html#Front>
>
> The scoping issue with spin group was that a DEF in a ProtoInstance node
> fieldValue belongs to the namescope of the parent of the ProtoInstance, not
> just to the namescope of the ProtoInstance itself. Only the DEF names used
> in the ProtoBody are restricted to the namescope of the corresponding
> ProtoInstance.
>
> For the proto_nested example, there was a need to identify the case when a
> ProtoInstance has ISing, eg. is used inside a ProtoBody of another Proto
> which connectd to the fields of the ProtoInstance. As far as I remember
> Castle Engine does something similar. It is not beautiful, and I am not
> sure the bolted on solution works with deeper ISing.
>
> I may try a few more of the castle demo models. Perhaps there are more
> fairly easy to fix problems.
>
> Any feedback still very welcome,
>
> -Andreas
>
>
>
> On Mon, Jun 8, 2020 at 12:56 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> Looking at harder, more nested examples revealed quite a few problems
>> which are only partially fixed here:
>>
>> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
>> <https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html#Front>
>>
>>
>> https://5ede6856ca50c48058af6ed6--x3dom.netlify.app/examples/functional/proto/inline.html
>>
>>
>> This includes the spin group example and a few castle demo models. Fixes
>> include more careful parsing, route normalization and proto declaration
>> transfer into child name scopes.
>>
>> Spin group almost works but has trouble with DEF/USE name scoping of the
>> TouchSensor (a different scoping problem than the table2/leg2 problem in
>> proto_nested). Incidentally, the TouchSensor does not seem to react in
>> freeWrl also.
>>
>> I may try to describe the DEF/USE name scoping issue in spin group in
>> another request for clarification.
>>
>> I think it may be time to scrap this attempt and start over with a
>> different approach since the code is now too complex. A new approach would
>> probably define a new ProtoInstanceNode which fits better into the existing
>> x3dom infrastructure.
>>
>> -Andreas
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 5, 2020 at 3: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
>>>
>>
>>
>> --
>> 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/20200616/625e7da4/attachment-0001.html>