[x3d-public] Wrong type for default HAnimMotion.channels
Don Brutzman
brutzman at nps.edu
Sun Jun 21 08:04:11 PDT 2020
I have cleaned up the new Mantis issues as follows.
====================================================================================
* Mantis 1311: Check type definitions for HAnimMotion channels field and joints field in
HAnimMotion channels field and joints field are defined as type string, as best match for somewhat-complex data structures.
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.
interface Motion {
string description ""
string channels ""
sequence<Boolean> channelsEnabled []
string joints ""
No inconsistencies identified for HAnim2.
====================================================================================
* Mantis 1312: Mismatched type defaults defined for HAnimMotion channels field in X3D4
HAnimMotion channels field and joints field are defined as type SFString but have MFString default values [] instead. Need to make these consistent.
X3D4 Part 1: Architecture and base components
26 Humanoid Animation (HAnimH-Anim) component
26.3.4 HAnimMotion
HAnimMotion : X3DChildNode {
SFString [in,out] channels []
MFBool [in,out] channelsEnabled []
MFString [in,out] joints []
etc.
----------------------
1. Default value change needed:
SFString [in,out] channels []
to
SFString [in,out] channels ""
----------------------
2. X3D4 design decision needed:
Utilize list data structure, permitting validation of joint names:
MFString [in,out] joints []
or else map identically to plain-string HAnim2 specification:
SFString [in,out] joints ""
====================================================================================
Hopefully we are zeroed in on the appropriate remedies now.
On 6/20/2020 2:51 PM, Don Brutzman wrote:
> Good catch John, I was all confused in the last post. Sorry about that!
>
> Let's look at an excerpt from the spec example.
>
> * HAnim2 Part 2: Humanoid animation (HAnim) motion data animation
> Annex D, Examples of HAnim motion data animation using a Motion object
> D.2 Example with equal joint numbers
> https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/ExampleMocapAnimationMotionObject.html
>
> <HAnimMotion frameCount="392" frameTime = "0.033333"
>
> joints="HumanoidRoot, l_hip, l_knee, l_talocrural, r_hip,
> r_knee, r_talocrural, vl5, IGNORED, l_shoulder,
> l_elbow, l_radiocarpal, IGNORED, r_shoulder, r_elbow,
> r_radiocarpal, IGNORED, skullbase"
>
> channels="6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation
> 3 Zrotation Xrotation Yrotation"
>
> etc.
>
> 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.
>
> We could have made the joints field an MFString, but didn't.
>
> We could have made the channels field an MFString, but didn't - too complex, not regular, mix of strings and integers.
>
> Clearly tool support will be needed to parse and produce these properly.
>
> We can probably add some utility methods to our APIs such as addChannel(), validate() etc.
>
> 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.
>
> Taking a break now. Happy Father's Day!
>
>
>
> On 6/20/2020 2:19 PM, John Carlson wrote:
>> 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.
>>
>> On Sat, Jun 20, 2020 at 4:10 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>
>> I believe that there’s a similar issue with joints? I’m on my back so it’s it hard to check.
>>
>> We’ve been through this before.
>>
>> joints should be sequence<string> or just string?
>>
>> John
>>
>> On Sat, Jun 20, 2020 at 3:29 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>
>> Don, also change examples in HAnim 2 standard, if there are any.
>>
>> Thanks,
>>
>> John
>>
>> On Sat, Jun 20, 2020 at 12:47 PM Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>>
>> [added: HAnim working group]
>>
>> Hmmm, I think the comparison reveals a potential flaw in the specifications.
>>
>> On 6/18/2020 11:19 PM, J. Scheurich wrote:> HAnimMotion : X3DChildNode
>> SFString [in,out] channels []
>> >
>> > Shouldnt it be
>> > HAnimMotion : X3DChildNode
>> > SFString [in,out] channels ""
>>
>> Default value [] corresponds to MFString, default value "" corresponds to SFString. You've found a mismatch.
>>
>> Investigating further:
>> ===================================================================
>>
>> [1] HAnim Part 2: Humanoid animation (HAnim) motion data animation
>> 6 HAnim motion data animation using Motion objects
>> 6.3 Data structure of Motion object
>> https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/MotionNodes.html#MotionObject
>>
>> interface Motion {
>> string description ""
>> string channels ""
>> sequence<Boolean> channelsEnabled []
>> double cycleTime
>> double elapsedTime
>> Boolean enabled false
>> int frameCount 0 [0, ∞)
>> float frameDuration 0.1 (0, ∞)
>> int frameIncrement 1 (-∞, ∞)
>> int frameIndex 0 [0, ∞)
>> string joints ""
>> integer loa -1 [-1,4]
>> Boolean loop false
>> Boolean next
>> Boolean previous
>> sequence<float> values [] (-∞,∞)
>> }
>>
>> "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."
>> ===================================================================
>>
>> [2] X3D4 Part 1: Architecture and base components
>> 26 Humanoid Animation (HAnimH-Anim) component
>> 26.3.4 HAnimMotion
>>
>> HAnimMotion : X3DChildNode {
>> SFString [in,out] channels []
>> MFBool [in,out] channelsEnabled []
>> SFTime [out] cycleTime
>> SFString [in,out] description ""
>> SFTime [out] elapsedTime (0,∞)
>> SFBool [in,out] enabled TRUE
>> SFInt32 [out] frameCount [0,∞)
>> SFTime [in,out] frameDuration 0.1 (0,∞)
>> SFInt32 [in,out] frameIncrement 1 (-∞,∞)
>> SFInt32 [in,out] frameIndex 0 (0,∞)
>> MFString [in,out] joints []
>> SFInt32 [in,out] loa -1 [-1,4]
>> SFBool [in,out] loop false
>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>> SFBool [in] next
>> SFBool [in] previous
>> MFFloat [in,out] values [] (-∞,∞)
>> }
>> ===================================================================
>>
>> The HAnim2 specification is the governing reference.
>>
>> It appears crystal clear that the channels field is a list.
>>
>> Therefore you have found an important error - great work! As remedy, we should have the following interface definitions:
>>
>> HAnim2 change:
>>
>> string channels ""
>> to
>> sequence<string> channels ""
>>
>> and corresponding X3D4 change:
>>
>> SFString [in,out] channels []
>> to
>> MFString [in,out] channels []
>>
>> 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.
>>
>> Looking forward to review and confirmation, improvement and resolution. Have entered a pair of Mantis issues needed to correct each specification:
>>
>> [3] Mantis 1311: Incorrect type defined for HAnimMotion channels field in HAnim2
>> https://www.web3d.org/member-only/mantis/view.php?id=1311
>>
>> [4] Mantis 1312: Mismatched type defined for HAnimMotion channels field in X3D4
>> https://www.web3d.org/member-only/mantis/view.php?id=1312
>>
>> 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.
>>
>> Thanks for reporting this problem. Good luck with further implementation/evaluation efforts (of cool content!) to confirm/improve the HAnim2 and X3D4 specifications.
>>
>> all the best, Don
>> -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto: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
>>
>
> all the best, Don
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
More information about the x3d-public
mailing list