[x3d-public] What are valid children of HAnimHumanoid.skin?
John Carlson
yottzumm at gmail.com
Tue Oct 31 10:39:50 PDT 2023
I don’t have any complaints about browsers reading my code. I have
problems with how x3d.py *generates* XML and VRML such that browsers won’t
handle joints fields before skeleton. If I USE more than one HAnimJoint
in the joints field, which is customary, then if x3d.py puts joints field
before skeleton, what hell is going to break loose if that code is used in
*any* x3d browser.
Please try to put your minds in a producer state of mind rather than
consumer state of mind. No producer in their right mind is going to want a
joints field before skeleton, even if it is possible.
I am arguing for a final decision about how fields are ordered in x3d.py,
but unfortunately this really possibly affects all fields of all nodes in
x3d.py. If a final decision is made, and I decide to use off-the-shelf
x3d.py, then I will have to put DEFs in the joints field, which I’m fairly
sure definitely violates the standard.
I’m just asking for changes to HAnimHumanoid in x3d.py
My guess is that this issue will come up again and again, and everyone will
have to edit either the x3d.py code, which is fairly easy, or modify the
stylesheet, which is mind-bending.
Once skeleton is placed before joints, we can then discuss
skin/skinCoord/skinNormal.
John
On Tue, Oct 31, 2023 at 11:00 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:
> > Date: Tue, 31 Oct 2023 14:03:11 +0100
> > From: Michalis Kamburelis <michalis.kambi at gmail.com>
> > To: GPU Group <gpugroup at gmail.com>
> > Cc: John Carlson <yottzumm at gmail.com>, X3D Graphics public mailing
> > list <x3d-public at web3d.org>
> > Subject: Re: [x3d-public] What are valid children of
> > HAnimHumanoid.skin?
> >
> > To be clear, CGE/view3dscene are the same as FreeWRL in this regard.
> (And I
> > can bet all other X3D browsers :) )
>
> x3dom does the same as well and treats HAnim nodes the same as all
> other X3D nodes with respect to DEF/USE. Strictly speaking, the
> ordering used is defined by the DOM hierarchy, eg. descendants of a
> first node come before a second node (and its descendants) following
> the first node. But this ordering exactly corresponds to the textual
> sequence in the encoding and it is conceptually easier to just follow
> the source code top to bottom, left to right (although there are other
> traditions/conventions).
>
> So there is no requirement to use USE references anywhere including in
> 'joints' field values but it is the sensible setup for all actual
> models. As Michalis indicates it would be actually awkward to
> distinguish between USE and DEF nodes since USE nodes become the
> 'physical' DEF node before HAnim nodes are processed, eg. there is no
> memory of them being originally a reference.
>
> -Andreas
>
> > In the end, it doesn't matter whether you write:
> >
> > """
> > SomeNode {
> > field1 DEF MyShape Shape { }
> > field2 USE MyShape
> > }
> > """
> >
> > or
> >
> > """
> > SomeNode {
> > field2 DEF MyShape Shape { }
> > field1 USE MyShape
> > }
> > """
> >
> > ( In the above examples, field1 and field2 order differs. )
> >
> > These both result in the exact same X3D nodes graph, exact same behavior,
> > which follows X3D specification from what I can tell, and I think this
> > matches what all X3D browsers are doing.
> >
> > I know the H-Anim specification has a wording that suggests that some
> > fields should use USE to refer to already defined node. You can interpret
> > the phrase in
> >
> https://www.web3d.org/documents/specifications/19774-1/V2.0/Architecture/ObjectInterfaces.html#Humanoid
> > """The joints field contains a list of references, one for each Joint
> > object defined within the skeleton field hierarchy of the Humanoid
> > object""" to indicate that e.g. joints should always be expressed as a
> list
> > of "USE xxx" declarations, and they usually are.
> >
> > But in CGE/view3dscene, we relax this requirement (it would be odd to
> even
> > try to check it, since in general in X3D it should not matter). All it
> > matters is that "joints" are the same nodes as used within "skeleton"
> > hierarchy. You are welcome to specify either field as first, just make
> sure
> > that first node occurrence is DEF, and the other occurrences are USE.
> >
> > Hope this also helps with issue John submitted (
> > https://github.com/castle-engine/view3dscene/issues/83 ).
> >
> > Regards,
> > Michalis
> >
> >
> >
> > wt., 31 pa? 2023 o 13:49 GPU Group <gpugroup at gmail.com> napisa?(a):
> >
> > > In freewrl it doesn't matter which field skin (and children Shapes) or
> > > skinCoord comes first, as long as the first one in the scene file has
> the
> > > Coordinate DEF (and following ones have Coordinate USE). Once parsed
> into a
> > > scenegraph, both skinCoord and skin shapes refer to the same node
> instance
> > > in memory.
> > >
> > >
> > > On Tue, Oct 31, 2023 at 12:07?AM John Carlson <yottzumm at gmail.com>
> wrote:
> > >
> > >> 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
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>> _______________________________________________
> > >> 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/f74690c0/attachment.html
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
> > ------------------------------
> >
> > End of x3d-public Digest, Vol 175, Issue 117
> > ********************************************
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> 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/9c30eaa4/attachment-0001.html>
More information about the x3d-public
mailing list