view3dscene/tovrml: default containerField should be properly set for nodes under HAnimHumanoid. HAnimMotion is one sub-element which should not require a containerField. It should be defaulted to "motions"

[coderextreme]

$ grep children blenderLily.x3d[nada]
$ (~/Downloads/view3dscene-4.3.0-win64-x86_64/view3dscene/tovrmlx3d.exe --validate blenderLily.x3d 2>&1) |grep children

tovrmlx3d: Warning: X3D: Unknown X3D field name (indicated by containerField value) "children" by node "HAnimJoint" inside node "HAnimHumanoid"
tovrmlx3d: Warning: X3D: Unknown X3D field name (indicated by containerField value) "children" by node "HAnimMotion" inside node "HAnimHumanoid"
tovrmlx3d: Warning: X3D: Unknown X3D field name (indicated by containerField value) "children" by node "Transform" inside node "HAnimHumanoid"

Transforms go in the skin field, AFAIK there is no other choice!
HAnimMotions goes in the motions field
HAnimJoints go in the skeleton or joints field.

John

[michaliskambi]

Please attach a testcase. The default containerField for nodes like Transform is children, so possibly the input is missing containerField declaration when the nodes are USEd.

As always, attaching a testcase is appreciated.

[coderextreme]

Just remove all XML containerField attributes from an HAnimHumanoid and children. I don't know about Transform stuff, see below. I did check X3DChildNode and X3DNode for children...no luck with those. x3d.py does not provide containerField, and probably won't any time soon. I will try to attach to this email. 26.3.2 HAnimHumanoid HAnimHumanoid : X3DChildNode, X3DBoundedObject { SFVec3f [in,out] center 0 0 0 (-∞,∞) SFString [in out] description "" SFBool [in out] bboxDisplay FALSE SFBool [in out] visible TRUE MFString [in,out] info [] MFVec3f [in,out] jointBindingPositions [] (-∞,∞) MFRotation [in,out] jointBindingRotations [] (-∞,∞)|[-1,1] MFVec3f [in,out] jointBindingScales [] (0,∞) MFNode [in,out] joints [] [HAnimJoint] SFInt32 [in,out] loa -1 [-1,4] SFNode [in,out] metadata NULL [X3DMetadataObject] MFNode [in,out] motions [] [HAnimMotion] MFBool [in,out] motionsEnabled [] SFString [in,out] name "" SFRotation [in,out] rotation 0 0 1 0 (-∞,∞)|[-1,1] SFVec3f [in,out] scale 1 1 1 (0,∞) SFRotation [in,out] scaleOrientation 0 0 1 0 (-∞,∞)|[-1,1] MFNode [in,out] segments [] [HAnimSegment] MFNode [in,out] sites [] [HAnimSite] SFString [in,out] skeletalConfiguration "BASIC" MFNode [in,out] skeleton [] [HAnimJoint, HAnimSite] MFNode [in,out] skin [] [IndexedFaceSet, X3DGroupingNode, Shape] SFNode [in,out] skinBindingCoord NULL [X3DCoordinateNode] SFNode [in,out] skinBindingNormal NULL [X3DNormalNode] SFNode [in,out] skinCoord NULL [X3DCoordinateNode] SFNode [in,out] skinNormal NULL [X3DNormalNode] SFVec3f [in,out] translation 0 0 0 (-∞,∞) SFString [in,out] version "" MFNode [in,out] viewpoints [] [HAnimSite] SFVec3f [] bboxCenter 0 0 0 (-∞,∞) SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1 }

…

On Tue, Sep 26, 2023 at 9:13 AM Michalis Kamburelis < ***@***.***> wrote: Please attach a testcase. The default containerField for nodes like Transform is children, so possibly the input is missing containerField declaration when the nodes are USEd. As always, attaching a testcase is appreciated. — Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFMJ56NQKVMN4TOQKR4TW3X4LPI3ANCNFSM6AAAAAA5HCTVL4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[michaliskambi]

Just remove all XML containerField attributes from an HAnimHumanoid and
children. I don't know about Transform stuff, see below. I did check
X3DChildNode and X3DNode for children...no luck with those.

I don't understand this statement. To investigate this issue, please attach a testcase as I said. As far as I know, CGE/view3dscene behave correctly: they follow the containerField specified in X3D XML specification, https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#HAnimJoint
. Maybe the testcase just misses containerField="xxx" usage at respective "<USE ...>" elements.

[coderextreme]

KoreanCharacterMotionAnnexD01Jin.x3d.txt

Here's the attachment that didn't make it through email (I guess they don't allow attachment of .x3d extension).

[coderextreme]

containerField="children" is for children HAnimJoints of HAnimJoints. For HAnimJoints which are children of HAnimHumanoid, containerField="skeleton" or containerField="joints" are used. There's no field "children" in an HAnimHumanoid, see spec I mentioned.

[coderextreme]

There's no need to specify containerField for HAnimJoint which are children of HAnimJoint.

[coderextreme]

Also, Transform (and a few other types of nodes) children of HAnimHumanoid should use containerField="skin" to make view3dscene be quiet. It would be good if view3dscene/tovrmlx3d figured that out on its own.

[coderextreme]

What I'm getting at is that view3dscene should be able to figure out automatically what containerField to use for children of HAnimHumanoid, and should not report "children" which is not an acceptable field for HAnimHumanoid.

[coderextreme]

Thanks for continued troubleshooting.

Please do not do anything with containerField handling in x3d.py since it is unique to XML encoding.

Don Brutzman:
"If you encounter any incorrect handling, please provide a regular issue report that notes

Model, in .x3d/.x3dv and also .py
Error or warning that was encountered, relevant tools, etc.

I can then isolate the problem and fix it. When errors do occur, it is usually an error in the scene, but sometimes a simple omission of some sort somewhere deep in the code autogeneration of the library."

I don't have any python that is a short test case, because I am building the humanoid with a Blender X3DV addon for exporting X3DV. What I will do is generate python from XML, and then present it.

[michaliskambi]

The testcase is missing the needed containerField values. You need to specify them like this:

<HAnimHumanoid ...>
  <HAnimJoint DEF='hanim_humanoid_root'  containerField="skeleton">
   ....
  </HAnimJoint>

  <HAnimJoint USE='hanim_humanoid_root' containerField="joints" />
</HAnimHumanoid>

What I'm getting at is that view3dscene should be able to figure out automatically what containerField to use for children of HAnimHumanoid, and should not report "children" which is not an acceptable field for HAnimHumanoid.

That's not how X3D XML encoding works. There's no "automatic guessing" of what is the containerField of given node. Instead: The default containerField is specified by the spec (same link as in my previous post: https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#HAnimJoint ), and if you need to use a different value -- you need to specify it explicitly by adding containerField="xxx" .

Reason: Automatic guessing would be faulty sometimes -- some nodes have a few SFNode and MFNode fields, and it is not possible to always guess where should the children go. So the spec doesn't specify any logic for guessing.

• E.g. to which field of PhysicalMaterial do you assign ImageTexture. To baseTexture , emissiveTexture, etc.?

• To which field of HAnimHumanoid do you assign HAnimJoint? To joints or skeleton? (because they are both possible https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimHumanoid ).

  ( Though in theory automatic guessing could do different decisions depending on whether the node is USEd or not... but that would complicate the guessing even more. That is why spec says: no guessing, you need to specify containerField. )

[coderextreme]

Yes, I know all this. Please contact Don Brutzman and tell him that x3d.py needs to create containerFields when outputting XML, otherwise, I have to go in for each HAnimHumanoid I create in XML and add containerFields. I am limited to one post per day now. Thanks! John

…

On Wed, Sep 27, 2023 at 6:47 AM Michalis Kamburelis < ***@***.***> wrote: The testcase is missing the needed containerField values. You need to specify them like this: <HAnimHumanoid ...> <HAnimJoint DEF='hanim_humanoid_root' containerField="skeleton"> .... </HAnimJoint> <HAnimJoint USE='hanim_humanoid_root' containerField="joints" /> </HAnimHumanoid> What I'm getting at is that view3dscene should be able to figure out automatically what containerField to use for children of HAnimHumanoid, and should not report "children" which is not an acceptable field for HAnimHumanoid. That's not how X3D XML encoding works. There's no "automatic guessing" of what is the containerField of given node. Instead: The default containerField is specified by the spec (same link as in my previous post: https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#HAnimJoint ), and if you need to use a different value -- you need to specify it explicitly by adding containerField="xxx" . Reason: Automatic guessing would be faulty sometimes -- some nodes have a few SFNode and MFNode fields, and it is not possible to always guess where should the children go. So the spec doesn't specify any logic for guessing. - E.g. to which field of PhysicalMaterial do you assign ImageTexture. To baseTexture , emissiveTexture, etc.? - To which field of HAnimHumanoid do you assign HAnimJoint? To joints or skeleton? (because they are both possible https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimHumanoid ). ( Though in theory automatic guessing could do different decisions depending on whether the node is USEd or not... but that would complicate the guessing even more. That is why spec says: no guessing, you need to specify containerField. ) — Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFMJ53AINJQKCZP7HCLGVLX4QG6RANCNFSM6AAAAAA5HCTVL4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[michaliskambi]

Yes, I know all this. Please contact Don Brutzman and tell him that x3d.py
needs to create containerFields when outputting XML, otherwise, I have to
go in for each HAnimHumanoid I create in XML and add containerFields.

I am limited in time, too, sorry. And I don't know anything about x3d.py .

If you have found a bug you believe you should report to x3d.py and/or to Don Brutzman, please report it to that project or person. You can of course send link to Don to this ticket. This is a GitHub repo for view3dscene.

[coderextreme]

I agree time is limited. I do not want to keep on editing huge HAnim files and entering containerField's. I have already posted my issues to x3d-public, and Don told me to stop posting and only post one post per day.

My suggestion for view3dscene is to stop reporting that "children" is somehow a field of HAnimHumanoid.

I consider this issue closed beyond that.

[michaliskambi]

My suggestion for view3dscene is to stop reporting that "children" is somehow a field of HAnimHumanoid.

view3dscene says that HAnimHumanoid doesn't have "children" field. And if you don't specify the containerField in e.g. Transform or HAnimJoint, they use the default containerField equal to "children", which is wrong inside HAnimHumanoid. There's nothing to fix here from view3dscene side, we behave as spec says (as likely just like other browsers), from what I can see.

[coderextreme]

fooGrampsXML.x3d.txt

Here is an example with a missing containerField attribute for HAnimMotion which is not defaulted to "motions" by tovrmlx3d.exe. The parent of HAnimMotion is HAnimHumanoid. This remains an issue because x3d.py checks for default containerField of HAnimMotion (perhaps just for children of HAnimHumanoid???) and does not set it if it's the default (see Andreas' changes to x3d.py to add non-default containerFields).

XML Schema:

    <xs:simpleType name="containerFieldChoicesHAnimMotion">
            <xs:annotation>
                    <xs:appinfo>containerFieldChoicesHAnimMotion lists the allowed containerField enumeration values for HAnimMotion node: default "children" if parent node is a grouping node, otherwise "motions" if parent node is HAnimHumanoid.</xs:appinfo>
                    <xs:documentation source="https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField"/>
            </xs:annotation>
            <xs:restriction base="xs:NMTOKEN">
                    <xs:enumeration value="children">
                            <xs:annotation>
                                    <xs:appinfo>parent node is a grouping node</xs:appinfo>
                            </xs:annotation>
                    </xs:enumeration>
                    <xs:enumeration value="motions">
                            <xs:annotation>
                                    <xs:appinfo>parent node is HAnimHumanoid</xs:appinfo>
                            </xs:annotation>
                    </xs:enumeration>
            </xs:restriction>
    </xs:simpleType>

[michaliskambi]

Ack, we'll then add auto-detection of HAnimMotion.containerField.

[michaliskambi]

We now automatically account for proper HAnimMotion.containerField. Testcase: https://github.com/castle-engine/demo-models/blob/master/x3d/hanimmotion_containerfield.x3d

[coderextreme]

FYI, I am no longer attempting to use HAnimMotion because Joe wanted me to use Interpolators. I’d like to try more examples, but I only have a couple of files right now. I successfully exported a BVH file from Blender, so I have hopes that I can continue to debug HAnimMotion in the future and provide a flag in the Blender exporter to choose interpolators or bvh style motions. I have been trying to do live mocap with X3D, but I’m at a step where my skeleton is in several pieces and I don’t have a good way of modeling a several bone collections, except perhaps as a linear list of joints. Hmm So yeah, streaming HAnim with urls may be in the future. John

…

On Thu, Feb 8, 2024 at 11:55 AM Michalis Kamburelis < ***@***.***> wrote: We now automatically account for proper HAnimMotion.containerField. Testcase: https://github.com/castle-engine/demo-models/blob/master/x3d/hanimmotion_containerfield.x3d — Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFMJ5YHSPQXLT6RUGGZTLDYSUGRJAVCNFSM6AAAAAA5HCTVL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZUGY2TQNZWGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>