[x3d-public] What are valid children of HAnimHumanoid.skin?
John Carlson
yottzumm at gmail.com
Tue Oct 31 16:25:43 PDT 2023
I agree Joe! The HAnimMotion joints is much more reasonable. joints should
be MFString, not MFNode.
On Tue, Oct 31, 2023 at 4:55 PM Joe D Williams <joedwil at earthlink.net>
wrote:
> me too Holger.
>
> Not a copy but the actual DEFed node. Can result in same node with
> multiple parents.
>
> Also, the scope is important.
>
> Also the order of appearance is important.
>
> However, the HAnim DEF/USE for the skinCoord seems to be slightly
> different.
>
> I'm not sure how different it is for the coord DEF and theskinCoord USE
> but I observed view3dscene to work with the skinCoord USE before the coord
> DEF.
>
>
>
> Also different is the use of USE in joints field. Can the joints field
> appear before the skeleton field?
>
> Anyway, I am still convinced that the joints field is not specified
> correctly. The naming conventions are strict enough in HAnim that the
> joints field only needs to contain list of each Joint name attribute, that
> is just a simple list of Joint names instead of the USE. By the spec if you
> know the name of the Joint and the name of the Humanoid, then you
> can determine the DEF string. What does any browser do with the list of USE
> strings in the joints field? To me the list of USEs is just confusing.
>
>
>
> Thanks,
>
> Joe
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: John Carlson <yottzumm at gmail.com>
> Sent: Oct 31, 2023 2:28 PM
> To: Holger Seelig <holger.seelig at yahoo.de>
> Cc: Joe D Williams <joedwil at earthlink.net>, X3D <x3d-public at web3d.org>
> Subject: Re: [x3d-public] What are valid children of HAnimHumanoid.skin?
>
>
> 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/21d6c19c/attachment-0001.html>
More information about the x3d-public
mailing list