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

John Carlson yottzumm at gmail.com
Wed May 27 21:16:38 PDT 2020


A lot of this email is speculative, and subject to correction.

I believe, but could be wrong, that each X3DOM node contains a this._vf
property.  This means to change a node to reference several
protobody scenegraph instances under one DOM node is very undesirable in
X3DOM.  I believe this is the real reason that X3DOM doesn't currently have
Protos.   You may have heard "Oh there's different technology on the web to
do protos."  Heh, heh.

So how do we get rid of ProtoInstances, and still maintain namespaces?  Do
we need to?

Alternatives?   Maybe if we use an Inline to contain most of the model?


John

On Wed, May 27, 2020 at 10:06 PM John Carlson <yottzumm at gmail.com> wrote:

> Okay, let’s see how I would debug proto instances as tags in the HTML
> document.   Perhaps select the ProtoBody and see how selecting different
> ProtoInstances changes the contents of the ProtoBody.   Is anyone familiar
> with the web browser debuggers?
>
> John
> On Wed, May 27, 2020 at 9:26 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> If you read anything today, read paragraph starting with “Another.”
>>  After reading andreas email, I agree if the proto instances get converted
>> to separate DOM trees, Andreas approach might be possible.   If they remain
>> as proto instances, then we are probably at the mercy of the X3DOM
>> infrastructure.
>>
>> So this may means we are going through the horns of the dilemma, half
>> proto expander/half proto infrastructure built into X3DOM.
>>
>> Debugging won’t be pretty.
>>
>> John
>>
>> On Wed, May 27, 2020 at 9:12 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> It seems like we are confusing protos with the proto expander.   So far,
>>> I think I’ve only signed up for a generic, DOM based proto expander.   A
>>> non-expanded proto implementation may be easier or harder.   I think it
>>> would be very cool if we could implement protos and a proto expander with
>>> similar codebase, I’m just not sure such a thing is likely to emerge.   A
>>> proto expander is limited to Inlines, I think, so that would indicate
>>> implementing protos as registered tags—a browser environment, I think.
>>> I’ve never implemented registered tags.
>>>
>>> I agree that I could get rid of my expander implementation if we
>>> implemented protos.
>>>
>>> I think I should be very careful about what I sign up to do...if only
>>> for my health.
>>>
>>> Another thing I am seeing is that single elements will have to support
>>> multiple instances in the scene graph.   While this is easy enough with
>>> different inlines, my guess is this has much more impact when there’s only
>>> one parent DOM node present.   We should see how X_ITE does it.   If most
>>> X3DOM nodes can support several copies (as instances, not just DEF/USE),
>>> perhaps we can do it.
>>>
>>> I’m going to go read andreas’ emails again.
>>>
>>> John
>>>
>>> On Wed, May 27, 2020 at 8:06 PM John Carlson <yottzumm at gmail.com> wrote:
>>>
>>>>
>>>> It would be very nice if someone could sit down with me and explained
>>>> X3DOM namespace code.
>>>>
>>>>
>>>> On Wed, May 27, 2020 at 7:59 PM John Carlson <yottzumm at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Art Deco materials running with JSON files minus gridBack.x3d (try
>>>>> changing to gridBack.json, not sure...) at
>>>>> https://coderextreme.net/X3DJSONLD Select Art Deco examples from pull
>>>>> down.   You may have to flip file selection back and forth.
>>>>>
>>>>> Yes, I agree we need a DOM based expander.   We need 2 ways to do
>>>>> scoping, one for X3DOM, and one for the generic (non 3D) case.
>>>>>
>>>>> On Wed, May 27, 2020 at 7:48 PM John Carlson <yottzumm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Guys, I’m kinda panicking that replaceWorld() seems unavailable in
>>>>>> the X_ITE version I am using.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On Wed, May 27, 2020 at 7:44 PM John Carlson <yottzumm at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Considering it is likely that any Proto implementation in X3DOM will
>>>>>>> only be available in an Inline or similar url inclusion how worthwhile is
>>>>>>> it?   Have we considered CORS yet?
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 27, 2020 at 4:57 PM John Carlson <yottzumm at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Learning how to design and implement X3DOM *and* namescopes *and*
>>>>>>>> perhaps X_ITE at the same time is pretty much beyond my paygrade, unless I
>>>>>>>> get a doctorate (honorary is fine) in return.  I have been a application
>>>>>>>> programmer for most of my career.  That's pretty much what I enjoy doing.
>>>>>>>> That's why they didn't let me into SGI.  They wanted a systems guy.
>>>>>>>>
>>>>>>>> I think I *can* design and implement a DOM to DOM proto expander
>>>>>>>> (for any kind of DOM--use it with HTML or SVG if you like), if given
>>>>>>>> adequate supervision/help, since I've nearly implemented a JSON proto
>>>>>>>> expander.  This should not require learning much about X3DOM, from what I
>>>>>>>> see in the X3DOM code. Doug should know how far we can carry this and
>>>>>>>> perhaps where the gotchas are.
>>>>>>>>
>>>>>>>> But how well it will work is another question.  Perhaps we should
>>>>>>>> assign component levels to each feature I will implement?  I know the first
>>>>>>>> level :).
>>>>>>>>
>>>>>>>> Guys & gals, I'm getting anxiety.  This is NOT good.  I can't do
>>>>>>>> squat with anxiety, and we will be walking around this email thread for a
>>>>>>>> very long time.  Note that i *can* compose emails with anxiety! Seriously!
>>>>>>>>
>>>>>>>> So what's more valuable, an X3DOM Proto handler, or a generic DOM
>>>>>>>> to DOM proto expander that can be applied in many use cases in XML and/or
>>>>>>>> HTML?
>>>>>>>> Which one is eminently more doable?
>>>>>>>>
>>>>>>>> A bird in the hand is worth two in the bush.  Let's work on
>>>>>>>> something with wider scope than X3D/X3DOM/X_ITE.  Maybe we can get other
>>>>>>>> people to play in our sandbox.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>> On Wed, May 27, 2020 at 4:22 PM John Carlson <yottzumm at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Andreas, when you expand the ProtoInstances, the
>>>>>>>>> scoping disappears, thus you need to put the instance scope in any DEF or
>>>>>>>>> name that appears in the ProtoBody.
>>>>>>>>>
>>>>>>>>> Are we implementing an expander, or full on Protos?
>>>>>>>>>
>>>>>>>>> Sorry if I haven't made this clearer.
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On Wed, May 27, 2020 at 4:02 PM Andreas Plesch <
>>>>>>>>> andreasplesch at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I created a test for namescopes in Inline nodes:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://gist.github.com/andreasplesch/f959aaaf04475922bdfbdf1aaca8476b
>>>>>>>>>>
>>>>>>>>>> This is using the same DEF names for clock, interpolator and
>>>>>>>>>> material
>>>>>>>>>> for both the main scene and within the Inline scene.
>>>>>>>>>>
>>>>>>>>>> It seems to work fine, without interference between the inline
>>>>>>>>>> and main scopes:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://gist.githack.com/andreasplesch/f959aaaf04475922bdfbdf1aaca8476b/raw/a6d08ddb67eb055dd4ada4624374c8712cf15893/namescope_x3dom2.html
>>>>>>>>>>
>>>>>>>>>> The idea will be to use the same mechanism for ProtoInstances. I
>>>>>>>>>> think
>>>>>>>>>> the spec. requires that each ProtoInstance has its own namescope.
>>>>>>>>>>
>>>>>>>>>> -Andreas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, May 27, 2020 at 3:43 PM Andreas Plesch <
>>>>>>>>>> andreasplesch at gmail.com> wrote:
>>>>>>>>>> >
>>>>>>>>>> > Hi John,
>>>>>>>>>> >
>>>>>>>>>> > I think Inline in x3dom properly isolates the namescope within
>>>>>>>>>> Inlines
>>>>>>>>>> > from the namescope of the main scene. So it should be possible
>>>>>>>>>> to have
>>>>>>>>>> > DEF/USE names within an Inline which are identical with ones in
>>>>>>>>>> the
>>>>>>>>>> > main scene, without causing confusion. Perhaps there is an
>>>>>>>>>> example for
>>>>>>>>>> > that to test with.
>>>>>>>>>> >
>>>>>>>>>> > -Andreas
>>>>>>>>>> >
>>>>>>>>>> > On Wed, May 27, 2020 at 12:03 PM John Carlson <
>>>>>>>>>> yottzumm at gmail.com> wrote:
>>>>>>>>>> > >
>>>>>>>>>> > > I think the big monster in the closet is whether we have to
>>>>>>>>>> rewrite DEF/USE/name values (for ROUTEs at least), or if we can use X3DOM's
>>>>>>>>>> namespaces. If we have to rewrite the values, I don't see value in using
>>>>>>>>>> X3DOM's infrastructure--we just hand it an expanded DOM.
>>>>>>>>>> > >
>>>>>>>>>> > > John
>>>>>>>>>> > >
>>>>>>>>>> > > On Wed, May 27, 2020 at 9:50 AM John Carlson <
>>>>>>>>>> yottzumm at gmail.com> wrote:
>>>>>>>>>> > >>
>>>>>>>>>> > >> I see one issue with approach, but it is a good first step:
>>>>>>>>>> > >>
>>>>>>>>>> > >> In current ProtoExpander, name values, DEF/USE values are
>>>>>>>>>> rewritten.  So Scripts attributes, ROUTE attributes, etc. need to be
>>>>>>>>>> rewritten as well.  That's only the second step.  So really, the whole
>>>>>>>>>> scene needs be examined.  It will become difficult, I think, to extract the
>>>>>>>>>> non-Inlined, non-ExternProtoDeclare items from the existing DOM.  So we are
>>>>>>>>>> limited to Inlines, or how X_ITE does it with the URL in X3DCanvas tag.
>>>>>>>>>> JSON is limited to Inlines, so limiting to Inlines is probably OK.  But
>>>>>>>>>> we'll need to ask Don about his examples and converters.  Note that
>>>>>>>>>> X3DJSONLD is not limited to Inlines though, but it loads JSON from files,
>>>>>>>>>> which is equivalent.
>>>>>>>>>> > >>
>>>>>>>>>> > >> Suggestions?  It's good to think simple cases, but we need a
>>>>>>>>>> holistic approach to design if we're going to solve this.
>>>>>>>>>> > >>
>>>>>>>>>> > >> So we have
>>>>>>>>>> > >>
>>>>>>>>>> > >> 1.  Use Inlines
>>>>>>>>>> > >> 2.  Rewrite DEF/USE/name.
>>>>>>>>>> > >>
>>>>>>>>>> > >> John
>>>>>>>>>> > >>
>>>>>>>>>> > >>
>>>>>>>>>> > >> On Tue, May 26, 2020 at 10:00 PM Don Brutzman <
>>>>>>>>>> brutzman at nps.edu> wrote:
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> As discussed Monday: Prototype Expander may have general
>>>>>>>>>> value, but primary need is adding Prototype support to X3DOM.
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> Recommend scrapping all options as distracting alternative
>>>>>>>>>> future work.
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> Simply focus on the X3DOM prize in JavaScript.  Path to get
>>>>>>>>>> there is a straight line:
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> 1. Concept: ProtoDeclare is a template definition,
>>>>>>>>>> ProtoInstance creates a scene subgraph.
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> 2. Thus the only resulting code of interest looks like
>>>>>>>>>> X3DOM scene subgraph.
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> 3. Collect and create corresponding pairs of (a) inputs
>>>>>>>>>> (ProtoDeclare/ProtoInstance) and (b) outputs (X3DOM scene subgraph).
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> 4. The ProtoExpander is native X3DOM javascript code reads
>>>>>>>>>> 3(a) and creates 3(b).
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> ====================
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> That's it.  No really.
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> Recommended first model for input/output inventory:
>>>>>>>>>> ArtDeco00, which is a simple Material node.
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> *
>>>>>>>>>> https://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials/ArtDecoPrototypesIndex.html
>>>>>>>>>> > >>> *
>>>>>>>>>> https://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials/ArtDecoPrototypes.json
>>>>>>>>>> > >>> *
>>>>>>>>>> https://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials/ArtDecoExamplesIndex.html
>>>>>>>>>> > >>> *
>>>>>>>>>> https://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials/ArtDecoExamples.json
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> JSON input
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> { "ProtoDeclare":
>>>>>>>>>> > >>>    {
>>>>>>>>>> > >>>      "@name":"ArtDeco00",
>>>>>>>>>> > >>>      "@appinfo":"UniversalMediaMaterials prototype",
>>>>>>>>>> > >>>      "@documentation":"
>>>>>>>>>> https://www.web3d.org/x3d/content/examples/Basic/UniversalMediaMaterials
>>>>>>>>>> ",
>>>>>>>>>> > >>>      "ProtoBody": {
>>>>>>>>>> > >>>          "-children":[
>>>>>>>>>> > >>>            { "Material":
>>>>>>>>>> > >>>              {
>>>>>>>>>> > >>>                "@ambientIntensity":0.25,
>>>>>>>>>> > >>>                "@diffuseColor":[0.282435,0.085159,0.134462],
>>>>>>>>>> > >>>                "@shininess":0.127273,
>>>>>>>>>> > >>>                "@specularColor":[0.276305,0.11431,0.139857]
>>>>>>>>>> > >>>              }
>>>>>>>>>> > >>>            }
>>>>>>>>>> > >>>          ]
>>>>>>>>>> > >>>      }
>>>>>>>>>> > >>>    }
>>>>>>>>>> > >>> },
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> JSON result of interest:
>>>>>>>>>> > >>>
>>>>>>>>>> > >>>            { "Material":
>>>>>>>>>> > >>>              {
>>>>>>>>>> > >>>                "@ambientIntensity":0.25,
>>>>>>>>>> > >>>                "@diffuseColor":[0.282435,0.085159,0.134462],
>>>>>>>>>> > >>>                "@shininess":0.127273,
>>>>>>>>>> > >>>                "@specularColor":[0.276305,0.11431,0.139857]
>>>>>>>>>> > >>>              }
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> First draft of converter: extract everything inside
>>>>>>>>>> ProtoBody, ignore the rest.
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> So you are now halfway to first example.  If that is how
>>>>>>>>>> JSON says it in JavaScript, how does X3DOM say it in JavaScript?
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> If still puzzled, here is a second-opinion point of
>>>>>>>>>> comparison: how does X_ITE say it?
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> Have fun with X3D JavaScript, I hope...
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> On 5/26/2020 9:29 AM, John Carlson wrote:
>>>>>>>>>> > >>> > There's also choice of data structure
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>> > 1.  Mostly DOM/JDON, relying on functions
>>>>>>>>>> > >>> > 2.  Full X3DJSAIL-like data structure
>>>>>>>>>> > >>> > 3.  Just the Proto classes.
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>> > On Tue, May 26, 2020 at 2:59 AM John Carlson <
>>>>>>>>>> yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>> >     1.  Keep current implementation, debug it
>>>>>>>>>> > >>> >     2.  Add XML -> JSON -> XML to current
>>>>>>>>>> implementation.  Code is written, but not tested extensively
>>>>>>>>>> > >>> >     3.  Write a new version in XML
>>>>>>>>>> > >>> >     4.  Copy and port X_ITE's Proto code.
>>>>>>>>>> > >>> >     5.  Write a new XML based proto expander.
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>> >     We *do* want at least an XML proto expander.
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>> >     Anyone want to help with any of these?  There are a
>>>>>>>>>> lot of options.
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>> > _______________________________________________
>>>>>>>>>> > >>> > X3dom-users mailing list
>>>>>>>>>> > >>> > X3dom-users at lists.sourceforge.net
>>>>>>>>>> > >>> > https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>>>>>>>>> > >>> >
>>>>>>>>>> > >>>
>>>>>>>>>> > >>> all the best, Don
>>>>>>>>>> > >>> --
>>>>>>>>>> > >>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>>>>>>>>>> brutzman at nps.edu
>>>>>>>>>> > >>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>>>>>>>>>>  +1.831.656.2149
>>>>>>>>>> > >>> X3D graphics, virtual worlds, navy robotics
>>>>>>>>>> http://faculty.nps.edu/brutzman
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > --
>>>>>>>>>> > 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/20200527/3c0f0b34/attachment-0001.html>


More information about the x3d-public mailing list