[x3d-public] Problem in x3dviewscene: ROUTE placement
John Carlson
yottzumm at gmail.com
Sat Jun 10 12:41:48 PDT 2023
the Java and JavaScript validators check out okay. I will now start
debugging the online validator.
Here are the offline validators.
GitHub - coderextreme/x3dvalidate: Validate JSON files against various
versions of X3D JSON schema with Ajv
<https://github.com/coderextreme/x3dvalidate>
GitHub - coderextreme/x3dschema: X3D Schema work (JSON)
<https://github.com/coderextreme/x3dschema>
On Sat, Jun 10, 2023 at 2:30 PM John Carlson <yottzumm at gmail.com> wrote:
> 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/0eecfe01/attachment-0001.html>
More information about the x3d-public
mailing list