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

Thu Jun 25 18:08:29 PDT 2020

Andreas, I’m just checking to see if you’ve removed the JSON proto expander
from the code.  Would you like me to pursue removing the expander and test
your code after it gets through the JSONParser?

Thanks!

John

On Tue, Jun 16, 2020 at 8:20 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> 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/20200625/27c11f08/attachment-0001.html>