[x3d-public] [x3d] [X3D] X3D schema, DTD updates: USE HAnim objects

[Joe D Williams]

Hi Don,

> You are correct that an HAnim* USE node within an skeleton doesn't 
> make sense.
>
> There are specific cases called out where HAnim* USE nodes appear as 
> direct children of HAnimHumanoid, motivated by making them 
> accessible to IK engines etc.

Yes,  the joints[] sites[] segments[] fields in Humanoid are artifact 
of providing the model in Proto form or pre 19774 legacy to serve 
either as a list of ROUTE destinations, or list of 'standard' 
@name(s).

No HAnim browser has ever required the joints[] sites[] segments[] 
fields in Humanoid.

The current spec is aimed at listing ROUTE destinations DEF(s) rather 
than name(s). Of course the @name field is the best for skeleton 
validation since the @DEF fields are user-defined.

> X3D Specification is inconsistent about noting that name field is 
> required, have submitted a specification comment to fix that 
> omission:

"The description of each field shall be as described in ISO/IEC 
19774."

seems clear to me, the 19774 says @name is required for all 'standard' 
items and seems intended as a means of verification..

> X3D Schematron (and thus X3D Validator) does have sufficient 
> expressive power to make this distinction, and will provide error 
> messages if either USE case is handled incorrectly.  8)

Great, then this is a case for X3DEdit where the note is:
Not appropriate to USE any 'named' HAnim node.
For a 'standard' humanoid, each 'standard' Joint/Segment/Site has a 
unique 'standard' name.

Basically, if you wish to USE a Joint or any other HAnim node, then 
that probably ain't real but you can do it, just don't include @name.

Thanks Again Don and all,
Joe


----- Original Message ----- 
From: "Don Brutzman" <brutzman at nps.edu>
To: "Joe D Williams" <joedwil at earthlink.net>; "X3D Graphics public 
mailing list" <x3d-public at web3d.org>; "X3D working group" 
<x3d at web3d.org>
Sent: Sunday, January 25, 2015 12:44 AM
Subject: Re: [x3d] [X3D] X3D schema, DTD updates: USE HAnim objects


> thank you for the thoughtful review Joe.
>
> On 1/22/2015 6:13 PM, Joe D Williams wrote:
>>>> HAnim* nodes: cannot require @name field
>>
>> not a workable rule by the current HAnim standard.
>>
>> In DIS terms that may apply:usually nonsensical."
>>
>> "Multiple owners for one entity is
>> (where entiity is a 'standard' hanim object in the hierarchy)
>>
>> thus USE of an named HAnim node is nonsensical:)
>
> H-Anim Specification does require a name field in these node 
> definitions, as you note below, so that is the guiding reference.
> http://www.web3d.org/documents/specifications/19774/V1.0/HAnim/ObjectInterfaces.html
>
> You are correct that an HAnim* USE node within an skeleton doesn't 
> make sense.
>
> There are specific cases called out where HAnim* USE nodes appear as 
> direct children of HAnimHumanoid, motivated by making them 
> accessible to IK engines etc.
>
> X3D DTD and Schema do not quite have sufficient expressive power to 
> make this distinction between the two cases.
>
> X3D Schematron (and thus X3D Validator) does have sufficient 
> expressive power to make this distinction, and will provide error 
> messages if either USE case is handled incorrectly.  8)
>
> I just rechecked and the X3D Specification is inconsistent about 
> noting that name field is required, have submitted a specification 
> comment to fix that omission:
>
> X3D Humanoid Animation (H-Anim) component
> 26.3 Node reference
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/hanim.html#Nodereference
>
>>>> - Metadata*, HAnim* nodes: cannot require @name field or else USE 
>>>> nodes fail to validate
>>>
>>> to me, that is OK.
>>
>> it is OK because there is no case of 'standard' humanoid where USE 
>> is valid or necessary.
>>
>> Besides, the spec says
>> Humanoid: The name field, which shall be present, stores the name 
>> of the humanoid defined by the Humanoid object.
>>
>> Joint: The name field is the only field which must be defined, all 
>> the other fields are optional.
>>
>> Segment: The name field shall be present, so that the Segment can 
>> be distinguished from other Segment objects.
>>
>> SIte: The name field shall be present so that the Site can be 
>> distinguished from other Site objects.
>>
>> Maybe some problems come from the fact that for VRML/X3D the HAnim 
>> name sort of overlaps the DEF.
>>
>> Nonetheless, for 'standard' every hanim object has to have a unique 
>> name (that is actually shown in the standard).
>> This makes it not proper to USE an hanim object.
>> Maybe a limitation,
>> maybe reality.
>>
>> Anyway, there is no reason to USE an HAnim node that has a name - 
>> it just isn't done or needed for our humanoid.
>>
>> except, that is in those useless legacy
>> joints []
>> segments []
>> sites []
>> fields of the Humanoid object, but that useage of USE are a special 
>> not very well explained cases that should be discussed.
>
> agreed, except maybe regarding "useless legacy" - as we gain 
> improving traction with our tool handling of HAnim models we may yet 
> find that they are indeed useful.
>
>> Thanks,
>> Joe
>>
>> I hope I have good pointd for HAnim nodes, but it is just the same 
>> for Metastuffs. the names and datas of whatever is created by USE 
>> is really of no consequence since only the DEF is accessible.
>>
>>
>>
>> ----- Original Message ----- From: "Joe D Williams" 
>> <joedwil at earthlink.net>
>> To: "Don Brutzman" <brutzman at nps.edu>; "X3D Graphics public mailing 
>> list" <x3d-public at web3d.org>; "X3D working group" <x3d at web3d.org>
>> Sent: Tuesday, January 20, 2015 5:04 PM
>> Subject: Re: [x3d] [X3D] X3D schema, DTD updates: FogCoordinate 
>> depth, X3DAppearanceNode is abstract
>>
>>
>>>> - Metadata*, HAnim* nodes: cannot require @name field or else USE 
>>>> nodes fail to validate
>>>
>>>
>>> to me, that is OK.
>>> How would it be good to USE an HanimJoint node, or any other 
>>> hanim. It just should not be done, like no good reason exists.
>>> Except maybe to try to transform right to left?
>>> No way for hanim, maybe for other creatures.
>>>
>>> Same for Meta. Why would I want another instance of the same meta 
>>> data?
>>>
>>> If possible, more like USE nodes should Not be allowed with these.
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- From: "Don Brutzman" 
>>> <brutzman at nps.edu>
>>> To: "X3D Graphics public mailing list" <x3d-public at web3d.org>; 
>>> "X3D working group" <x3d at web3d.org>
>>> Sent: Monday, January 19, 2015 8:02 PM
>>> Subject: [x3d] [X3D] X3D schema, DTD updates: FogCoordinate depth, 
>>> X3DAppearanceNode is abstract
>>>
>>>
>>>> X3D Schema, DTD update activity:
>>>>
>>>> =============================================================================
>>>> 18 January 2015, walmsley, brutzman
>>>> - FogCoordinate depth field as type MFFloat array
>>>> - X3DAppearanceNode abstract="true"
>>>> - Metadata*, HAnim* nodes: cannot require @name field or else USE 
>>>> nodes fail to validate
>>>> =============================================================================
>>>>
>>>> These assets can be found on the X3D Specifications: XML Schema 
>>>> and DOCTYPE Validation page.
>>>>
>>>>         http://www.web3d.org/specifications
>>>>
>>>> Full documentation updates have been autogenerated for the XML 
>>>> Schema and DOCTYPE validators.
>>>>
>>>> http://www.web3d.org/specifications/X3dSchemaDocumentation3.3/x3d-3.3.html
>>>>
>>>> http://www.web3d.org/specifications/X3dDoctypeDocumentation3.3.html
>>>>
>>>> The X3D Working Group also updated the X3D Graphics Standards: 
>>>> Specification Relationships diagram to show all major planned 
>>>> work.
>>>>
>>>> http://www.web3d.org/specifications/X3dSpecificationRelationships.png
>>>> http://www.web3d.org/specifications/X3dSpecificationRelationships.pdf
>>>>
>>>> Changes are tested through validation regression testing of 3800+ 
>>>> open source X3D scenes.
>>>>
>>>> http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
>>>>
>>>> Feedback welcome, thanks for all contributions.
>
> 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