[x3d-public] What is "loa" ?

Wed Jun 24 17:05:01 PDT 2020

➢ In freewrl, the Motion nodes -including HAnimMotion and (MotionPlay + MotionClip) don't need the DEF names  Just the joint name="l_shoulder" names.

OK, so for timer/interpolator/route animations, the author needs to know the DEF names but in your under the covers Motion node implementation, you don’t care. So you use the Joint name field to make a connection?
Then the names in the Humanoid joints field is really of no value to the Motion node?
Joe

From: GPU Group
Sent: Wednesday, June 24, 2020 3:19 PM
To: Joseph D Williams
Cc: John Carlson; Don Brutzman; X3D Graphics public mailing list
Subject: Re: [x3d-public] What is "loa" ?

In freewrl DEF/USE is just for the parser, for when you want to ROUTE or re-USE a node. Once its parsed we don't refer to those DEF names in HAnim. 
In freewrl, the Motion nodes -including HAnimMotion and (MotionPlay + MotionClip) don't need the DEF names  Just the joint name="l_shoulder" names.
-Doug

On Wed, Jun 24, 2020 at 4:03 PM Joseph D Williams <joedwil at earthlink.net> wrote:
• Can we change the USE reference node to SFString instead of SFNode?

That does nothing but mess up USE even more. 
The main idea is that the USE statements refer to the DEF name which does not match the joint names in the Motion node. Am I wrong about this? The DEF names are different from the name field  in the Joint. Sooner or later the Motion animation stuff has to know both. So what to do? 
It is obvious that the Motion node needs to know the Joint name first, to see if there are matches, then needs to find the DEF names to run the animation. What to do? I didn’t like or see the need for the Humanoid joints, segments, and sites fields because if xml, then it is easy to use DOM interfaces to find out the list of Joint nodes and give both the DEF name and the name name.
Joe

From: John Carlson
Sent: Wednesday, June 24, 2020 1:23 PM
To: Joseph D Williams
Cc: Don Brutzman; GPU Group; X3D Graphics public mailing list
Subject: Re: [x3d-public] What is "loa" ?

Can we change the USE reference node to SFString instead of SFNode?

On Wed, Jun 24, 2020 at 3:15 PM Joseph D Williams <joedwil at earthlink.net> wrote:
Also if not too late, which it definitely should not be, Please change the Humanoid joints, segments, and sites fields to hold an MFString “string’ ‘string’…” style that includes all Joint names, Segment names, and Site names. This aligns with the needs of the Humanoid Motion node that needs the actual names, not the DEFs. 
Including these in a USE instance is confusing because the DEF actually needs to be ignored by the hanim browser as far as rendering in concerned, and does not align with the needs of the Humanoid Motion node because that node needs the actual Joint names, not the actual Joint animation interface DEF names. 

As I said, I think I finally can agree with including those Humanoid fields if they actually serve a purpose. That purpose is to deliver sets of actual names that can be used by the Humanoid Motion node. 
Or, not a favorite of mine, the Humanoid Motion node should be changed to specify the Joint DEF names, which whatever is under the covers would have to discover anyway. 

Thanks and Best, 
Joe

From: GPU Group
Sent: Wednesday, June 24, 2020 8:57 AM
To: Don Brutzman; Joseph D Williams
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] What is "loa" ?

Don - if not too late for v4, facilitation and.or next steps requested for following topic:
v4 HAnimMotion > MF field types in (web3d supplemental) MotionClip node 
Thanks,
-Doug Sanden
more..
There may be a consensus forming around the idea of the extra nodes - MotionPlay and MotionClip - having MF fields for channels, joints (and values).. The 2 extra nodes aren't needed for full compliance to HAnim2 - they are supplemental - and so don't need to strictly comply. with field syntax.
1) HAnimMotion as specified in HANim2 with SF fields for channels, joints and values
-- complies with HAnim2 specs fully
2) HAnimMotionPlay + HAnimMotionClip extra / supplemental nodes
- MotionClip could have MF fields for channels, joints and values to assist authoring tool support
- (in theory could have both SF and MF under different names if needed for abstract node inheritance ie parsedChannels MFString?)
- and url field for loading .bvh files
-- an SFNode nameMap field will help with some bvh use cases

Related to

http://dug9.users.sourceforge.net/web3d/tests/hanim/web3d/HAnim_Motion.pdf

Mantis (resolved): 0001312: Mismatched type defaults defined for HAnimMotion channels field in X3D4 

On Tue, Jun 23, 2020 at 9:36 PM Joseph D Williams <joedwil at earthlink.net> wrote:
Basically, me like very much
Joe

From: GPU Group
Sent: Monday, June 22, 2020 5:07 PM
To: Joseph D Williams
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] What is "loa" ?

But I think there's room for both methods. 
- the Motion node probably needs to conform to HAnim 2.0 specifications already registered with (whatever body - is it ISO?).
- a few more non-hanim-standard nodes could be considered 
- I proposed a few - HAnimMotionPaly + HAnimMotionData/HAnimMotionDataFile 
-- Don suggested merging HAnimMotionData and DataFile. I suggested HAnimMotionClip for the name
- HAnimMotionClip has the 3 data fields from Motion. But when loading from url/,.bvh file, it doesn't populate those fields. Just uses them like HAnimMotion when no url given.
So one way to make more of us happy:
- keep the HAnimMotion node as defined for HAnim 2,0 specs
- Do the MotionPlay + MotionClip additional nodes
-- put a url field tor Doug (and the freewrlians who like the option to play with freely downloaded .bvh mocap files)
-- put MF fields for Joe who likes style sheet conversions and authoring tool workflows
How does that sound?
-Doug

On Mon, Jun 22, 2020 at 5:40 PM GPU Group <gpugroup at gmail.com> wrote:
I can type in an image pixel by pixel into an MF field. Its more convenient to give a url to an image file.
Same with .bvh.
-Doug 

On Mon, Jun 22, 2020 at 5:34 PM Joseph D Williams <joedwil at earthlink.net> wrote:
• Or - have web3d browsers load .bvh directly, via a mapping / lookup node / field./ table which you would likely also need for import tools.

As discussed in another thread mainly about actually importing a complete bvh file, that is a legacy style that has the ‘official’ playback  skeleton is hidden (hanim V1 and x3d  exposed it using the Humanoid skeleton field) and the ‘user’ just imports his custom bvh file that is already matched to the internal hidden playback skeleton and then it gets executed and user gets some results. Maybe a video, even. Definitely not designed for realtime interactions. 

As is seen using Motion node, this style looks easy at first, then gets hard when you actually want to take control by editing the motion data, or to load another data set, or to update the ‘standard’ playback skeleton or imported capture skeleton. 

x3d hanim gets away from this legacy owner/user model by exposing the playback skeleton and the animation structures directly to the author. And, by using a coding scheme where animations do not need to be a part of the Humanoid user code we are more happy. 
Thanks, 
Joe

From: Joseph D Williams
Sent: Monday, June 22, 2020 3:49 PM
To: GPU Group; X3D Graphics public mailing list
Subject: Re: [x3d-public] What is "loa" ?

• If so, then -as we get further from copy and pasta-ability- there may be some demand for tools to import .bvh and convert to these x3d MF fields.

Right, I think the best idea would be to have a simple tool take the bvh file and turn it into xml of gltf style that can be validated and reformatted for editing. And, unless we want to treat strings like mf numbers, strings need delimiting quotes. 
Thanks for the hanim thoughts.
Joe

From: GPU Group
Sent: Saturday, June 20, 2020 1:23 PM
To: X3D Graphics public mailing list
Subject: Re: [x3d-public] What is "loa" ?

Hypothesis: the hanim motion fields were originally designed to make it easy to copy and paste from freely available motion capture .bvh files.
If so, then -as we get further from copy and pasta-ability- there may be some demand for tools to import .bvh and convert to these x3d MF fields.
Or - have web3d browsers load .bvh directly, via a mapping / lookup node / field./ table which you would likely also need for import tools.
-Doug

On Sat, Jun 20, 2020 at 12:38 PM GPU Group <gpugroup at gmail.com> wrote:
https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/ExampleMocapAnimationMotionObject.html 
This version of AnnexD is what I used - and it looks like an SFString 0 as does values and jpints
WARNING - any examples from this AnnexD may need rework for web3d 
-Doug

On Sat, Jun 20, 2020 at 12:21 PM Don Brutzman <brutzman at nps.edu> wrote:
MUFTI you definitely want to be looking at the HAnim2 specifications.

Web3D Consortium members are the controlling authority for X3D and HAnim specifications, International Standards Organization (ISO) certifies.

X3D3 is simply implementing HAnim2, typically as tersely as possible so that there is no confusion in prose that HAnim2 is the controlling specification.  Please see

* ISO/IEC 19774-1, HAnim2 Specifications parts 1 and 2
   https://www.web3d.org/documents/specifications/19774/V2.0/

===============================================
* ISO/IEC 19774-1, HAnim2 Specifications part 1
   clause 3 Terms and definitions
   https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/glossary.html

3.11
   level of articulation
   LOA
   degree of fidelity based on number of joints in an HAnim figure
===============================================

also

* 4.8.5 Levels of articulation
   https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#LevelsOfArticulation

"Level of articulation (LOA) represents the complexity and detail of joints for a humanoid skeletal hierarchy, and can be used for generating various motions based on the joints. There are five levels of articulation:

     LOA
0 represents only the humanoid_root Joint object without an accompanying hierarchy, as shown in (Figure 4.3).
     LOA
1 represents the simplest organization and hierarchy of joints for a humanoid. There are 18 joints and 18 segments. Each segment has a joint in the hierarchy. Figure 4.4 represents LOA
1 joints.
     LOA
2 consists of 71 joints and 71 segments (Figure 4.5).
     LOA
3 consists of 94 joints and 94 segments (Figure 4.6).
     LOA
4 builds on LOA
3 by adding anatomical details of hands and feet (Figure 4.7). LOA
4 consists of 148 joints and 148 segments. Hands and feet joints for LOA
4 are illustrated in 4.9.3 and 4.9.4 respectively."

* 4.9 Structure of a humanoid, 4.9.6 Hierarchy
   https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#Hierarchy

* 4.9 Structure of a humanoid
   https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html

* Annex A (informative) Nominal human body dimensions and levels of articulation (LOAs)
   Nominal human body dimensions and levels of articulation (LOAs)

* A.2 Levels of articulation (LOAs)
   https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/BodyDimensionsAndLOAs.html#LevelsOfArticulation

There is a lot of information in there that deserves careful reading.  You will find tables and diagrams that illustrate every joint and (bone) segment in the human body, along with a number of useful feature-point sites.  This took years of effort by many members of HAnim working group.

Current work by Joe Williams, John Carlson and myself is improving past-legacy examples to match HAnim2 capabilities with X3D4.  We hope that testing and verification will help.

* HumanoidAnimation X3D Examples Archive
   https://www.web3d.org/x3d/content/examples/HumanoidAnimation

* X3D Tooltips, HAnimHumanoid loa
   https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimHumanoid.loa

HAnim designers hope that by identifying both HAnimHumanoid models and HAnimMotion animations with the LOA supported, it will be easier to mix/match models and animations.  Since each LOA is a strict subset of the next LOA, some compatibility is possible across human LOA levels.

* 4.9.7 Site and Segment relationships
   https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#SiteSegmentRelationships

It is not impossible to think that someday this work might even rise to the level of rigor needed for 3D HAnim models becoming part of medical records.  HAnim and X3D4 have the potential to help... everyone.

Thanks for your scrutiny and helpful questions.

On 6/18/2020 11:02 PM, John Carlson wrote:
> 
> To answer your question, many parts of the government like to create acronyms.
> 
> John

Sorry John, can't blame government for this one.  (Wondering, are parts of the government controlling your keyboard?!)

> On Fri, Jun 19, 2020 at 12:38 AM J. Scheurich <mufti11 at web.de <mailto:mufti11 at web.de>> wrote:
> 
>     hI,
> 
>     From
> 
>     https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/hanim.html#HAnimMotion
> 
>     SFInt32 [in,out] loa -1 [-1,4]
> 
>     What does "loa" mean ? Fieldnames in X3D are often english words,
>     but the dictionary leo.org <http://leo.org> has no results for "loa" 8-(
> 
>     so long
>     MUFTI
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 http://faculty.nps.edu/brutzman

_______________________________________________
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/20200624/02e67361/attachment-0001.html>