[x3d-public] Problem in x3dviewscene: ROUTE placement
John Carlson
yottzumm at gmail.com
Sat Jun 10 12:30:06 PDT 2023
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%7C00db1b0e43bf45f74e9b08db69e07595%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638220185033281771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7WB1UD%2BKA76sWVHgZGKmKzv76f%2BIUr6Rof%2FC%2BvLENfY%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/20230610/852479a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: X3dHeaderPrototypeSyntaxExamples.x3d
Type: model/x3d+xml
Size: 6402 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230610/852479a9/attachment-0001.x3d>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: X3dHeaderPrototypeSyntaxExamples.json
Type: application/json
Size: 13986 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230610/852479a9/attachment-0001.json>
More information about the x3d-public
mailing list