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