[x3d-public] Tiered design for skeleton, skin, coveroids
Don Brutzman
don.brutzman at gmail.com
Wed Nov 12 21:27:24 PST 2025
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.
>
>
> 1. A Coveroid object can be modeled, rendered, and exchanged
> independently without being contained within a Humanoid object
> *coveroids* field.
>
>
> 1. Minimum essential metadata must be included in order to meet
> interoperability and reusability requirements.
>
>
> 1. 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.
>
>
> 1. 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.)
>
>
> 1. 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?
>
>
> 1. 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.)
>
>
> 1. 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.
>
>
> 1. Once we have a consistent design principles emerging, need to look
> at Humanoid <#m_1010625822353646373_Humanoid>, Joint
> <#m_1010625822353646373_Joint>, Segment
> <#m_1010625822353646373_Segment>, and Site
> <#m_1010625822353646373_Site> clauses to see what additional semantic
> functionality needs to be defined.
>
>
> 1. Is Tier object a better name than Coveroid object?
>
>
> 1. 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/55d5c385/attachment-0001.html>
More information about the x3d-public
mailing list