[x3d-public] HAnim only skeleton renderable ?
Andreas Plesch
andreasplesch at gmail.com
Wed Jun 20 11:20:43 PDT 2018
Hi Don,
On Wed, Jun 20, 2018, 9:29 AM Don Brutzman <brutzman at nps.edu> wrote:
> [copied: Humanoid Animation (HAnim) Working Group h-anim at web3d.org]
>
> Thanks for asking this important question. Those fields you've identified
> are not rendered. They are provided so that tools might have a convenient
> list of references occurring throughout the skeleton, thus facilitating
> automatic techniques.
>
It would be helpful to clearly state that the content of these fields is
not rendered, perhaps in the tooltips.
> Critical reference: HAnim Draft International Standard (DIS) submitted to
> ISO, available on web3D website.
>
>
> =========================================================================================
>
> All H-Anim Standards
> http://www.web3d.org/standards/h-anim
>
> 19774-1 ISO/IEC DIS 19774-1 V2.0 Humanoid Animation
> (H-Anim) : Architecture
> http://www.web3d.org/documents/specifications/19774-1/V2.0/
>
> 6.2 Humanoid
>
> http://www.web3d.org/documents/specifications/19774-1/V2.0/HAnim/ObjectInterfaces.html#Humanoid
> [...]
>
> The skeleton field contains the humanoid_root Joint object. The Humanoid
> object is considered the parent object of the humanoid_root Joint object
> and defines a coordinate space for the humanoid_root Joint object. Thus,
> the Humanoid object's transformation affects the Joint object hierarchy in
> the skeleton field. A hierarchy of Joint objects is defined for each H-Anim
> humanoid figure within the skeleton field of the Humanoid object and a
> hierarchical definition of joints is present even when the geometry of the
> humanoid figure is not defined within the skeleton field. The skeleton
> field can also contain zero or more Site objects which allow landmarks to
> be established with respect to the overall humanoid figure, but which are
> not affected by the movement of any of the Joint objects.
>
> The joints field contains a list of references, one for each Joint object
> defined within the skeleton field hierarchy of the Humanoid object. The
> order in which the joints are listed is irrelevant since the names of the
> joints are stored in the Joint objects themselves.
>
I saw that but the language did not help in deciding if these lists should
be rendered, especially after examining how examples use USE for
referencing.
The larger question is if these fields are really helpful since they do not
add information and require manual syncing. Tools can extract these lists
from skeleton, and would need to if these fields are not provided or left
at default values.
> The segments field contains a list of references, one for each Segment
> object defined within the skeleton field hierarchy of the Humanoid object.
> The order in which the segments are listed is irrelevant since the names of
> the segments are stored in the Segment objects themselves.
>
> The sites field contains a list of references, one for each Site object
> defined within the skeleton field hierarchy of the Humanoid object. The
> order in which the sites are listed is irrelevant since the names of the
> sites are stored in the Site objects themselves.
>
> The references to contained Joint, Segment and Site objects may be used to
> support inverse kinematics (IK) and other motion tools animating nodes
> found within the skeleton field.
>
>
> =========================================================================================
> Informational reference: X3D Tooltips, HAnimHumanoid
>
> http://www.web3d.org/x3d/tooltips/X3dTooltips.html#HAnimHumanoid
> HAnimHumanoid [inherits X3DChildNode, implements X3DBoundedObject]
> The HAnimHumanoid node is used to: (a) store references to the joints,
> segments, sites, skeleton, optional skin, and fixed viewpoints, (b) serve
> as a container for the entire humanoid, (c) provide a convenient way of
> moving the humanoid through its environment, and (d) store human-readable
> metadata such as name, version, author, copyright, age, gender and other
> information. HAnimHumanoid contains a skeleton consisting of HAnimJoint,
> HAnimSegment and HAnimSite nodes. HAnimHumanoid can also contain an
> optional skin consisting of an IndexedFaceSet mesh with corresponding
> skinCoord Coordinate|CoordinateDouble vertices and skinNormal Normal
> vectors.
> Hint: MFNode arrays for the joints, segments, sites, and viewpoints fields
> provide lists for all HAnim nodes found in the skeleton hierarchy and thus
> only contain USE node references.
> Hint: H-Anim Specification
> http://www.web3d.org/documents/specifications/19774-1/V2.0/HAnim/HAnimArchitecture.html
> Hint: H-Anim Specification, Humanoid
> http://www.web3d.org/documents/specifications/19774-1/V2.0/HAnim/ObjectInterfaces.html#Humanoid
> Hint: X3D for Advanced Modeling (X3D4AM) slideset
> http://x3dgraphics.com/slidesets/X3dForAdvancedModeling/HumanoidAnimation.pdf
> Warning: requires X3D profile='Full' or else include <component
> name='H-Anim' level='1'/>
>
>
> =========================================================================================
> http://www.web3d.org/x3d/tooltips/X3dTooltips.html#HAnimHumanoid.joints
> [joints accessType inputOutput, type MFNode array, empty list] [HAnimJoint]
> The joints field contains a list of USE references for all HAnimJoint node
> instances found within the preceding skeleton hierarchy.
> Hint: order is irrelevant since names are contained in the original DEF
> objects.
> Hint: these USE nodes can be utilitized by inverse kinematics (IK) and
> animation engines.
> Warning: the number of contained <HAnimJoint USE='*'
> containerField='joints'/> nodes at top level of HAnimHumanoid needs to
> match the number of corresponding HAnimJoint node instances found within
> the preceding skeleton hierarchy.
> Warning: top-level HAnimJoint USE nodes must include
> containerField='joints' for proper validation and operation.
>
>
> =========================================================================================
> http://www.web3d.org/x3d/tooltips/X3dTooltips.html#HAnimHumanoid.segments
> [segments accessType inputOutput, type MFNode array, empty list]
> [HAnimSegment]
> The segments field contains a list of USE references for all HAnimSegment
> node instances found within the preceding skeleton hierarchy.
> Hint: order is irrelevant since names are contained in the original DEF
> objects.
> Hint: these USE nodes can be utilitized by inverse kinematics (IK) and
> animation engines.
> Warning: the number of contained <HAnimSegment USE='*'
> containerField='segments'/> nodes at top level of HAnimHumanoid needs to
> match the number of corresponding HAnimSegment node instances found within
> the preceding skeleton hierarchy.
> Warning: top-level HAnimSegment USE nodes must include
> containerField='segments' for proper validation and operation.
>
>
> =========================================================================================
> http://www.web3d.org/x3d/tooltips/X3dTooltips.html#HAnimHumanoid.sites
> [sites accessType inputOutput, type MFNode array, empty list] [HAnimSite]
> sites field contains a list of USE references for all HAnimSite node
> instances found within the preceding skeleton hierarchy.
> Hint: order is irrelevant since names are contained in the original DEF
> objects.
> Hint: these USE nodes can be utilitized by inverse kinematics (IK) and
> animation engines.
> Warning: the number of contained <HAnimSite USE='*' containerField='sites,
> skeleton or viewpoints'/> nodes at top level of HAnimHumanoid needs to
> match the number of corresponding HAnimSite node instances found within the
> preceding skeleton hierarchy.
> Warning: top-level HAnimSite USE nodes must include containerField='sites'
> for proper validation and operation.
>
>
> =========================================================================================
> http://www.web3d.org/x3d/tooltips/X3dTooltips.html#HAnimHumanoid.viewpoints
> [viewpoints accessType inputOutput, type MFNode array, empty list]
> [HAnimSite]
> List of HAnimSite nodes containing Viewpoint nodes that appear in the
> skeleton model, usually as USE node references. The viewpoints field
> contains zero or more special HAnimSite nodes that are only affected by
> HAnimHumanoid transformations (and no HAnimJoint transformations). Each
> HAnimSite can contain a Viewpoint as virtual camera in the HAnimHumanoid
> reference frame (such as viewing the face or profile of the human figure).
> Warning: these are actual node declarations, not USE nodes.
> Hint: the viewpoint field has different functionality than the joints,
> segments and sites fields.
> Hint: the viewpoints field connects internal Site nodes that in turn hold
> relative Viewpoint nodes, such as <HAnimSite USE='ObserveFaceSite_view'
> containerField='viewpoints'/> which has corresponding counterpart nodes
> <HAnimSite DEF='ObserveFaceSite_view' name='ObserveFaceSite_view'
> containerField='children'> <Viewpoint description='look at me!'/>
> </HAnimSite>.
> Warning: top-level HAnimSite nodes (in turn containing Viewpoint nodes)
> must include containerField='viewpoints' for proper validation and
> operation.
>
>
> =========================================================================================
>
> Completion of this new draft integrates years of work and is very recent.
> The X3D v4.0 Working Draft Specification (on github for Web3D members) has
> also been updated to match, providing the first component revision for X3D
> v4.0.
>
> Validation tools in X3D XML Schema, DTD, X3DUOM and X3DJSAIL are also
> updated. Pending improvements to match recent refinements include X3D JSON
> Encoding, X3D-Edit and
>
> X3D Example Archives: Basic, Humanoid Animation
> http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation
>
> X3D Example Archives: X3D for Advanced Modeling, Motion Animation
> http://x3dgraphics.com/examples/X3dForAdvancedModeling/MotionAnimation
>
> X3D Example Archives: X3D for Advanced Modeling, Shay D Pixel
> http://x3dgraphics.com/examples/X3dForAdvancedModeling/ShayDPixel
>
> The HAnim working group meets regularly to discuss improvements and
> progress. Looking forward to help tune example scenes, strengthen
> validation tests, and supporting your implementation.
>
I may make some example scenes x3dom compatible, by removing or replacing
unsupported nodes unrelated to HAnim.
Andreas
>
> v/r Don
>
>
> On 6/20/2018 5:15 AM, Andreas Plesch wrote:
> > Hi Joe,
> >
> > ok. Most of the HAnim scenes in the web3d examples archive probably
> populate these fields with USE references. My vague sense is that they do
> that only out of a perception that this is required or recommended, not for
> a functional purpose, but I did not go through those in detail.
> >
> > I will see if and how it is possible to special case the nodes in these
> fields in x3dom, perhaps by removing them from the list of drawable objects.
> >
> > On a spec. tangent, 19774-2/V2.0 Annex B, here
> >
> >
> http://www.web3d.org/documents/specifications/19774-2/V2.0/MotionDataAnimation/ExampleKeyframeAnimation.html
> >
> > and 19774-1/V2.0 Annex F
> >
> >
> http://www.web3d.org/documents/specifications/19774-1/V2.0/HAnim/Design.html
> >
> > define a containerField='skeleton' for the example Humanoid whose parent
> is the Scene. This is probably an editing oversight.
> >
> > -Andreas
> >
> >
> > On Tue, Jun 19, 2018 at 6:52 PM Joseph D Williams <joedwil at earthlink.net
> <mailto:joedwil at earthlink.net>> wrote:
> >
> > * So my question is if only the nodes in the skeleton field should
> be____
> >
> > rendered while the USE references in the joints and segments
> fields____
> >
> > should not be rendered and are provided exclusively for other
> purposes____
> >
> > (like kinematics) ? I could not quite answer that question from
> the____
> >
> > standard language.
> >
> > __ __
> >
> > Forget these fields they are leftovers from when the skeleton was
> not included in the user code and the fields just defined which of the
> skeleton parts in the ‘standard’ model that was not even accessible to the
> actual user, these fields were all he got to author, and some animation.
> >
> > Anyway, unless somebody can clearly show the need for these, then
> should be dumped, and never treated as required. When it became feasible to
> permit the skeleton into the actual user code, these fields became excess
> but for some reason nobody will delete them.
> >
> > __ __
> >
> > Thanks again,
> >
> > Joe
> >
> > __ __
> >
> > __ __
> >
> > *From: *Andreas Plesch <mailto:andreasplesch at gmail.com>
> > *Sent: *Tuesday, June 19, 2018 5:35 AM
> > *To: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
> > *Subject: *[x3d-public] HAnim only skeleton renderable ?
> >
> > __ __
> >
> > In my first attempt to improve the implemention of HAnim nodes and
> >
> > fields in x3dom, most (all?) shapes making up the Nancy humanoid from
> >
> > Nancy, native tags, were rendered multiple times, on top of each
> >
> > other.
> >
> > The reason turned out to be the USE references in the joints and
> >
> > segments field of Humanoid.
> >
> > Since a USE node places another instance of a DEF node into the scene
> >
> > graph, all the Shapes in the joint and segment nodes were duplicated.
> >
> > __ __
> >
> > So my question is if only the nodes in the skeleton field should be
> >
> > rendered while the USE references in the joints and segments fields
> >
> > should not be rendered and are provided exclusively for other
> purposes
> >
> > (like kinematics) ? I could not quite answer that question from the
> >
> > standard language.
> >
> > __ __
> >
> > -Andreas
> >
> > __ __
> >
> > --
> >
> > Andreas Plesch
> >
> > Waltham, MA 02453
> >
> > __ __
> >
> > _______________________________________________
> >
> > x3d-public mailing list
> >
> > x3d-public at web3d.org <mailto:x3d-public at web3d.org>
> >
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> > __ __
> >
> >
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
> >
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
>
>
> 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
> http://faculty.nps.edu/brutzman
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180620/f7378e74/attachment-0001.html>
More information about the x3d-public
mailing list