[x3d-public] Problem in x3dviewscene: ROUTE placement
John Carlson
yottzumm at gmail.com
Sun Jun 11 17:58:03 PDT 2023
Don, this model shows Routes under Scene, and we are talking about Routes
under Group and Transform, I think. I don’t think we have an actual
example of that case yet.
Thanks,
John
On Sun, Jun 11, 2023 at 4:36 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> John, here is a JSON autogenerated example (using stylesheet we developed
> together) matching the other forms provided in response to Michalis. Many
> more available, likely does not need to be on your TODO list.
>
>
>
> -
> https://www.web3d.org/x3d/content/examples/Vrml2Sourcebook/Chapter08AnimatingPositionOrientationScale/Figure08_3PositionInterpolator.json
>
>
>
> 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
> https://faculty.nps.edu/brutzman
>
>
>
> *From:* John Carlson <yottzumm at gmail.com>
> *Sent:* Saturday, June 10, 2023 12:30 PM
> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Cc:* Michalis Kamburelis <michalis.kambi at gmail.com>; X3D Graphics public
> mailing list <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>
>
>
> I believe this example is current. It shows a mixed-node result.
>
>
>
> The third option was taken, which should preserve structure across
> encodings. I will also run this example through my Java and JavaScript
> JSON validators.
>
>
>
> John
>
>
>
> On Sat, Jun 10, 2023 at 2:14 PM John Carlson <yottzumm at gmail.com> wrote:
>
> The third option was chosen, with only advantages, possibly.
>
>
>
> Probably it would be easiest to create an example. I will put that on my
> todo list.
>
>
>
> John
>
>
>
> On Sat, Jun 10, 2023 at 2:10 PM John Carlson <yottzumm at gmail.com> wrote:
>
> Here: “*Disadvantages:* ordering of ROUTE statements is lost, relative to
> other children nodes. ROUTEs are placed at the end, only a partial order is
> retained.”
>
>
>
> From:
>
>
>
> https://www.web3d.org/x3d/stylesheets/X3dToJson.html
>
>
>
> John
>
>
>
> On Sat, Jun 10, 2023 at 2:03 PM John Carlson <yottzumm at gmail.com> wrote:
>
> I’m further remembering perhaps that these many routes were placed into a
> JSON array of routes?
>
>
>
> It’s been a very long time, I would have to recheck.
>
>
>
> Water under the bridge?
>
> On Sat, Jun 10, 2023 at 1:58 PM John Carlson <yottzumm at gmail.com> wrote:
>
> My impression was that they were being moved out (from a nested context)
> or down the scenegraph, collecting many routes together.
>
>
>
> I didn’t write X3dToJson.xslt. It’s not my expertise, but i may be able
> to find some examples with roundtripping.
>
>
>
> It would be easy to test by sprinkling many routes at same level in XML,
> then convert to JSON to see if they are collected. I hope this helps.
>
>
>
> HAnim is higher priority.
>
>
>
> John
>
>
>
> On Sat, Jun 10, 2023 at 1:45 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
> Good question, not sure where they are getting moved. Examples always
> welcome. When JSON Schema is finally approved and implemented, we’ll be
> able to formalize that.
>
>
>
> - X3D Resources, Examples: Scene Archives for X3D
> - https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
>
>
>
> Expectation is that ordering of nodes and ROUTE statements will be
> consistent for ClassicVRML, XML, JSON, Java, Python, etc., allowing
> symmetric conversion between representations. Hence the careful scrutiny
> as we go. Thanks for tracking this John.
>
>
>
> 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
> https://faculty.nps.edu/brutzman
>
>
>
> *From:* John Carlson <yottzumm at gmail.com>
> *Sent:* Saturday, June 10, 2023 11:28 AM
> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Cc:* Michalis Kamburelis <michalis.kambi at gmail.com>; X3D Graphics public
> mailing list <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>
>
>
> Don, does this make it so we don’t have to move routes around in the JSON
> encoding?
>
>
>
> I was not clear why they needed to be moved.
>
>
>
> Thanks,
>
>
>
> John
>
>
>
> On Sat, Jun 10, 2023 at 1:05 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
> Well, closer, but not quite there yet. Here is some more “language
> lawyering.” 8)
>
>
>
> BLUF: it is important and allowed for ROUTE statements (and prototype
> statements) to appear in MFNode lists, side by side with other nodes.
>
>
>
> Not exactly sure what you mean by MFList. Presumably you mean MFNode,
> which is one of the approved concrete or abstract types in
>
>
>
> - X3D 4.0 Part 1: Architecture and base components, clause 5 Field
> type reference
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/fieldTypes.html
>
>
>
> I believe that the rules are telling us that the ROUTE statement can
> appear where other nodes can appear. Typically that is within an MFNode
> list.
>
>
>
> - X3D 4.0 Part 1: Architecture and base components, clause 5 Field
> type reference, 5.3 Field types, 5.3.12 SFNode and MFNode
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/fieldTypes.html#SFNodeAndMFNode
> - The SFNode field specifies an X3D node. The MFNode field specifies
> zero or more nodes.
> - The default value of an uninitialized SFNode field is NULL. The
> default value of an MFNode field is the empty list.
>
>
>
> The third bullet above likely needs to be modified to say
>
> - The SFNode field specifies an X3D node. The MFNode field specifies
> zero or more nodes, also allowing ROUTE or prototype statements.
>
>
>
> Also relevant, with another suggested addition, again providing clarity
> and consistency with 4.4.8.2 Routes and 4.4.4 Prototype semantics:
>
> - 5.2.2 X3DArrayField
> - X3DArrayField is the abstract field type from which all field types
> that can contain multiple values are derived. All fields derived from
> X3DArrayField have names beginning with *MF* (multiple-valued field).
> MF fields may zero or more values, each of which shall be of the type
> indicated by the corresponding SF field type. It is illegal for any MF
> field to mix values of different SF field types. An MFNode field can
> also include ROUTE and prototype statements.
> - 5.2.3 X3DField
> - X3DField is the abstract field type from which all single values
> field types are derived. All fields directly derived from X3DField have
> names beginning with *SF* (single-valued field). SF fields may only
> contain a single value of the type indicated by the name of the field type.
>
>
>
> Corresponding ClassicVRML grammar productions:
>
> - X3D 3.3 encodings, Part 2: Classic VRML encoding, Annex A
> (normative) Grammar, A.2 General
> -
> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#General
>
>
> *statements *::=
>
> *statement *|
>
> *statement statements *|
>
> *empty *;
>
> *statement *::=
>
> *nodeStatement* |
> *importStatement* |
> *exportStatement |*
>
> *protoStatement* |
>
> *routeStatement* ;
>
> *nodeStatement *::=
>
> *node* |
>
> *DEF **nodeNameId node* |
>
> *USE** nodeNameId* ;
>
>
>
> IMPORT and EXPORT statements only appear in special locations related to
> Inline node usage, and don’t seem to need special mention in the prose
> above.
>
>
>
> We certainly have many hundreds of validated examples that include ROUTE
> statements along with other children nodes, as part of MFNode lists. Large
> parts of our existing infrastructure support this construct, in accordance
> with X3D Architecture.
>
>
>
> Bottom line: it is important and allowed for ROUTE statements (and
> prototype statements) to appear in MFNode lists, side by side with other
> nodes.
>
>
>
> If the two highlighted sentences above seem like useful additions, I’ll
> create a Mantis issue and we can inquire if ISO editors will accept such a
> change at this very late date.
>
>
>
> Again thanks for careful scrutiny. Looking forward to regaining full
> consensus on this important design issue which is critical to consistent
> X3D model interoperability.
>
>
>
> 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
> https://faculty.nps.edu/brutzman
>
>
>
> -----Original Message-----
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> Sent: Friday, June 9, 2023 4:46 PM
> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> Cc: Joseph D Williams <joedwil at earthlink.net>; X3D Graphics public
> mailing list <x3d-public at web3d.org>; puk at igraphics.com
> Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>
>
>
> I do not see any need to change the X3D spec here. For once, it is all
> correct in X3D spec :) And "Architecture and base components" is
> consistent with what "Classic VRML encoding" is saying, and both chapters
> of "Classic VRML encoding" ("4 Concepts" and "Annex A
>
> (normative) Grammar") are consistent.
>
>
>
> Joe's model should just be fixed, from what I can tell -- you have to move
> ROUTE outside of the [ ... ]. It makes sense that MFList [ ... ] should
> contain only nodes.
>
>
>
> From what I can tell,
>
>
> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html
>
> clearly says that ROUTE cannot be part of MFList [ ... ] , and that's OK.
> You have to place ROUTE within some node (or at top-level).
>
>
>
> Within MFList [ ... ] you can only have nodes (or USE of nodes). You
> cannot place ROUTE, EXPORT, IMPORT, PROTO... within MFList [ ... ] and
> that's OK, that's simple. Let's not break it :)
>
>
>
> Regards,
>
> Michalis
>
>
>
> sob., 10 cze 2023 o 01:30 Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> napisał(a):
>
> >
>
> > Thanks for precise response Michalis, very helpful.
>
> >
>
> > The intent for ROUTE is that it might appear within other nodes. The
> phrasing in X3D4 Architecture is quite explicit about this:
>
> >
>
> > X3D 4.0 Part 1: Architecture and base components, clause 4 Concepts,
>
> > 4.4.8.2 Routes
>
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.pr
>
> > oof/Part01/concepts.html#Routes Routes allows an author to
>
> > declaratively connect the output events of a node to input events of
> other nodes, providing a way to implement complex behaviors without
> imperative programming. When a routed output event is fired, the
> corresponding destination input event receives notification and can process
> a response to that change. This processing can change the state of the
> node, generate additional events, or change the structure of the scene
> graph. Routes may be created declaratively in an X3D file or
> programmatically via an SAI call.
>
> > Routes are not nodes. The ROUTE statement is a construct for
> establishing event paths between specified fields of nodes. ROUTE
> statements may either appear at the top level of an X3D file or inside a
> node wherever fields may appear. A ROUTE statement shall only appear after
> the definition of the source and destination nodes. Placing a ROUTE
> statement within a node does not associate it with that node in any way. A
> ROUTE statement does follow the name scoping rules as described in 4.4.7
> Run-time name scope.
>
> >
>
> > We expect that the prose and grammar in 19776-2/V3.3 Part 2: Classic
> VRML encoding to be reviewed and refined to match, when we get back to that
> document and upgrade it to X3D 4.0. I think that the current ClassicVRML
> spec indeed defers to the Architecture specification:
>
> >
>
> > X3D 3.3 Part 2: Classic VRML encoding, clause 4 Concepts, 4.3.2
>
> > Statements, 4.3.2.1 Organization of statements “Any number of ROUTE
> statements as specified in 4.4.8.2 Routes of ISO/IEC 19775-1.”
>
> >
>
> > So changes (corresponding to your accurate note) may need to be made to
>
> >
>
> > X3D 3.3 Part 2: Classic VRML encoding, Annex A (normative), Grammar
>
> > https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/gra
> mmar.html
>
> >
>
> >
>
> >
>
> > Wikipedia: Extended Backus–Naur form (EBNF)
>
> > https://en.wikipedia.org/wiki/Extended_Backus-Naur_form
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExtended_Backus-Naur_form&data=05%7C01%7Cbrutzman%40nps.edu%7C00493792347e4f819db008db69e92034%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638220222248610611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DcxsWZcLGeEt%2Fgglrmzr9yqc5s1dDJ9dXe4tpGXAc%2Bs%3D&reserved=0>
>
> >
>
> >
>
> > which includes the following EBNF production rules:
>
> >
>
> >
>
> >
>
> > node ::=
>
> >
>
> > nodeTypeId { nodeBody } |
>
> >
>
> > Script { scriptBody } |
>
> >
>
> > ComposedShader {composedShaderBody} |
>
> > PackagedShader {packagedShaderBody} |
>
> > ShaderProgram {shaderProgramBody} ;
>
> >
>
> > nodeBody ::=
>
> >
>
> > nodeBodyElement |
>
> >
>
> > nodeBodyElement nodeBody |
>
> >
>
> > empty ;
>
> >
>
> > nodeBodyElement ::=
>
> >
>
> > initializeOnlyId fieldValue |
>
> > inputOutputId fieldValue |
>
> >
>
> > initializeOnlyId IS initializeOnlyId |
>
> >
>
> > inputOnlyId IS inputOnlyId |
>
> >
>
> > outputOnlyId IS outputOnlyId |
>
> >
>
> > inputOutputId IS inputOutputId |
>
> >
>
> > routeStatement |
>
> >
>
> > protoStatement ;
>
> >
>
> > and
>
> >
>
> > routeStatement ::=
>
> >
>
> > ROUTE nodeNameId . outputOnlyId TO nodeNameId . inputOnlyId ;
>
> >
>
> >
>
> >
>
> > which, at first glance, looks OK to me from perspective of Joe’s
>
> > example (and many other examples)…
>
> >
>
> >
>
> >
>
> > Do you have modifications to suggest for the grammar?
>
> >
>
> >
>
> >
>
> > p.s. I tried to add a Mantis issue for long-term tracking but had
> trouble getting form to respond properly, will try again another time.
>
> >
>
> > Ensure ClassicVRML grammar matches X3D 4.0 Architecture Concepts and
> rules.
>
> > In particular, closely examine placement of ROUTE statements.
>
> >
>
> >
>
> >
>
> > 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
>
> > https://faculty.nps.edu/brutzman
>
> >
>
> >
>
> >
>
> > -----Original Message-----
>
> > From: Michalis Kamburelis <michalis.kambi at gmail.com>
>
> > Sent: Friday, June 9, 2023 2:11 PM
>
> > To: Joseph D Williams <joedwil at earthlink.net>
>
> > Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D Graphics
>
> > public mailing list <x3d-public at web3d.org>
>
> > Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > The ROUTE cannot go anywhere in the file, in particular you cannot place
> it inside an MFNode.
>
> >
>
> >
>
> >
>
> > https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/con
>
> > cepts.html
>
> >
>
> > : ROUTE is allowed at top-level and in node's body,
>
> >
>
> >
>
> >
>
> > """
>
> >
>
> > A node's body consists of any number of field statements, IS statements,
> ROUTE statements, PROTO statements or EXTERNPROTO statements, in any order.
>
> >
>
> > """
>
> >
>
> >
>
> >
>
> > The grammar confirms this precisely:
>
> >
>
> >
>
> >
>
> > https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/gra
>
> > mmar.html
>
> >
>
> > :
>
> >
>
> >
>
> >
>
> > - mfnodeValue is a sequence of nodeStatement
>
> >
>
> > - nodeStatement is only "USE ...", "DEF Xxx Node { }" or "Node { }"
>
> >
>
> > - only the more general "statement" allows ROUTE (and IMPORT, EXPORT,
> PROTO...). The "statement" is inside a node (but not in MFNode list).
>
> >
>
> >
>
> >
>
> > Regards,
>
> >
>
> > Michalis
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > pt., 9 cze 2023 o 22:37 Joseph D Williams <joedwil at earthlink.net>
> napisał(a):
>
> >
>
> > >
>
> >
>
> > > Hi All,
>
> >
>
> > >
>
> >
>
> > > My problem with view3dscene 4.3.0 is that it quits reading upon this
> sequence:
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > DEF StandAnimation Group {
>
> >
>
> > >
>
> >
>
> > > children [
>
> >
>
> > >
>
> >
>
> > > DEF StandTimer TimeSensor { … }
>
> >
>
> > >
>
> >
>
> > > DEF Stand_r_metatarsalPitch OrientationInterpolator {
>
> >
>
> > >
>
> >
>
> > > key [ … ]
>
> >
>
> > >
>
> >
>
> > > keyValue [ ... ]} ...
>
> >
>
> > >
>
> >
>
> > > ROUTE StandTimer.fraction_changed TO
>
> >
>
> > > Stand_r_ankleRotInterp.set_fraction
>
> >
>
> > >
>
> >
>
> > > ]}
>
> >
>
> > >
>
> >
>
> > > …
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > When it finds a ROUTE as child of Group. The error is:
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > VRML/X3D: Error when reading, will skip the rest of X3D file:
>
> >
>
> > >
>
> >
>
> > > Error at line 661 column 6:
>
> >
>
> > >
>
> >
>
> > > Expected node type or DEF or USE, got keyword "ROUTE"
>
> >
>
> > >
>
> >
>
> > > Making this construction required.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > DEF StandAnimation Group {
>
> >
>
> > >
>
> >
>
> > > children [
>
> >
>
> > >
>
> >
>
> > > DEF StandTimer TimeSensor { … }
>
> >
>
> > >
>
> >
>
> > > DEF Stand_r_metatarsalPitch OrientationInterpolator {
>
> >
>
> > >
>
> >
>
> > > key [ … ]
>
> >
>
> > >
>
> >
>
> > > keyValue [ ... ]} ...
>
> >
>
> > >
>
> >
>
> > > ]}
>
> >
>
> > >
>
> >
>
> > > ROUTE StandTimer.fraction_changed TO
>
> >
>
> > > Stand_r_ankleRotInterp.set_fraction
>
> >
>
> > >
>
> >
>
> > > …
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Moving the Route outside the Group.
>
> >
>
> > >
>
> >
>
> > > I think we went through the gram in detail here and found that placing
> the statement in this MF should be OK.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Thanks,
>
> >
>
> > >
>
> >
>
> > > Joe
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Clipped for mercy
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Joseph
>
> > > D
>
> >
>
> > > Williams
>
> >
>
> > > Sent: Friday, June 9, 2023 10:29 AM
>
> >
>
> > > To: X3D Graphics public mailing list <x3d-public at web3d.org>
>
> >
>
> > > Subject: [x3d-public] Problem in x3dviewscene: ROUTE placement
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Error in viewX3dScene processing
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > VRML/X3D: Error when reading, will skip the rest of X3D file: Error at
> line 661 column 6: Expected node type or DEF or USE, got keyword "ROUTE"
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > I was hoping we could fix this player problem since we determined that
> a ROUTE statement can go anywhere in the file.
>
> >
>
> > >
>
> >
>
> > > Thanks,
>
> >
>
> > >
>
> >
>
> > > Joe
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230611/c831e854/attachment-0001.html>
More information about the x3d-public
mailing list