[x3d-public] What are valid children of HAnimHumanoid.skin?
John Carlson
yottzumm at gmail.com
Mon Oct 30 23:05:50 PDT 2023
Actually, I reread and I’m lost again, sigh.
John
On Mon, Oct 30, 2023 at 11:45 PM John Carlson <yottzumm at gmail.com> wrote:
> Annex C: VRML Encoding seems to agree with what Don posted:
>
> “
>
> The geometry of an HAnim figure can be described in two ways. The first
> way is within the scene graph of the joint hierarchy, which is described in
> the *skeleton* field of the HAnimHumanoid node. Geometry defined within
> HAnimSegment nodes of this joint hierarchy describe the body as separate
> geometric pieces. This method, while computationally efficient, has certain
> visual anomalies (such as seams or creases) that detract from the
> appearance of the HAnim figure. The second way of describing the geometry
> of an HAnim figure is as a continuous piece of geometry, within the *skin*
> field of the HAnimHumanoid node. For this method, point and normal
> vector data sets are first defined in the *skinCoord* and *skinNormal* fields
> (in the form of Coordinate and Normal nodes, respectively). This data is
> defined in this manner to allow it to be referenced by two different
> entities within the definition of the HAnimHumanoid node. The first
> entity is one or more IndexedFaceSet nodes that define the surface of the
> geometry of the humanoid within the *skin* field. In most cases, this
> surface is a single IndexedFaceSet node. However, the surface can also be
> defined as multiple IndexedFaceSet nodes. It is possible that depending
> on the implementation of the IndexedFaceSet nodes and the configuration
> of the HAnim figure, multiple IndexedFaceSet nodes may provide better
> performance by isolating the continuous mesh changes to localized surfaces.”
>
> On Mon, Oct 30, 2023 at 11:01 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> 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
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231031/f732b03e/attachment-0001.html>
More information about the x3d-public
mailing list