[x3d-public] What are valid children of HAnimHumanoid.skin?
John Carlson
yottzumm at gmail.com
Tue Oct 31 14:28:16 PDT 2023
Thanks, Holger, I concur.
On Tue, Oct 31, 2023 at 3:56 PM Holger Seelig <holger.seelig at yahoo.de>
wrote:
> 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>
> 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>
>> Sent: Oct 30, 2023 6:27 PM
>> To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> Cc: X3D Graphics public mailing list <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> 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
>>>
>>> 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> *On Behalf Of *GPU
>>> Group
>>> *Sent:* Sunday, October 29, 2023 5:56 AM
>>> *To:* John Carlson <yottzumm at gmail.com>
>>> *Cc:* X3D Graphics public mailing list <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> 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> 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>
>>> 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>
>>> Sent: Oct 26, 2023 10:08 AM
>>> To: Joe D Williams <joedwil at earthlink.net>, X3D Graphics public mailing
>>> list <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
>>>
>>> [apply] [error] X3DLoaderDOM: Parent-child node relationship not
>>> found! (parent HAnimHumanoid, child HAnimJoint, containerField='children')
>>> Please report this problem to 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
>>>
>>> [apply] [error] X3DLoaderDOM: Parent-child node relationship not
>>> found! (parent HAnimHumanoid, child HAnimJoint, containerField='children')
>>> Please report this problem to 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
>>>
>>> [apply] [error] X3DLoaderDOM: Parent-child node relationship not
>>> found! (parent HAnimHumanoid, child HAnimJoint, containerField='children')
>>> Please report this problem to 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
>>>
>>> [apply] [error] X3DLoaderDOM: Parent-child node relationship not
>>> found! (parent HAnimHumanoid, child HAnimJoint, containerField='children')
>>> Please report this problem to brutzman at nps.edu
>>>
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> 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/9d0b035e/attachment-0001.html>
More information about the x3d-public
mailing list