[x3d-public] Isolating problems with HAnimHumanoid.java and X3DUOM, etc.

[John Carlson]

Joe the actual issue is, we want to restrict the application programmer’s
ability to set the containerField in XML to something typesafe.   I
outlined a possible solution (not using a string parameter in
setContainerField*).  Perhaps I should create a more formal, compilable
solution for HAnim.  It seems to be the hardest to solve.  I thought my
solution needed some work, but it looked pretty typesafe (I think I missed
an if/then).  The main thing was to have a set of enumerated containerField
values for any pair of parent/child node types.

I think this will be well hidden behind addJoints(), addSkeleton, etc.
 reviews or new designs from anywhere are possible.

I am pretty sure this is up to a particular private SAI implementation, and
does not need to be exposed to the SAI standard.  Indeed, it may only be
applicable to HAnim.  Textures?

The point of not having a children field is to prevent a top level
HAnimJoint field from setting a containerField value = “children”. There’s
no “children” field at the HAnimHumanoid allowing HAnimJoints as children.
As you say, there’s no addChildren.

This really becomes ambiguous when trying to output a “children”
HAnimHumanoid field in VRML.  Don’t go there, use the fields that actually
exist, please, otherwise things aren’t typesafe.  I’ve already patched that.

The reason Don’s current code is correct and it sneaks under the radar is
that it doesn’t output anything. Sure, it “validates,” but there’s no
external checks to make sure.  Try adding JSON, VRML or XML output
instructions and see what happens.   The code itself starts complaining
when you add output encodings.  My guess is, there’s a sticky-wicky in the
X3DJSAIL stylesheet.  I’m hoping my solution outlined elsewhere can help.

Vince also has a marvelous solution for container fields.  Set them, but
then remove the ones that have default values, then when you validate, you
don’t have to validate a bunch of defaulted containerFields.

Anyway, learning something new with each go round.

John

On Mon, Jun 24, 2024 at 3:37 PM Joe D Williams <joedwil at earthlink.net>
wrote:

> Hi John,
>
>
>
> > This is WRONG!
>
> > containerField_ALLOWED_VALUES = new String[] { "children" }; // type
> xs:NMTOKEN
>
>
>
> The containerField names the 'legal' parent type:
>
> Humanoid can be a child of a node that can have children, like Transform,
> or the host scene, for instances. So the Humanoid containerField default is
> 'children' as listed.
>
>
>
> Note that the containerField for the first Joint is skeleton, it contains
> the Joint hierarchy and all following Joint containerField are children.
>
>
>
> Humanoid 'children' nodes all have specific names.
>
> Humanoid does not show the add/remove children field because no
> general-purpose nodes wanted
>
> only the listed ones, but all is alive and available.
>
> Thanks,
>
> Joe
>
>
>
>
>
> -----Original Message-----
> From: John Carlson <yottzumm at gmail.com>
> Sent: Jun 24, 2024 2:47 AM
> To: Joe D Williams <joedwil at earthlink.net>, Michalis Kamburelis <
> michalis.kambi at gmail.com>, X3D Graphics public mailing list <
> x3d-public at web3d.org>
> Subject: Re: Isolating problems with HAnimHumanoid.java and X3DUOM, etc.
>
>
> Weird, sorry, I thought I didn’t send this message.
>
> On Mon, Jun 24, 2024 at 3:58 AM John Carlson <yottzumm at gmail.com> wrote:
>
>> The beginning of actually solving the problem.
>>
>> HAnimHumanoid.java:
>>
>> This is WRONG!
>>
>> public static final String containerField_DEFAULT_VALUE = "children"; //
>> type xs:NMTOKEN
>>
>> This is WRONG!
>>
>> containerField_ALLOWED_VALUES = new String[] { "children" }; // type
>> xs:NMTOKEN
>>
>> X3DUOM:
>>
>> <ConcreteNode name="HAnimHumanoid">
>> [ snip ]
>> <!-- THIS IS WRONG! -->
>> <containerField default="children" type="xs:NMTOKEN"/>
>> [ snip ]
>>       </ConcreteNode>
>>
>> [ There's NO children field here!--And that may be ok! ]
>>
>> HAnimHumanoid : X3DChildNode, X3DBoundedObject {
>>   SFVec3f    [in,out] center                0 0 0    (-∞,∞)
>>   SFString   [in,out] description           ""
>>   SFBool     [in,out] bboxDisplay           FALSE
>>   MFString   [in,out] info                  []
>>   MFVec3f    [in,out] jointBindingPositions []       (-∞,∞)
>>   MFRotation [in,out] jointBindingRotations []       [-1,1] or (-∞,∞)
>>   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] or (-∞,∞)
>>   SFVec3f    [in,out] scale                 1 1 1    (0,∞)
>>   SFRotation [in,out] scaleOrientation      0 0 1 0  [-1,1] or (-∞,∞)
>>   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                  []       [Group, LOD, Shape, Switch, Transform, IndexedFaceSet, IndexedFanSet, IndexedLineSet, IndexedQuadSet, IndexedTriangleSet, IndexedTriangleStripSet]
>>   SFNode     [in,out] skinBindingCoords     NULL     [Coordinate|CoordinateDouble]
>>   SFNode     [in,out] skinBindingNormals    NULL     [X3DNormalNode]
>>   SFNode     [in,out] skinCoord             NULL     [Coordinate|CoordinateDouble]
>>   SFNode     [in,out] skinNormal            NULL     [X3DNormalNode]
>>   SFVec3f    [in,out] translation           0 0 0    (-∞,∞)
>>   SFString   [in,out] version               "2.0"    ["2.0"]
>>   MFNode     [in,out] viewpoints            []       [HAnimSite]
>>   SFBool     [in,out] visible               TRUE
>>   SFVec3f    []       bboxCenter            0 0 0    (-∞,∞)
>>   SFVec3f    []       bboxSize              -1 -1 -1 [0,∞) or −1 −1 −1
>>
>> }
>>
>> ======================================================
>> Here's containerField for Group in X3DUOM. HAnimHumanoid needs something
>> like this.
>>
>>             <containerField default="children"
>>
>>             type="containerFieldChoicesGroupLODShapeTransformSwitch"/>
>>
>> [ refers to: ]
>>
>>       <SimpleType name="containerFieldChoicesGroupLODShapeTransformSwitch"
>>                   baseType="xs:NMTOKEN"
>>
>> appinfo="containerFieldChoicesGroupLODShapeTransformSwitch lists the
>> allowed containerField enumeration values for Shape, Transform and LOD
>> nodes: "children" if parent node has abstract type X3DGroupingNode,
>> otherwise "metadata" default."
>>                   documentation="
>> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
>> ">
>>          <enumeration value="children"
>>                       appinfo="parent node has abstract type
>> X3DGroupingNode"/>
>>          <enumeration value="proxy" appinfo="parent node is Collision"/>
>>          <enumeration value="rootNode" appinfo="parent node is GeoLOD"/>
>>          <enumeration value="shape" appinfo="parent node is CADFace or
>> CollidableShape"/>
>>          <enumeration value="skin" appinfo="parent node is
>> HAnimHumanoid"/>
>>       </SimpleType>
>> ======================================================
>>
>> We need something like:
>>
>> <SimpleType name="containerFieldChoicesHAnimHumanoid"
>>
>> with enumerations, then refer to the node in the HAnimHumanoid type.
>>
>> Have I isolated the problem, or do I need to step into X3D Schema?
>>
>> Hmm?  Do we need a default container field for HAnimHumanoid?  Can we
>> leave off a default?
>>
>> I don't want to program XML, no thanks!
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240624/8d765d11/attachment.html>