[x3d-public] Problem in x3dviewscene: ROUTE placement
John Carlson
yottzumm at gmail.com
Mon Jun 12 13:52:47 PDT 2023
You’re way ahead of me on NetBeans Don. Carpal tunnel is still flaring, of
course it’s been flaring since the 80’s or 90’s
I guess I’ll have to get surgery if things get bad, and build a wicked 3D
world with ChatGPT.
John
On Mon, Jun 12, 2023 at 3:45 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> Joe: your second style of construct worked for me in view3dscene yesterday
> – I launched it to view the .x3d scene using X3D-Edit. So it looks like
> view3dscene does not forbid the XML syntax, but rather is stricter with the
> ClassicVRML syntax, which matches what he told us yesterday.
>
>
>
> If there is a problem in the X3dToClassicVRML.xslt stylesheet conversion,
> I can fix that. However won’t ever be pushing all the ROUTEs to the end or
> another location in the scene.
>
>
>
> NetBeans came out with NetBeans v18 yesterday, will be testing our
> X3D-Edit plugin with that soon.
>
>
>
> 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:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *Joseph D
> Williams
> *Sent:* Monday, June 12, 2023 12:36 PM
> *To:* GPU Group <gpugroup at gmail.com>; X3D-Public <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>
>
>
>
>
>
>
> No, not tool-generated code. This has run like I show with all available
> players for 15 or more years without the need to fix.
>
> Found this problem in view3dscene when I began to use it when skin started
> working; looking forward to displacer.
>
>
>
> Interesting enough for view3dscene, the sequences:
>
>
>
> Group {
>
> Children [
>
> Node { … ]
>
> ]
>
> ROUTE …
>
> }
>
>
>
> And
>
>
>
> Group {
>
> Children [
>
> Node { … ]
>
> ] }
>
> ROUTE …
>
>
>
> Are both ok by view3dscene.
>
>
>
> Just does not like:
>
>
>
> Group {
>
> Children [
>
> Node { … }
>
> ROUTE …
>
> ] }
>
>
>
> Thanks,
>
> Joe
>
>
>
>
>
>
>
> *From: *GPU Group <gpugroup at gmail.com>
> *Sent: *Monday, June 12, 2023 12:12 PM
> *To: *X3D-Public <x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
>
>
>
> ROUTES apply in a context: Scene/ProtoBody. If you were developing an
> authoring tool, and you read in a scene with ROUTEs anywhere in the
> context, you'll be scraping the ROUTES out of anywhere and putting them in
> a context-specific routes list. Then when you write out the scene, at the
> end of the context you'll spit out the list of ROUTEs.
>
> So there's no reason not to put ROUTES at the root level of the context.
> Except if you are re-DEFing (using the same DEF name multiple times down
> the scenegraph, thereby re-defining what the DEF name refers to) then you
> would want the ROUTEs close / just after the DEF is applied to the node you
> want to ROUTE to/from. I think.
>
>
>
> On Mon, Jun 12, 2023 at 1:00 PM GPU Group <gpugroup at gmail.com> wrote:
>
> FreeWRL - OK (Scene root node list is a node list, as is proto root node
> list, and in general node lists OK placement for ROUTEs in classic file for
> freeWRL. Parser scrapes them out of MFlist so they don't show in the MFNode
> list in scenegraph)
>
> InstantPlayer - OK
>
> Octaga - OK
>
> H3D - syntax error, unexpected ROUTE, expecting identifier or SCRIPT or
> DEF or USE
>
> WDune - syntax error
>
>
>
>
>
>
>
> On Mon, Jun 12, 2023 at 12:08 PM Vincent Marchetti <vmarchetti at kshell.com>
> wrote:
>
> My understanding of these results is:
>
> > On Jun 12, 2023, at 1:41 PM, Joseph D Williams <joedwil at earthlink.net>
> wrote:
> >
> > No, not tool-generated code. This has run like I show with all available
> players for 15 or more years without the need to fix.
> > Found this problem in view3dscene when I began to use it when skin
> started working; looking forward to displacer.
> >
> > Interesting enough, the sequences:
> >
> > Group {
> > Children [
> > Node { … ]
> > ]
> > ROUTE …
> > }
>
> In this case, the ROUTE statement is in the body of the Group node,
> alongside the fields of the Group node, as clearly allowed by
> the Architecture specification and the ClassicVRML grammar.
>
>
>
>
> > And
> >
> > Group {
> > Children [
> > Node { … ]
> > ] }
> > ROUTE …
>
> In this case, the ROUTE statement is at the root level of the Scene,
> alongside the Group node, as allowed by
> the Architecture specification and the ClassicVRML grammar.
>
>
>
> > Are both ok by view3dscene.
> >
> > Just does not like:
> >
> > Group {
> > Children [
> > Node { … ]
> > ROUTE …
> > ] }
>
> In this case the ROUTE statement appears as one item in the MFNode-typed
> Children field. The validity of this has been under discussion in this
> thread. I believe the Architecture prose is ambiguous at best, but that
> this is forbidden by the ClassciVRML formal grammar.
>
> It appears to me that other implementors of the ClassicVRML reading chose
> to accept the invalid placement of the ROUTE statement. I can't speak for
> Michalis' intentions, but the view3dscene ClassicVRML import does reject
> what I judge to be invalid syntax.
>
> Vince Marchetti
>
>
>
> > Thanks,
> > Joe
> >
> >
> >
> >
> >
> > From: Vincent Marchetti
> > Sent: Monday, June 12, 2023 6:55 AM
> > To: X3D-Public
> > Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
> >
> > Thank you for identifying the relevant seection of the X3D V4
> Architecture. The relevant sentence from section 4.4.8.2 is:
> >
> > ROUTE statements may either appear at the top level of an X3D file or
> inside a node wherever fields may appear.
> >
> > It declares the intent of allowing a ROUTE statement inside a node
> definition in close proximity to a field that the ROUTE modifies, for
> purpose of readability, but other than that purpose this placement of the
> ROUTE statement does not change the semantics of a ROUTE statement. I
> don't think this sentence bears being taken literally to an extreme;
> otherwise we are obligated to define a additional XML encoding of the ROUTE
> statement which allows the ROUTE statement to be included as an XML
> attribute; so that, for example, it can be placed adjacent to the XML
> encoding of the SFVec3f "translation" field of the Transform element. I am
> not trying to argue by exaggeration;t I am argujng that the sentence need
> to be interpreted in accordance with the syntax of a specific encoding.
> >
> > The ClassicVRML encoding does allow a ROUTE to be defined in the body of
> a X3D node; the specific issue we are discussing is whether this includes
> placing the ROUTE definition inside the ClassicVRML encoding of an MFNode
> value. We could have a continued discussion about whether inclusion as an
> item in a MFNode value is included in the text phrase "..wherever fields
> may appear", but we can also refer to the formal grammar definition of the
> ClassicVRML appendix which, in my judgement, does not allow that.
> >
> > Taking a step back, and asuming that the JoeLevel2LOA3SSPYRWRJKHud.x3dv
> example was generated by a tool; we have one tool that generates an x3dv
> file which does not conform to the ClassicVRML formal geometry published in
> X3D V3.3 . If I understand Don's email report of June 9, the X3D conversion
> of the x3dv file passed validation, but this was not direct validation of
> the original x3dv file. So I see the validation situation as:
> >
> > 1) The view3dscene code identifies the ClassicVRML error in
> JoeLevel2LOA3SSPYRWRJKHud.x3dv when asked to render it,'
> > 2) The conversion code, from x3dv -> x3d, offered by view3dscene, does
> not flag an error in JoeLevel2LOA3SSPYRWRJKHud.x3dv but does generate a
> valid x3d scene from it,
> >
> > In the example archives, we have not yet identified a ClassicVRML
> encoding that includes this very specific feature, a ROUTE statement
> included within an MFNode value of an X3D field, so it is not yet possible
> to use our example archive for guidance.
> >
> > I think these considerations make it premature to change the ClassicVRML
> grammar definition in the standard.
> >
> > Vince Marchetti
> >
> >
> >
> > > On Jun 12, 2023, at 1:36 AM, Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
> > >
> > > • Sorry to be unclear, that was not the relevant reference,
> rather the prior email in the thread.
> > >
> > > My mail of 9 June 16:30:04 PDT 2023 holds the relevant reference.
> Excerpt follows, quoting a quote, and have provided yellow highlights to
> key phrasing this time.
> > >
> > >
> > > • [x3d-public] Problem in x3dviewscene: ROUTE placement
> > > •
> http://web3d.org/pipermail/x3d-public_web3d.org/2023-June/018836.html
> > >
> > > 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.proof/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.
> > >
> > >
> > > • I next took the offered example scene
> > > •
> https://www.web3d.org/x3d/content/examples/Vrml2Sourcebook/Chapter08AnimatingPositionOrientationScale/Figure08_3PositionInterpolator.x3d
> > >
> > > and moved entire scene graph within Scene inside a Group, i.e.
> > > • <Scene><Group><!—everything including ROUTE statements
> --></Group></Scene>
> > > • Thus nothing remains in top-level MFNode list of the
> scene, except for single parent Group
> > >
> > > Then tested the modified example.
> > > • All validation tests passed.
> > > • Xj3D worked.
> > > • X3DOM worked.
> > > • After 10 minutes of reporting to Microsoft that
> view3dscene was legitimate, and coercing Windows 10 to accept it,
> view3dscene.exe worked on this modified example too.
> > > • Searching for “<ROUTE” found 4989 matches in first 500
> scenes searched (out of 4060 total archived scenes) so no doubt there are
> more.
> > >
> > > • To my prior list of benefits for flexible placement of
> ROUTE statements, here is another:
> > > • Simplifies author and tool addition of code-block
> patterns and templates within a scene (this a feature used numerous times
> as an optional authoring assist for event tracing by X3D-Edit, likely to be
> added as utility features in X3DJSAIL and X3DPSAIL someday as well.)
> > > Specifically, from X3D-Edit documentation,
> > > • Trace capabilities are available for ROUTE, sensors,
> interpolators and other nodes that produce or consume events. Trace output
> results are logged on the browser console to show the timing and values
> passed events. When the Trace checkbox is selected by the author, a Script
> node is inserted immediately after the node to accomplish this task. This
> is a useful debugging technique.
> > > •
> https://savage.nps.edu/X3D-Edit/images/TraceFeatureReportsRoutedEventValuesOnBrowserConsoleViaScriptOutput.png
> > > •
> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07-EventAnimationInterpolation/Chapter07-EventAnimationInterpolation-EventTracing.pdf
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter07-EventAnimationInterpolation%2FChapter07-EventAnimationInterpolation-EventTracing.pdf&data=05%7C01%7Cbrutzman%40nps.edu%7Ce0198912c78d41ded35b08db6b7c6f44%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638221954925283752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=3t4W81HuNGGYCxyFJ3OOUGfCkItrtYSI%2BcUkgE1CuhA%3D&reserved=0>
> > >
> > > • “Consistency across all file encodings and language
> bindings is possible.” This is our basic design principle for separation of
> functionality in X3D architecture from implementation details in all
> related specifications.
> > >
> > > We have immense interoperability already. As promised many times, we
> will smooth out any mismatches in future X3D 4.0 file encodings and
> language bindings. Test cases do help too. So stand by for action.
> > >
> > > Hopefully the highlighted specification requirement, the ease of
> creating flexible test cases, and the value of this existing specification
> capability is presented more clearly now.
> > >
> > > Careful consideration, implementation efforts, and consensus-based
> progress are always appreciated.
> > >
> > > Having fun with X3D… I hope that others are too.
> > >
> > > 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: vmarchetti at kshell.com <vmarchetti at kshell.com>
> > > Sent: Sunday, June 11, 2023 4:42 PM
> > > To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D-Public <
> x3d-public at web3d.org>
> > > Cc: Michalis Kamburelis <michalis.kambi at gmail.com>
> > > Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement
> > >
> > >
> > > On Jun 11, 2023, at 5:09 PM, Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
> > >
> > > Not trying to invent anything here, rather point out what is specified
> (and also common practice). I already gave the relevant links in the X3D
> 4.0 Architecture governing what is required.
> > >
> > > I do not see this requirement given or even implied in the link you
> specified:
> > > •
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/fieldTypes.html
> > >
> > > is a comprehensive listing of the X3D Field types, with details on
> SFNode and MFNode therein, and on this page I don't see any mention of the
> ROUTE statement nor does a text search on that page discover even the terms
> "route" or "statement" in isolation.
> > >
> > > ...
> > >
> > >
> > > Consistency across all file encodings and language bindings is
> possible.
> > > I don't this this statement is true, or to the extent that it is true,
> then long - ago X3D design decisions did not treat it as of primary
> importance. As Michalis pointed out, in the ClassicVRML encoding the zero
> or more items in a single MFNode value are syntactically enclosed in square
> brackets. Moreover, in the ClassicVRML encoding all the field values are
> explicitly identified with the name of the field. However, in the X3D
> encoding the XML child elements are in most cases identified as belonging
> to an X3D field through the node type-inheritance classification; and in
> the few cases where that is not possible an explicit "containerField" XML
> attribute is used. To make the X3D encoding consistent with ClassicVRML
> would entail the use of wrapper XML elements around the element encoding of
> one node-element for an SFNode value, or the several nodes of MFNode.
> However, the design decision was made long ago not to use wrapper elements
> in the XML encoding ( see
> https://www.web3d.org/x3d/content/examples/Basic/development/WrapperTagsConsideredHarmful.html
> )
> > >
> > > My point is that the consistency among encodings is a useful criteria
> but should not automatically take precedence over other considerations. One
> such consideration is maintainging stability of our formal ClassicVRML
> grammar.
> > >
> > > And I think there is little additional benefit in changing the the
> ClassicVRML to allow ROUTE inside MFNode encodings. Doing so does allow a
> ROUTE to be placed adjacent to a node whose fields it modifies and you
> (Don) have pointed out the readability benefits that offers -- but Michalis
> points out that the ClassicVRML already allows that ROUTE statement to be
> placed inside the body of a node it modifies, even closer!
> > >
> > > Vince Marchetti
> >
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> _______________________________________________
> 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/20230612/64e14236/attachment-0001.html>
More information about the x3d-public
mailing list