[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 17:59:04 PDT 2020
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/f903f2ea/attachment-0001.html>
More information about the x3d-public
mailing list