[x3d-public] HAnim, v1 -> v2

[John Carlson]

Joe, perhaps you’ve seen the WIP “LOA4” on the other thread.

Below describes templates in sed for replacing v1 to v2 conversion.
On Thu, Jan 5, 2023 at 11:34 PM John Carlson <yottzumm at gmail.com> wrote:

>
>
> On Thu, Jan 5, 2023 at 8:54 PM Joseph D Williams <joedwil at earthlink.net>
> wrote:
>
>>
>>    - While I tried to find an issue with the VRML grammar, and i had
>>    several misperceptions, and on review, i didn’t find any problems that just
>>    “popped out.”
>>
>>
>>
>> John, Good, that is Good, that is Very Good.
>>
>
> I hope so!  My lack of knowledge surrounding. VRML is great.   I have not
> worked a great deal with VRML, so i am using my meager XML and JSON skills,
> hoping at some point to start a VRML project.
>
>>
>>
>>    - Your thoughts?  I know everyone (besides me) is busy.
>>
>>
>>
>> I just need a simple thing to change V1 names to v2 names, get some
>> dimensions  and complete the Part 1 Annex A LOA4.
>>
>
$ sed -e ‘s/v1—-pattern-1/v2—replacement-1/g’ \
-e ‘s/v1—-pattern-2/v2—replacement-2/g’ \
…

Basically above, on each row, replace thing between first two slashes (v1
name) with what appears   between the second two slashes (v2 name), and
send me script and what you want me to substitute v1 to   v2 (script
described above).

It’s also acceptable to send the rows as CSV, and I’ll return the script.

I apologize for dropping the ball so many times.

You may need to install WSL or Git Bash on windows.  I can run the script
though, if you need me to.  So skip that.

If the replacement is more complicated, describe.

Thanks!

John

>
> Joe,
>
> I’m concerned that if I accomplish such tools/scenes that they won’t get
> to you.  I need to revamp or create a repository.  I’m not sure i can
> duplicate the “LOA4” that was previously sent, but i can try looking
> through my emails.  It was the one with the partially attached hands,
> hoping you could provide any joints or segments necessary.   I will search
> for To:joe.
>
> Brb, searching through email.
>
> I’m not really wanting to enlist my wife, and I’m already in the doghouse
> for previous emails.   I do not have a standard body to get dimensions
> from, I’m 6’8”. But perhaps that’s 2 meters, 1 meter above root?  Am I
> “standard”?  Lol
>
> Maybe someday, i can look at some VRML and claim, ”They took my hands!”
>
>> Joe
>>
>>
>>
>>
>>
>> *From: *John Carlson <yottzumm at gmail.com>
>> *Sent: *Thursday, January 5, 2023 3:45 PM
>> *To: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> *Cc: *Joseph D Williams <joedwil at earthlink.net>; Michalis Kamburelis
>> <michalis.kambi at gmail.com>; Patrick Dähne <pdaehne at gmail.com>; X3D
>> Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org>
>> *Subject: *VRML grammar generator. Was: Re: [x3d-public] [...] HAnim2
>> X3D4BoxMan update: does ClassicVRML Grammar allows ROUTE in children?
>>
>>
>>
>> While I tried to find an issue with the VRML grammar, and i had several
>> misperceptions, and on review, i didn’t find any problems that just “popped
>> out.”   Perhaps my dry eyes have worsened.
>>
>>
>>
>> Perhaps we should provide generation of VRML grammar from X3DUOM, if not
>> done already?  We can have thousands of checks of examples against VRML
>> grammar, as you have said.   I have not kept track of VRML “stuff.”
>>
>>
>>
>> Your thoughts?  I know everyone (besides me) is busy.
>>
>>
>>
>> I can even try to accomplish myself with existing grammar and X3DUOM.   I
>> can try with writing Xslt first, and if that’s too burdensome, possibly
>> start from the JSON schema generator and branch out.
>>
>>
>>
>> Trying to make this as easy for someone to do as possible, can we make
>> the right implementation choice?   What limitations?  Declarative
>> implementations seem important.
>>
>>
>>
>> I agree that supporting one-offs in X3D Validator is useful and we
>> probably don’t want to support batch web-based validation at this time.
>>
>>
>>
>> I have also researched “schema from example” and “grammar from example.”
>>   It might be worth applying new AI research to this problem with the right
>> prompt.
>>
>>
>>
>> Maybe i should apply AI to the JSON schema.  Hmm!
>>
>>
>>
>> John
>>
>>
>>
>> On Thu, Jan 5, 2023 at 11:01 AM Brutzman, Donald (Don) (CIV) <
>> brutzman at nps.edu> wrote:
>>
>> Patrick, thanks for these important insights.
>>
>>
>>
>> Am looking closely and tracing the grammar.  As you know, such grammars
>> are very important because they formally and unambiguously describe what is
>> allowed.  Also pretty tricky to follow!
>>
>>
>>
>>    - Extensible 3D (X3D) encodings, Part 2: Classic VRML encoding Annex
>>    A (normative), Grammar
>>    -
>>    https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html
>>
>>
>>
>> Am finding following excerpts of interest.  Hopefully addition of
>> color-coding helps:
>>
>>
>>
>>    1. *node *::=
>>
>>   nodeTypeId { *nodeBody* } |
>>
>>   Script { scriptBody } |
>>
>>   ComposedShader {composedShaderBody} |
>>
>>   PackagedShader {packagedShaderBody} |
>>
>>   ShaderProgram {shaderProgramBody} ;
>>
>>    1. *nodeBody *::=
>>
>>   *nodeBodyElement* |
>>
>>   *nodeBodyElement* *nodeBody* |
>>
>>   empty ;
>>
>>
>>
>>    1. mfnodeValue ::=
>>
>>    *nodeStatement *|
>>
>>    [ ] |
>>
>>    [ nodeStatements ] ;
>>
>>
>>
>>    1. nodeStatements ::=
>>
>>   *nodeStatement* |
>>
>>   *nodeStatement* nodeStatements ;
>>
>>
>>
>>    1. *nodeStatement*::=
>>
>>   *node* |
>>
>>   DEF nodeNameId *node* |
>>
>>   USE nodeNameId ;
>>
>>
>>
>>    1. *nodeBodyElement *::=
>>
>>   initializeOnlyId fieldValue |
>>
>>   inputOutputId fieldValue |
>>
>>   initializeOnlyId IS initializeOnlyId |
>>
>>   inputOnlyId IS inputOnlyId |
>>
>>   outputOnlyId IS outputOnlyId |
>>
>>   inputOutputId IS inputOutputId |
>>
>>   routeStatement |
>>
>>   protoStatement ;
>>
>>
>>
>>    1. routeStatement ::=
>>
>>   *ROUTE* nodeNameId . outputOnlyId TO nodeNameId . inputOnlyId ;
>>
>>
>>
>>    1. *statement* ::=
>>
>>   *nodeStatement* |
>>
>>   importStatement |
>>
>>   exportStatement |
>>
>>   protoStatement |
>>
>>   routeStatement ;
>>
>>
>>
>>    1. sfnodeValue ::=
>>
>>   *nodeStatement *|
>>
>>   NULL ;
>>
>>
>>
>>
>>
>> So it looks like there are several chains of interest as follows:
>>
>>
>>
>>    1. mfnodeValue > nodeStatements > *nodeStatement* > *node *>
>>    nodeTypeId {* nodeBody* } > *nodeBodyElement* > routeStatement >
>>    *ROUTE*
>>
>>
>>
>>    1. sfnodeValue > *nodeStatement > *(etc. as shown immediately above
>>    in chain 1)
>>
>>
>>
>>    1. *statement* > routeStatement > *ROUTE*
>>
>>
>>
>> From these three chains in ClassicVRML grammar, it appears logical to
>> conclude that *ROUTE* is allowed to appear wherever an MFNode, SFNode or
>> statement is allowed to appear.
>>
>>
>>
>> That would be a consistent match with the parent-child relationships
>> defined in X3D XML Schema and DTD.
>>
>>
>>
>> Hopefully I have the chain of logic correct here.  All scrutiny and
>> review is welcome, we definitely need to get this right.
>>
>>
>>
>> If there is any unintended omission in the Backus-Naur logic here, then
>> great!  We can agree now on corrections, and fix any issues in this year’s
>> expected update of the ClassicVRML encoding from X3D3 to X3D4.  Correction
>> of converters can also proceed immediately upon achieving consensus.
>>
>>
>>
>>    - Wikipedia:  Backus-Naur form
>>    - https://en.wikipedia.org/wiki/Backus-Naur_form
>>
>>
>>
>> Again thanks for careful strictness, careful checking of model content is
>> one of our greatest strengths.
>>
>>
>>
>> Have fun with ClassicVRML X3D!  8)
>>
>>
>>
>> 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: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Patrick
>> Dähne
>> Sent: Thursday, January 5, 2023 3:05 AM
>> To: Joseph D Williams <joedwil at earthlink.net>
>> Cc: X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org>
>> Subject: Re: [x3d-public] [...] HAnim2 X3D4 BoxMan update
>>
>>
>>
>>
>>
>> > Am 05.01.2023 um 03:33 schrieb Joseph D Williams <joedwil at earthlink.net
>> >:
>>
>> >
>>
>> >             • Classic VRML does not allow to declare ROUTEs inside
>> MFNode fields. Move them outside.
>>
>> >
>>
>> > There may be other x3d Statements and some rules, but I don’t see any
>> spec language for what you describe regarding ROUTE.
>>
>>
>>
>> The (only) relevant part of the „Classic VRML encoding“ spec is „Annex A:
>> Grammar“:
>>
>>
>>
>> https://www.web3d.org/documents/specifications/19776-2/V3.3/index.html
>>
>>
>>
>> The grammar is written in Backus-Naur form. It is the „Scheme“ of classic
>> encoding. Have a look at the rule „mfnodeValue“. You won’t find the symbol
>> „routeStatement“ on the right hand side of that rule.
>>
>>
>>
>> ROUTEs are only allowed:
>>
>>
>>
>> 1. At the top level of the scene
>>
>> 2. Inside the node body (between fields)
>>
>>
>>
>> In my opinion it does not make much sense to forbid ROUTEs inside MFNode
>> fields, and I am actually surprised that someone implemented it such
>> strictly.
>>
>>
>>
>> Bye,
>>
>>
>>
>> Patrick
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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/20230106/5e91d589/attachment-0001.html>