[x3d-public] Tiered design for skeleton, skin, coveroids

Don Brutzman don.brutzman at gmail.com
Wed Nov 12 21:39:20 PST 2025


[corrected copy with proper paragraph lettering, please ignore the prior
version.]

Joe and everyone:  Dick and I accepted the challenge today to try defining
a Coveroid object. Speculative specification prose follows.

Carol: no doubt there are more to come, but it is looking like we are
handling a great many of your requirements.

This is a good topic for next Monday's specification discussion.

   - HAnim Architecture v2.1 draft, clause 6 Object interfaces, *6.x
   Coveroid*
   <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Coveroid>
   -
   https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Coveroid

[Editors' note: this design section is speculative and intended to promote
> focused consideration. See email thread [hanim] Tiered design for
> skeleton, skin, coveroids
> <https://web3d.org/mailman/private/h-anim_web3d.org/2025-November/002541.html>
> .]
>


> *interface Coveroid {*

  <Object> metadata            # name, identifier, provenance, package
> contents, etc.
>
  sequence<Object> skeleton [] [*Joint*, *Site*] # includes Shape geometry
> with mesh indices
>
  sequence<Object> skin     [] [indexed mesh objects as defined by the
> representation]
>   integer loa               -1 [-1,4]
>   # other fields found in Humanoid that are deemed necessary

*}*


> Tentative goal: can we define requirements for a single tier that collects
> requirements for a Coveroid object, mimicking Humanoid object design, and
> primarily adapting other existing HAnim nodes wherever possible?
>


Such a new object appears to be necessary for modeling clarity, and
> packaging together all needed information, in order to meet use-case design
> requirements. Candidate characteristics follow.
>
>    1. Multiple Coveroid objects might be attached as tiers in the Humanoid
>     object *coveroids* field.
>    2. A Coveroid object can be modeled, rendered, and exchanged
>    independently without being contained within a Humanoid object
>    *coveroids* field.
>    3. Minimum essential metadata must be included in order to meet
>    interoperability and reusability requirements.
>    4. Can we allow both "skeletal" shapes and mesh-based "skin" such that
>    each has potential connections to a humanoid *skeleton*, or else be
>    independent and renderable as standalone models? Supporting both
>    correspondences and separability enables attach/detach portability.
>    5. Including an optional *loa* field can indicate whether
>    correspondence points found in an underlying Humanoid object with
>    similar (or higher) *loa* can be utilized.  (Perhaps matching labels
>    in *skeletalConfiguration* field as well.)
>    6. Can Site objects provide potential connections to an corresponding
>    Humanoid object, if available, perhaps through identical pairwise
>    *name* values and shared naming conventions for respective Joint,
>    Segment and Site objects?
>    7. Are other geometric representations needed, beyond individual
>    pieces of Joint-Segment geometry and overall skin-oriented indexed meshes?
>    (If we can achieve a similar design, then HAnim software implementations
>    are simpler to achieve since models will have a consistent design pattern
>    to follow.)
>    8. We need to continue carefully reviewing the design requirements of 4.2.3
>    Tiered design for skeleton, skin, coveroids
>    <http://concepts.html/#TieredDesign> in order to add further fields to
>    Coveroid object (as necessary) with corresponding functionality
>    definitions.
>    9. Once we have a consistent design principles emerging, need to look
>    at Humanoid
>    <https://mail.google.com/mail/u/0/#m_7386264980568717178_m_1010625822353646373_Humanoid>
>    , Joint
>    <https://mail.google.com/mail/u/0/#m_7386264980568717178_m_1010625822353646373_Joint>
>    , Segment
>    <https://mail.google.com/mail/u/0/#m_7386264980568717178_m_1010625822353646373_Segment>,
>    and Site
>    <https://mail.google.com/mail/u/0/#m_7386264980568717178_m_1010625822353646373_Site> clauses
>    to see what additional semantic functionality needs to be defined.
>    10. Is Tier object a better name than Coveroid object?
>    11. What other capabilities need to be listed here?
>
> Quote for today:

   - *"What are you working on?  What's the most important problem in your
   area?  Why aren't they the same?" *
   - Richard Wesley Hamming (1915-1998)
   - from biography Richard Wesley Hamming: Man, Mathematician, Mentor
   <https://richardwesleyhamming.com/> by Martin Mandelberg, published 2025

all the best, Don
-- 
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting  https://RelativeMotion.info


> On Tue, Nov 11, 2025 at 9:30 AM Don Brutzman <don.brutzman at gmail.com>
> wrote:
>
>> Thanks 1M Joe for these excellent thoughts, and also for a productive
>> group dialog yesterday.  Our updated design goals from yesterday's weekly
>> meeting can be found at
>>
>>    - HAnim architecture draft v2.1, clause 4 Concepts, 4.2.3 Tiered
>>    design for skeleton, skin, coveroids
>>    <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/concepts.html#TieredDesign>
>>
>> I agree with your reasoning that an author building a coveroid ought to
>> be able to use either Shape geometry (as occurs in the Humanoid
>> *skeleton* field), a morphable mesh (similar to the Humanoid *skin *field),
>> or both.  Then add Site nodes to define locations for specific
>> functionality, including connection points.  This design pattern already
>> works for Humanoid... for example
>>
>>    - Joe Skeleton Skin Site Salute Walk
>>    <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeSkeletonSkinSiteSaluteWalkIndex.html>
>>
>> Searching for "coveroid" - the following article is also interesting,
>> reinforced by Carol McDonald's multiple contributions.
>>
>>    - IEEE SA - How Can the Internet of Clothing Benefit Our Wellbeing
>>    and Environment?
>>    <https://standards.ieee.org/beyond-standards/industry/retail/how-can-the-internet-of-clothing-benefit-our-wellbeing-and-environment/>
>>    - Innovations in Wearable Technology Allow Brands and Consumers to
>>    Reimagine The Future of Clothing
>>    - IEEE Standards Association (SA), 2 SEP 2022
>>
>> particularly
>>
>> *Four Fundamental Components of the Internet of Clothing*
>>> IoC is enabling new ways for consumers to interact with and benefit from
>>> their clothing, as well as creating new ways for brands to reach them. And
>>> data is at the heart of the ecosystem.
>>
>>
>>
>> A white paper from the IEEE SA 3D Body Processing Industry Connections
>>> (IC) Activity
>>> <https://standards.ieee.org/industry-connections/3d/bodyprocessing/> outlines
>>> four interconnected components of the data transfer system – human,
>>> humanoid, cover, and coveroid:
>>
>>
>>
>>
>>>    - The human refers to the actual person who wears the piece of
>>>    clothing or footwear while the humanoid is a digital representation
>>>    of the human, such as measurement data sets, dress forms, mannequins, or
>>>    statues. The humanoid is used in the development of the product and is
>>>    created by manual measurement, 3D body scanning of a human, 3D point cloud
>>>    data (PCD) of a human, algorithms, population data, or any combination of
>>>    these.
>>>
>>>
>>>    - The cover is anything that a human wears on or above the skin.
>>>    Covers can be an outfit, multiple layers, or a single garment. When
>>>    creating the product, manufacturers use a coveroid, which is a
>>>    physical or digital representative of a cover. Coveroids can be created
>>>    from physical or virtual measurement data, 3D cover scan data, cover point
>>>    cloud data, visual algorithm, material algorithm, or a combination of these.
>>>
>>> The body data comes from humans, such as the body temperature, and then
>>> it is transferred to the humanoid, coveroid, and cover. These four
>>> fundamental components work together to form a framework of data sharing
>>> within the IoC ecosystem.
>>
>>
>> It sure seems like the more we examine these IEEE 3DBP concepts from an
>> HAnim specification perspective, the more adaptable and integratable they
>> seem.  Step by step...
>>
>> So far we have resisted the creation of a new node in HAnim Architecture,
>> finding that most of the needed functionality can be implemented using
>> existing HAnim nodes.
>>
>> Nevertheless, since outer tiers might have single or multiple coveroids,
>> defining an HAnim Coveroid node would let us encapsulate needed
>> functionality and corresponding metadata in a single package.  This can
>> also facilitate independent creation of a Coveroid object with later
>> attachment to (or disconnection from) a Humanoid object.
>>
>> Hmmm.... thoughts please:
>>
>>    - Why don't we try to define a Coveroid object, which attempts to
>>    meet these many requirements, and which can be separately created/shared
>>    then eventually collected as outer tiers attached to a Humanoid
>>     object.
>>
>> all the best, Don
>> --
>> X3D Graphics, Maritime Robotics, Distributed Simulation
>> Relative Motion Consulting  https://RelativeMotion.info
>>
>>
>> On Mon, Nov 10, 2025 at 10:15 AM Joe D Williams <joedwil at earthlink.net>
>> wrote:
>>
>>> > Any more requirements?
>>>
>>>
>>>
>>> The tiers need subsets for various levels of functionality.
>>>
>>> From simple 'costume fitment' garments with few binding points
>>>
>>> for coveroid to skeleton, up to a 'purchase fitment' coveroid
>>>
>>> with complete enough data for a realistic test/purchase/deliver
>>>
>>> process.
>>>
>>>
>>>
>>> Also, the coveroid may be a collection of Segment geometry
>>>
>>> corresponding to the x3d Level 1, or be the x3d Level 2
>>>
>>> which includes skeleton-driven skin, and various Displacers.
>>>
>>>
>>>
>>> The top-level model Coveroid will be as smart, maybe smarter,
>>>
>>> than the Humanoid because for physical delivery, it is still the
>>>
>>> provider guaranteeing the fit. The Humanoid will have
>>>
>>> to provide all the fitting information the Coveroid needs to decide
>>>
>>> how to incorporate the Coveroid. Then the Humanoid must
>>>
>>> evaluate and accept. Then there is the case where the Humanoid
>>>
>>> obtain a certain digital piece and do the fitment using other
>>>
>>> personal authorship tools.
>>>
>>>
>>>
>>> So, seems like there needs to be a common set of requirements
>>>
>>> for the Humanoid and the Coveroid, so the both oids can integrate.
>>>
>>> So the Humanoid goes in and picks a garment and the store says,
>>>
>>> "Sorry, you don't currently include sufficient Sensors and Actuators
>>>
>>> to try that on. Can we interest you in a selection from this simpler set,
>>>
>>> or can you jaunt to the Upgrade Suite?"
>>>
>>>
>>>
>>> Thanks and Fun with Coveroids,
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Nov 9, 2025 at 8:55 PM Don Brutzman <don.brutzman at gmail.com>
>>> wrote:
>>>
>>>> Given our recent positive experiences with HAnimHumanoid re-use in X3D,
>>>> have appended an additional design requirement.  This seems similarly
>>>> do-able.
>>>>
>>>>
>>>> l. The X3D Architecture implementation of HAnim Architecture allows
>>>> repeatable use of HAnimHumanoid nodes when EXPORT [AS] exposes it from
>>>> one file, and Inline, IMPORT [AS] and then USE retrieve the
>>>> HAnimHumanoid node in another file. Similar mechanisms need to be
>>>> possible for scalable re-use and animation of clothing and coveroid models.
>>>>
>>>>
>>>> all the best, Don
>>>> --
>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>> Relative Motion Consulting  https://RelativeMotion.info
>>>>
>>>> On Fri, Nov 7, 2025 at 3:14 PM Don Brutzman <don.brutzman at gmail.com>
>>>> wrote:
>>>>
>>>>> Dick and I took a good round turn
>>>>> <https://en.wiktionary.org/wiki/Appendix:Glossary_of_U.S._Navy_slang#:~:text=Round%20Turn>
>>>>> today on draft HAnim v2.1 spec design considerations for clothing, building
>>>>> on the list we reviewed together last Monday.
>>>>>
>>>>>    - HAnim Architecture, draft v2.1, section 4 Concepts, 4.2.3 Tiered
>>>>>    design for internal organs, skeleton, skin, coveroids
>>>>>    -
>>>>>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/concepts.html#TieredDesign
>>>>>
>>>>> 4.2.3 Tiered design for internal organs, skeleton, skin, coveroids
>>>>>
>>>>> Editors notes:
>>>>>
>>>>>    - Need to describe overall design for Humanoid to have multiple
>>>>>    tiers, so that layers of clothing can be added compatibly outside a human
>>>>>    body.
>>>>>    - This tiered approach starts with internal organs and musculature
>>>>>    (someday when ready), then skeleton, then skin, then coveroids...
>>>>>    - Conceivably this design will integrate well as a *coveroids* field
>>>>>    for Humanoid
>>>>>    <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Humanoid>
>>>>>     object.
>>>>>
>>>>> Terminology:
>>>>>
>>>>>    - Tier <https://simple.wiktionary.org/wiki/tier> is excellent new
>>>>>    term to use, since we already have existing definitions for layers and
>>>>>    levels.
>>>>>    - We use the term "coveroids" for the outermost tiers, also for
>>>>>    name of an ordered array field in Humanoid.
>>>>>    - We hesitate to use the term "clothing" as a field name because
>>>>>    it might be too limiting with respect to possible usage (e.g. suit of
>>>>>    armor, artificial exoskeleton) and also because we need to consider
>>>>>    non-human use cases.
>>>>>    - Nevertheless "clothes" and "clothing" remain candidate
>>>>>    terminology for some cases, e.g. OED definition "clothes are items worn to
>>>>>    cover the body."
>>>>>
>>>>> Design goals and requirements include:
>>>>>
>>>>>    1. Current tiers of interest are skeleton, skin, and coveroids.
>>>>>    Deferred as candidate future tiers: internal organs, musculature, and
>>>>>    (potentially) a specific facial model.
>>>>>    2. Each tier must be rendered in the correct order, from inside to
>>>>>    outside.
>>>>>    3. It must be possible to independently select which tiers are
>>>>>    active in the current model.
>>>>>    4. Can Joint objects be used as root node for each tier (e.g.
>>>>>    layer of clothing) or is a new node needed? If possible, for both
>>>>>    implementation complexity and author understanding, it is preferable to
>>>>>    *not* add new nodes to the specification.
>>>>>    5. How do we handle meshes for coveroids? Similar to skin, authors
>>>>>    may prefer Segment-based geometry or mesh changes or both. If design ends
>>>>>    up being sufficiently similar, might we modify and refactor the existing
>>>>>    *skin* field to be a list of meshes for each of tiers?
>>>>>    Alternatively, it may be more object-oriented to keep each mesh
>>>>>    encapsulated in each individual tier.
>>>>>    6. To support such an approach for coveroids and other tiers,
>>>>>    might we add *visible* field to Joint
>>>>>    <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Joint>
>>>>>     and Segment
>>>>>    <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Segment> objects,
>>>>>    in order to facilitate making blocks of geometry (and all related children)
>>>>>    nonvisible and inactive? Correspondingly ought we create a boolean array
>>>>>    for visibility in Humanoid object? (A similar approach using a
>>>>>    boolean array already exists for Motion node, however note that when
>>>>>    implemented in X3D that requires authors to use scripting and is awkward to
>>>>>    control at run time.)
>>>>>    7. If a particular tier has no geometry, or is not visible, then
>>>>>    it is not active.
>>>>>    8. What are requirements for definition of connections between
>>>>>    tiers (for example, layers of clothing connections to skin/skeleton)? Such
>>>>>    connectivity almost certainly must link (directly or indirectly) to
>>>>>    skeleton in order to maintain coherent animation of the humanoid. The
>>>>>    Site object is an obvious candidate for defining such connectivity.
>>>>>    9. Can Site object be applied consistently in context of each of
>>>>>    the tiers? In other words, is a point-wise approach using Site sufficient,
>>>>>    or might other kinds of connections be necessary? It is likely possible but
>>>>>    careful definitions are needed since non-point connections (line or
>>>>>    surfaces) might be needed. (For example, is the shoulder line for clothing
>>>>>    represented by a set of points or a line?)
>>>>>    10. Need ability to attach or detach connections (for example,
>>>>>    when a humanoid is putting on or taking off a hat).
>>>>>    11. Test case: is fur part of skin or part of coveroids? (Such
>>>>>    design is probably an author option, who might also choose to paint segment
>>>>>    geometry.)
>>>>>    12. Any more requirements?
>>>>>
>>>>> Group conversations are definitely helping, and comments are always
>>>>> welcome.
>>>>>
>>>>> This approach has potential to only require addition of a *coveroids* field
>>>>> to the *Humanoid*
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Humanoid>
>>>>> object, which is interesting simplicity.  Also addition of *visible *field
>>>>> to Joint
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Joint>
>>>>>  and Segment
>>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19774/ISO-IEC19774-1/ISO-IEC19774-1v2.1/ISO-IEC19774-1v2.1-WD/Architecture/ObjectInterfaces.html#Segment> objects
>>>>> offers appealing usefulness from a regular HAnim perspective, the ability
>>>>> to hide limbs or portions of the body...  Things look a little better each
>>>>> time.
>>>>>
>>>>> Once we are all reasonable happy with these requirements, suggested
>>>>> next steps are:
>>>>>
>>>>>    - define a few simple use cases that describe expected
>>>>>    functionality, later looking at MSF use cases.
>>>>>    - start converting design requirements into specification prose,
>>>>>    - building a simple example.
>>>>>
>>>>> Have fun thinking about future Humanoids wearing
>>>>> clothes!  👔👕👖👗👘👙👚🥼
>>>>>
>>>>> p.s. for Carol: and shoes too!  👡👢🥾🩴👞👟👠🥿🩰
>>>>>
>>>>> all the best, Don
>>>>> --
>>>>> X3D Graphics, Maritime Robotics, Distributed Simulation
>>>>> Relative Motion Consulting  https://RelativeMotion.info
>>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20251112/f60a3d5a/attachment-0001.html>


More information about the x3d-public mailing list