[x3d-public] What are valid children of HAnimHumanoid.skin?

Holger Seelig holger.seelig at yahoo.de
Tue Oct 31 13:56:10 PDT 2023


The specification is very clear at this point:
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/concepts.html#DEF_USE_Semantics

4.4.3 DEF/USE semantics

Node DEF names are limited in scope to a single X3D file, prototype definition, or string submitted to either CreateX3DFromString, CreateX3DFromStream, or CreateX3DFromURL X3D browser service (as specified in ISO/IEC 19775-2).

The USE statement does not create a copy of the node identified by a DEF name. Instead, the same node is inserted into the scene graph a second time, resulting in the node having multiple parents (see 4.3.5 Transformation hierarchy, for restrictions on self-referential nodes).

Node names shall be unique in the context within which the associated DEF name occurs.

Best regards,
Holger

--
Holger Seelig
Leipzig, Germany

holger.seelig at yahoo.de
https://create3000.github.io/x_ite/

> Am 31.10.2023 um 21:44 schrieb Joe D Williams <joedwil at earthlink.net>:
> 
> > To me, a definition is a DEF’ed field, and a USE field references the definition.  
>  
> The USE field creates a copy of the DEFed node at that location in the scenegraph. 
>  
> The general rule is that in the user code, DEF must appear before the USE. 
>  
> To x3d HAnim that (might) mean that the skin field must always appear before the skinCoord field. 
> However, the application in x3d HAnim is slightly different in that the skinCoord field could consist of selected points from geometry(s) of Segment nodes, or from one or several geometry(s) of the skin field. Or, who really knows all of what skinCoords may contain? So, likely that it turns out that the skinCoord is really not accessed until everything else is  done, then the actual skin field is built from data included or referenced by skinCoord.
>  
> More testing (only view3dscene tested here so far) needed please but when I have used code with skinCoord USE appearing before coord DEF all seemed to work without complaint. Maybe for this case the USE is not actually needed until well after the DEF is processed. 
>  
> Thanks,
> Joe
>  
> -----Original Message-----
> From: John Carlson <yottzumm at gmail.com>
> Sent: Oct 30, 2023 9:02 PM
> To: Joe D Williams <joedwil at earthlink.net>
> Cc: Brutzman Donald (Don) (CIV) <brutzman at nps.edu>, X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] What are valid children of HAnimHumanoid.skin?
> 
>  
> Hi Joe,
>  
> I don’t get how your example lines up with the standard Don quoted “The skin field contains one or more indexed mesh definitions. Those indexed mesh definitions utilize the point and normal data that is defined within the skinCoord and skinNormal fields, respectively, of the Humanoid object.”
>  
> Maybe I’m dumb?
>  
> Can we take it down to a high school level instead of PhD?
>  
> Look at the JoeKick link I posted separately, it follows your example.
>  
> Maybe the standards documentation could be clearer?  Maybe Don’s quote is from somewhere else?
>  
> AFAIK, Gramps now follows what you have below, but some versions may be reversed as we were trying to figure it out in the Blender exporter.
>  
> I don’t mind what is decided either way, and I would prefer your way and x3d.py to change, if it doesn’t support that order of output.  If I  seem a bit wishy-washy, it’s because I see that I am getting conflicting information, as far as I can tell.
>  
> We can go back to DAGs and inventing DEF/USE on the fly, but I thought we were past that, and now we’re just trying to define order of fields, and/or whether the verbage the standard should change.
>  
> To me, a definition is a DEF’ed field, and a USE field references the definition.  But I haven’t read any glossaries.
>  
> Thanks, I feel super dumb at this point.
>  
> John
> 
> On Mon, Oct 30, 2023 at 9:50 PM Joe D Williams <joedwil at earthlink.net <mailto:joedwil at earthlink.net>> wrote:
>> Hi John, 
>>  
>> skin [ 
>>  Shape {   
>>    geometry  IndexedFaceSet { 
>>     coord DEF TheSkinCoord Coordinate { point [ ... ] ... } } ]
>>  
>> then 
>>  
>> skinCoord USE TheSkinCoord 
>>  
>> So, not 
>> > "Yes, this means skinCoord DEF comes before skin Coordinate USE,"
>>   
>> actually  we want toDEF the coord Coordinate point then we can USE forskinCoord.
>>   
>> The only place I have seen these reversed is the code for Gramps you sent and it worked anyway.  
>>   
>>  Joe
>>  
>>  
>>  
>> -----Original Message-----
>> From: John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>>
>> Sent: Oct 30, 2023 6:27 PM
>> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu>>
>> Cc: X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>> Subject: Re: [x3d-public] What are valid children of HAnimHumanoid.skin?
>> 
>>  
>> Yes, this means skinCoord DEF comes before skin Coordinate USE, which is the information I was looking for.
>>  
>> At least this is my reading of the standard.
>>  
>> Joe, do you concur?  The next thing to do is look at what’s done in the archive.
>>  
>> Thanks,
>>  
>> John
>> 
>> On Mon, Oct 30, 2023 at 12:04 AM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>>> Please use latest url for X3D 4.0 Architecture:
>>> 
>>>  
>>> 
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/hanim.html#HAnimHumanoid
>>>  
>>> 
>>> HAnimHumanoid : X3DChildNode, X3DBoundedObject {
>>> 
>>>   […]
>>> 
>>>   MFNode [in,out] skin  []  [Group, LOD, Shape, Switch, Transform, IndexedFaceSet, IndexedFanSet, IndexedLineSet, IndexedQuadSet, IndexedTriangleSet, IndexedTriangleStripSet]
>>> 
>>>  
>>> 
>>> Further please note that the functional descriptions are provided in the HAnim 2.0 standard:
>>> 
>>>  
>>> 
>>> HAnim 2.0 Part 1:  Humanoid animation (HAnim) architecture, 6 Object interfaces, 6.2 Humanoid
>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Humanoid
>>>  
>>> 
>>> “The skin field contains one or more indexed mesh definitions. Those indexed mesh definitions utilize the point and normal data that is defined within the skinCoord and skinNormal fields, respectively, of the Humanoid object. This field is defined as an generic type for which the specific representation is defined by each binding to a presentation system. Annex C VRML binding <https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/VRMLInterface.html> contains a binding for VRML. Annex D X3D binding <https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/X3DInterface.html> describes the Humanoid animation component of X3D specified in ISO/IEC 19775-1 <https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/bibliography.html#I19775_1>.”
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 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 https://faculty.nps.edu/brutzman
>>> 
>>>  
>>> 
>>> From: x3d-public <x3d-public-bounces at web3d.org <mailto:x3d-public-bounces at web3d.org>> On Behalf Of GPU Group
>>> Sent: Sunday, October 29, 2023 5:56 AM
>>> To: John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>>
>>> Cc: X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>>> Subject: Re: [x3d-public] What are valid children of HAnimHumanoid.skin? argument for allowing containerFields in x3d.py
>>> 
>>>  
>>> 
>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimHumanoid 
>>> 
>>> - skin [IndexedFaceSet, X3DGroupingNode, Shape]
>>> 
>>> I haven't tried it but I don't see how freewrl could render a skin with bare IFS, it needs to be wrapped in at least a Shape, and HAnimHumanoid doesn't inherit from Shape
>>> 
>>> HAnimHumanoid : X3DChildNode, X3DBoundedObject 
>>>  
>>> 
>>> On Sun, Oct 29, 2023 at 6:45 AM GPU Group <gpugroup at gmail.com <mailto:gpugroup at gmail.com>> wrote:
>>> 
>>> xml with no containerField > freeWRL: Group and Transform, and today I added Shape.
>>> 
>>> Basically whatever ends up in that skin field, freewrl renders as normal scenegraph, so you can have a transform hierarchy of skin chunks / shapes and freewrl doesn't mind. (It's the skeleton and coordinate field that changes the shape of anything that uses the same coordinates, and the scene author presumes there's no weird transforms between chunks, but freewrl doesn't enforce that).
>>> 
>>> -Doug
>>> 
>>>  
>>> 
>>> On Sun, Oct 29, 2023 at 4:24 AM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>> 
>>> * I am specifically speaking of the lack of containerField in XML output from x3d.py.  I also have issues with overuse of the “children”container fields in VRML.  I am speaking of instances where view3dscene reports an error or does not show the scene (even trying tovrmlx3d would help).   The problem stems from lack of testing on HAnim VRML and XML outputs from x3d.py.  I could show Don an example, but he’s got a whole section of the archive devoted to examples which do show the same behavior when tested properly.
>>> 
>>>  
>>> 
>>> One cannot just type in “containerField” in a python program and expect x3d.py to list it in output.  I might be able to subclass, but that would require my own X3dToPython.xslt stylesheet.
>>> 
>>>  
>>> 
>>> * Skin/shape is another topic in the email.  See standard, where Shape is not mentioned under skin, rather, indexed mesh nodes are.  There is no children field under Shape, but there’s a skin field under HAnimHumanoid.  Skin has an MFNode field type, and has SFNode children,  AFAIK.  The question is whether these children should be Shapes or indexed meshes.
>>> 
>>>  
>>> 
>>> On Sat, Oct 28, 2023 at 2:16 PM Joe D Williams <joedwil at earthlink.net <mailto:joedwil at earthlink.net>> wrote:
>>> 
>>> > argument for allowing containerFields in x3d.py 
>>>  
>>> I don't understand. If no container fields then not able to do all of x3d. We had to use containerField for the admittedly rare instance where the default is not true. These are cases where looking up the containerField in schema is not enough. 
>>>  
>>> Some are tricky, like skeleton where only the root Joint has to have the containerField as skeleton. 
>>>  
>>> skin contains a Shape which does not have children.
>>>  
>>> However we are investigating the idea of  how to code LOD choices for skin. I think we already know how to do that for that for Segment geometry.  
>>>  
>>> Thanks,
>>> Joe
>>>  
>>>  
>>> -----Original Message-----
>>> From: John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>>
>>> Sent: Oct 26, 2023 10:08 AM
>>> To: Joe D Williams <joedwil at earthlink.net <mailto:joedwil at earthlink.net>>, X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>>> Subject: What are valid children of HAnimHumanoid.skin? argument for allowing containerFields in x3d.py
>>> 
>>>  
>>> From: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/hanim.html#HAnimHumanoid
>>> I see:
>>> MFNode     [in,out] skin                  []       [IndexedFaceSet, IndexedFanSet, IndexedQuadSet, IndexedTriangleSet, IndexedTriangleStripSet]
>>> And fromL https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Humanoid
>>> sequence<Object>   skin                  []           [indexed mesh objects as defined by the representation]
>>>  
>>> But in actual practice, I see:
>>>  
>>> <Shape DEF='Joe_Shape <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.html#Joe_Shape>' containerField='skin'>
>>> <Appearance DEF='Joe_skin_Appearance <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.html#Joe_skin_Appearance>'>
>>> 
>>> <Material DEF='Joe_skin_Material <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.html#Joe_skin_Material>' diffuseColor='0.3 0.3 0.6' emissiveColor='0.3 0.3 0.6'/>
>>> <ImageTexture DEF='JoeSkinImageTexture <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.html#JoeSkinImageTexture>'
>>>   url=' "JoeBodyTexture29.png  <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeBodyTexture29.png>" "https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JoeBodyTexture29.png  <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JoeBodyTexture29.png>" ' />
>>> 
>>> <!-- ROUTE information for KickTextureTransform node:  [from SkinInterpolator.value_changed to rotation  <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.html#ROUTE_194>] -->
>>> <TextureTransform DEF='KickTextureTransform <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.html#KickTextureTransform>'/>
>>> 
>>> </Appearance>
>>> 
>>>  
>>> 
>>> From:
>>> 
>>>  
>>> 
>>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKickIndex.html
>>> 
>>>  
>>> 
>>> And 
>>> 
>>>  
>>> 
>>> skin [
>>> 
>>>         DEF Joe_Shape Shape {
>>> 
>>>           appearance DEF Joe_skin_Appearance Appearance {
>>> 
>>>             material DEF Joe_skin_Material Material {
>>> 
>>>               diffuseColor 0.3 0.3 0.6
>>> 
>>>               emissiveColor 0.3 0.3 0.6
>>> 
>>>             }
>>> 
>>>             texture DEF JoeSkinImageTexture ImageTexture {
>>> 
>>>               url [ "JoeBodyTexture29.png" "https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JoeBodyTexture29.png" ]
>>> 
>>>             }
>>> 
>>>             textureTransform DEF KickTextureTransform TextureTransform {
>>> 
>>>             }
>>> 
>>>           }
>>> 
>>> ==================================================
>>> 
>>> So it would seem like Shapes with an Indexed geometry is what we're aiming for in the standard as one of the possibly many children of the skin container field (note the space).
>>> 
>>>  
>>> 
>>> That is all okay, AFAIAC, just extremely confusing when deciding where to add containerFields in DOM documents.
>>> 
>>>  
>>> 
>>>  
>>> 
>>> For example, consider the below:
>>> 
>>>  
>>> 
>>>                 <HAnimJoint USE='hanim_l_carpal_distal_interphalangeal_4'/>
>>> 
>>>                 <HAnimJoint USE='hanim_l_metacarpophalangeal_3'/>
>>> 
>>>                 <HAnimJoint USE='hanim_l_carpal_proximal_interphalangeal_3'/>
>>> 
>>>                 <HAnimJoint USE='hanim_l_carpal_distal_interphalangeal_3'/>
>>> 
>>>                 <HAnimJoint USE='hanim_l_metacarpophalangeal_2'/>
>>> 
>>>                 <HAnimJoint USE='hanim_l_carpal_proximal_interphalangeal_2'/>
>>> 
>>>                 <HAnimJoint USE='hanim_l_carpal_distal_interphalangeal_2'/>
>>> 
>>> [ etc. ]
>>> 
>>>  
>>> 
>>> It may not be apparent, but X3DJSAIL complains about this. There's no containerField='joints', right?  But I'm generating this code using x3d.py which doesn't allow me to list containerFields!
>>> 
>>>  
>>> 
>>> Grr!  Here are some of the "brutzman" messages from X3DJSAI, which are valid.  I really want to assign joints as a containerField, so perhaps I will just do it in X3DJSONLD.
>>> 
>>>  
>>> 
>>>     [apply] [error] X3DLoaderDOM: Parent-child node relationship not found! (parent HAnimHumanoid, child HAnimJoint, containerField='children') Please report this problem to brutzman at nps.edu <mailto:brutzman at nps.edu>
>>>     [apply] [error] X3DLoaderDOM: Parent-child node relationship not found! (parent HAnimHumanoid, child HAnimJoint, containerField='children') Please report this problem to brutzman at nps.edu <mailto:brutzman at nps.edu>
>>>     [apply] [error] X3DLoaderDOM: Parent-child node relationship not found! (parent HAnimHumanoid, child HAnimJoint, containerField='children') Please report this problem to brutzman at nps.edu <mailto:brutzman at nps.edu>
>>>     [apply] [error] X3DLoaderDOM: Parent-child node relationship not found! (parent HAnimHumanoid, child HAnimJoint, containerField='children') Please report this problem to brutzman at nps.edu <mailto:brutzman at nps.edu>
>>>     [apply] [error] X3DLoaderDOM: Parent-child node relationship not found! (parent HAnimHumanoid, child HAnimJoint, containerField='children') Please report this problem to brutzman at nps.edu <mailto:brutzman at nps.edu>
>>>     [apply] [error] X3DLoaderDOM: Parent-child node relationship not found! (parent HAnimHumanoid, child HAnimJoint, containerField='children') Please report this problem to brutzman at nps.edu <mailto:brutzman at nps.edu>
>>>     [apply] [error] X3DLoaderDOM: Parent-child node relationship not found! (parent HAnimHumanoid, child HAnimJoint, containerField='children') Please report this problem to brutzman at nps.edu <mailto:brutzman at nps.edu>
>>>     [apply] [error] X3DLoaderDOM: Parent-child node relationship not found! (parent HAnimHumanoid, child HAnimJoint, containerField='children') Please report this problem to brutzman at nps.edu <mailto:brutzman at nps.edu>
>>>  
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> 
>> 
>>  
> 
>  
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231031/d4c06f0c/attachment-0001.html>


More information about the x3d-public mailing list