[x3d-public] Problem in x3dviewscene: ROUTE placement
John Carlson
yottzumm at gmail.com
Sat Jun 10 12:14:51 PDT 2023
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/cb38fadc/attachment-0001.html>
More information about the x3d-public
mailing list