<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:2084908565;
mso-list-type:hybrid;
mso-list-template-ids:466785804 -1 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Almost agree, Thanks John and Don.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>But why SF when this historically would be an enumerated MF. Only names that are the same in two places make a match. The only reason this is SF is because we don’t want to do anything but copy and paste the BVH list with no need for added quptes? The browser now has to sort through what is a space delimited list? </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Seeing that reminds me how versatile this might be since all the important stuff is in,out. </p><p class=MsoNormal>Various animations that apply to a slightly different articulation skeleton (new joints) could be applied and the capture skeleton automagically mapped to the x3d hanim Humanoid playback skeleton field. However, I don’t think a main idea of Motion was to be able to change animations on the fly, more like a dedicated animation for the specific character that is actually embedded in the Humanoid. Not like it should be my aim to swap between various animations as I please, and with not very much control over cycle timing or switching between different animations, anyway.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> We could have made the joints field an MFString, but didn't.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Should be the same as the Humanoid joints field. Sorry I did not make this point sooner. </p><p class=MsoNormal>Joint names (strings) must match, except ‘IGNORED’? So, please make Motion joints field an MF with certain enumerations that reflect a ‘standard’ hanim skeleton defininition in the Humanoid joints field.</p><p class=MsoNormal>Uuuh ooh, those strings of the Humanoid joints field are in a completely different form than the Humanoid Motion joints field in that the Humanoid joints field strings are embedded in those USE statements. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>OK, application of this Motion node means that the Humanoid joints field which contains a collection of Joint names used in the playback skeleton (Humanoid joints) is actually justifiable. In this plan we must match the entries in both lists for satisfactory results.</p><p class=MsoNormal>This particular method of matching the joints used in the actual playback skeleton, as declared in the skeleton field and named again in the Humanoid joints field, to the capture skeleton named in the Humanoid Motion joints field. </p><p class=MsoNormal>To me, it also means revisiting the Humanoid joints, segments, and sites fields because it is obvious that we should employ the same syntax for both. In short, of course both these should be enumerated MF strings. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Clearly tool support will be needed to parse and produce these properly.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Right, authortime support to transform and validate, as well as deep runtime support if all Motion fields are in.out.</p><p class=MsoNormal>Yes, it will be easier if both joints fields are in the same form. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Now, the tool support not only has to ignore the USE statements in the joints field, a step that is learned the hard way, but has to do extra work to extract the joint name strings from the USE statements as well as doing on the fly in,out updates of the entire animation structure. </p><p class=MsoNormal>So, I think most of Motion would be init only. Using Motion, seems to me that you should update the entire node, especially if new skeleton does not exactly match the current skeleton. </p><p class=MsoNormal>Well, maybe be allowed to change the actual animation data on the fly (only need to rebuild data for whatever unknown matching, conversion, and animation scheme that is happening somewhere deep under the covers).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>However, still a lot less tool support than if we aimed at being able to import some complete BVH file in runtime then figure it out. Can probably get fairly close with some copy and paste authortime guidance.</p><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>Etc … <o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>No fair, etc…. please show sample data for all fields in the example<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks and All Best Safeness,<o:p></o:p></p><p class=MsoNormal>Joe<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:yottzumm@gmail.com">John Carlson</a><br><b>Sent: </b>Sunday, June 21, 2020 10:57 AM<br><b>To: </b><a href="mailto:brutzman@nps.edu">Don Brutzman</a><br><b>Cc: </b><a href="mailto:h-anim@web3d.org">Humanoid Animation (HAnim) Working Group</a>; <a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] Wrong type for default HAnimMotion.channels</p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Looks good.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>John</p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Sun, Jun 21, 2020 at 10:04 AM Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:</p></div></div></div><p class=MsoNormal style='margin-left:4.8pt'>I have cleaned up the new Mantis issues as follows.<br><br>====================================================================================<br>* Mantis 1311: Check type definitions for HAnimMotion channels field and joints field in<br><br>HAnimMotion channels field and joints field are defined as type string, as best match for somewhat-complex data structures.<br><br>It will be helpful to confirm these data types as part of defining the mapping to X3D data types. HAnim2 specification prose and examples provide the authoritative explanation.<br><br> interface Motion {<br> string description ""<br> string channels ""<br> sequence<Boolean> channelsEnabled []<br><br> string joints ""<br><br>No inconsistencies identified for HAnim2.<br><br>====================================================================================<br><br>* Mantis 1312: Mismatched type defaults defined for HAnimMotion channels field in X3D4<br><br>HAnimMotion channels field and joints field are defined as type SFString but have MFString default values [] instead. Need to make these consistent.<br><br>X3D4 Part 1: Architecture and base components<br> 26 Humanoid Animation (HAnimH-Anim) component<br> 26.3.4 HAnimMotion<br><br>HAnimMotion : X3DChildNode {<br> SFString [in,out] channels []<br> MFBool [in,out] channelsEnabled []<br><br> MFString [in,out] joints []<br><br>etc.<br>----------------------<br><br>1. Default value change needed:<br><br> SFString [in,out] channels []<br><br>to<br><br> SFString [in,out] channels ""<br><br>----------------------<br><br>2. X3D4 design decision needed:<br><br>Utilize list data structure, permitting validation of joint names:<br><br> MFString [in,out] joints []<br><br>or else map identically to plain-string HAnim2 specification:<br><br> SFString [in,out] joints ""<br><br>====================================================================================<br><br>Hopefully we are zeroed in on the appropriate remedies now.<br><br><br>On 6/20/2020 2:51 PM, Don Brutzman wrote:<br>> Good catch John, I was all confused in the last post. Sorry about that!<br>> <br>> Let's look at an excerpt from the spec example.<br>> <br>> * HAnim2 Part 2: Humanoid animation (HAnim) motion data animation<br>> Annex D, Examples of HAnim motion data animation using a Motion object<br>> D.2 Example with equal joint numbers<br>> <a href="https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/ExampleMocapAnimationMotionObject.html" target="_blank">https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/ExampleMocapAnimationMotionObject.html</a><br>> <br>> <HAnimMotion frameCount="392" frameTime = "0.033333"<br>> <br>> joints="HumanoidRoot, l_hip, l_knee, l_talocrural, r_hip,<br>> r_knee, r_talocrural, vl5, IGNORED, l_shoulder,<br>> l_elbow, l_radiocarpal, IGNORED, r_shoulder, r_elbow,<br>> r_radiocarpal, IGNORED, skullbase"<br>> <br>> channels="6 Xposition Yposition Zposition Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation<br>> 3 Zrotation Xrotation Yrotation"<br>> <br>> etc.<br>> <br>> As this shows, the joints field is a list of name values, and the channels field is a complex description that comes from the original BVH definitions.<br>> <br>> We could have made the joints field an MFString, but didn't.<br>> <br>> We could have made the channels field an MFString, but didn't - too complex, not regular, mix of strings and integers.<br>> <br>> Clearly tool support will be needed to parse and produce these properly.<br>> <br>> We can probably add some utility methods to our APIs such as addChannel(), validate() etc.<br>> <br>> So perhaps the only error is simply what MUFTI pointed out in the first place, the default for empty SFString should be "" rather than empty [] array. Apologies for swerving in the wrong direction.<br>> <br>> Taking a break now. Happy Father's Day!<br>> <br>> <br>> <br>> On 6/20/2020 2:19 PM, John Carlson wrote:<br>>> Again, I don’t have an issue with the HAnim standard as it stands. I have a problem with syncing up the standard with the schema.<br>>><br>>> On Sat, Jun 20, 2020 at 4:10 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a> <mailto:<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>>> wrote:<br>>><br>>> I believe that there’s a similar issue with joints? I’m on my back so it’s it hard to check.<br>>><br>>> We’ve been through this before.<br>>><br>>> joints should be sequence<string> or just string?<br>>><br>>> John<br>>><br>>> On Sat, Jun 20, 2020 at 3:29 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a> <mailto:<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>>> wrote:<br>>><br>>> Don, also change examples in HAnim 2 standard, if there are any.<br>>><br>>> Thanks,<br>>><br>>> John<br>>><br>>> On Sat, Jun 20, 2020 at 12:47 PM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> <mailto:<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>> wrote:<br>>><br>>> [added: HAnim working group]<br>>><br>>> Hmmm, I think the comparison reveals a potential flaw in the specifications.<br>>><br>>> On 6/18/2020 11:19 PM, J. Scheurich wrote:> HAnimMotion : X3DChildNode<br>>> SFString [in,out] channels []<br>>> ><br>>> > Shouldnt it be<br>>> > HAnimMotion : X3DChildNode<br>>> > SFString [in,out] channels ""<br>>><br>>> Default value [] corresponds to MFString, default value "" corresponds to SFString. You've found a mismatch.<br>>><br>>> Investigating further:<br>>> ===================================================================<br>>><br>>> [1] HAnim Part 2: Humanoid animation (HAnim) motion data animation<br>>> 6 HAnim motion data animation using Motion objects<br>>> 6.3 Data structure of Motion object<br>>> <a href="https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/MotionNodes.html#MotionObject" target="_blank">https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/MotionNodes.html#MotionObject</a><br>>><br>>> interface Motion {<br>>> string description ""<br>>> string channels ""<br>>> sequence<Boolean> channelsEnabled []<br>>> double cycleTime<br>>> double elapsedTime<br>>> Boolean enabled false<br>>> int frameCount 0 [0, ∞)<br>>> float frameDuration 0.1 (0, ∞)<br>>> int frameIncrement 1 (-∞, ∞)<br>>> int frameIndex 0 [0, ∞)<br>>> string joints ""<br>>> integer loa -1 [-1,4]<br>>> Boolean loop false<br>>> Boolean next<br>>> Boolean previous<br>>> sequence<float> values [] (-∞,∞)<br>>> }<br>>><br>>> "The channels field consists of a list, for each joint, of the number of channels for transformation, followed by the transformation type of each channel of data for that joint. Each value shall be separated by a comma and/or one or more spaces. Channels within a given Motion object are enabled by default, unless otherwise indicated by the corresponding Boolean entry in the channelsEnabled field."<br>>> ===================================================================<br>>><br>>> [2] X3D4 Part 1: Architecture and base components<br>>> 26 Humanoid Animation (HAnimH-Anim) component<br>>> 26.3.4 HAnimMotion<br>>><br>>> HAnimMotion : X3DChildNode {<br>>> SFString [in,out] channels []<br>>> MFBool [in,out] channelsEnabled []<br>>> SFTime [out] cycleTime<br>>> SFString [in,out] description ""<br>>> SFTime [out] elapsedTime (0,∞)<br>>> SFBool [in,out] enabled TRUE<br>>> SFInt32 [out] frameCount [0,∞)<br>>> SFTime [in,out] frameDuration 0.1 (0,∞)<br>>> SFInt32 [in,out] frameIncrement 1 (-∞,∞)<br>>> SFInt32 [in,out] frameIndex 0 (0,∞)<br>>> MFString [in,out] joints []<br>>> SFInt32 [in,out] loa -1 [-1,4]<br>>> SFBool [in,out] loop false<br>>> SFNode [in,out] metadata NULL [X3DMetadataObject]<br>>> SFBool [in] next<br>>> SFBool [in] previous<br>>> MFFloat [in,out] values [] (-∞,∞)<br>>> }<br>>> ===================================================================<br>>><br>>> The HAnim2 specification is the governing reference.<br>>><br>>> It appears crystal clear that the channels field is a list.<br>>><br>>> Therefore you have found an important error - great work! As remedy, we should have the following interface definitions:<br>>><br>>> HAnim2 change:<br>>><br>>> string channels ""<br>>> to<br>>> sequence<string> channels ""<br>>><br>>> and corresponding X3D4 change:<br>>><br>>> SFString [in,out] channels []<br>>> to<br>>> MFString [in,out] channels []<br>>><br>>> Meanwhile it looks like the corresponding channelsEnabled field is properly defined, and having both fields (channels and channelsEnabled) as matching list/MF array types simplifies implementation considerably.<br>>><br>>> Looking forward to review and confirmation, improvement and resolution. Have entered a pair of Mantis issues needed to correct each specification:<br>>><br>>> [3] Mantis 1311: Incorrect type defined for HAnimMotion channels field in HAnim2<br>>> <a href="https://www.web3d.org/member-only/mantis/view.php?id=1311" target="_blank">https://www.web3d.org/member-only/mantis/view.php?id=1311</a><br>>><br>>> [4] Mantis 1312: Mismatched type defined for HAnimMotion channels field in X3D4<br>>> <a href="https://www.web3d.org/member-only/mantis/view.php?id=1312" target="_blank">https://www.web3d.org/member-only/mantis/view.php?id=1312</a><br>>><br>>> As ever, we continue review discussion of issues on mailing lists, and the specification editors use Mantis issue to track consensus and resolution of changes.<br>>><br>>> Thanks for reporting this problem. Good luck with further implementation/evaluation efforts (of cool content!) to confirm/improve the HAnim2 and X3D4 specifications.<br>>><br>>> all the best, Don<br>>> -- Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> <mailto:<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>>> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" target="_blank">http://faculty.nps.edu/brutzman</a><br>>><br>> <br>> all the best, Don<br><br>all the best, Don<br>-- <br>Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" target="_blank">http://faculty.nps.edu/brutzman</a></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>