133 complete chapter human structure 734

[ipg-sig]

Describe your changes

Added content to the human structure.

Issue: Complete chapter Human structure (7.3.4) #133

@ClemensLinnhoff @LudwigFriedmann @MatthiasThDs @KimuraDIVP Please feel free to review and comment.
Work files can be found in the sharepoint under Documents/03_Development/Work_Files

The following adjustments have been made to the example model and structure according to the Miroboard:

The second detailed LOD level was set as the default, but simplified

• added bones for foot and toe
• added bones for hand and thumb
• added bones for hip
• added bones for eyes
• added groups for root, accessories, clothing, hair, body
• renamed some bones
• adjusted axis orientation
• adjusted bone orientation, so mirroring would be possible to use for animationg the character
• Added hip bones as seperate bones to stay compatible between (future) LOD levels. Therefore the bones can all have an unique name and can be used for (future) animations without breaking them. Same for the hand and spine.

Full_Hand ← Hand → Hand (with Upper_Fingers and Lower_Fingers)
Full_Foot ← Foot → Foot (with Upper_Toes and Lower_Toes)

[ClemensLinnhoff]

Links to the sections are missing here. @FKlopfer you assist in adding them back in?

[FKlopfer]

Added links to structure overview. Some chapters exist only in the overview yet, they need to be created: Skeleton, Human, Vest, Hair, Accessorie.

The order of the chapters also needs to be adjusted when everything is finished.

[ClemensLinnhoff]

In the example, there is the Armature as a hierarchy element between Grp_Root and the other Groups (Body, Hair etc.), like this:

• Grp_Root
  • Armature
    • Armature_Human
      • Root
        • Lower_spint
        • ...
    • Grp_Accessories
    • Grp_Body
    • ...

I think it needs to be that way, because every mesh that is affected by the skeleton needs to be part of the armature, as far as I know. So do we have to put this in the structure here in the documentation?

[ClemensLinnhoff]

@FKlopfer This is ready for an editorial review.

[ClemensLinnhoff]

We just noticed: shoulder right is missing @ipg-sig

[ClemensLinnhoff]

The coordinate definitions of the bones are not clear all the time. The y-axis should always be along the bone, right? And the x-axis always forward? Then I would define it that way instead of using up, down, side etc. Might make it more clear for bones that are at an angle in the default position.

[mettelilienthal]

We have a few questions regarding consistency between the vehicle, road, and human structure:

• Title: For the vehicle and road structure, the titles name the indices; while for the human structure, simply the bone itself is the title (Grp_Door_Bottom_<door_bottom_idx> vs. Upper_Spine). Which title naming convention should we work with?

• Origin definition: For the vehicle and road structure, the origin is defined in the tables along the axes; while for the human structure, the origin is defined in the text above the tables. Should we move the origin definitions to the tables?

• Definition of groups: In the vehicle structure, we introduced each group's definition with "This group contains..."; while in the human structure, the group is named explicitely ("The Lower_Spine bone represents..."). Should we rework the vehicle structure accordingly? This might help searchability as naming the group is more concrete.

• Coordinate systems: For the vehicle structure, we never defined how the local coordinate system for the vehicle as a whole is placed in relation to the world coordinate system. Should we add that and if so, how?

[ClemensLinnhoff]

• Title/Groups: There is a difference between a bone and a group. A group is an empty node grouping multiple meshes or further sub-groups. A bone is a single element in an armature/skeleton. Bones only exist once, so they don't have an index.
• Origin definition: You are right, let's harmonize the tables and put the origin in the tables here.
• Coordinate systems: This is also defined for the vehicle: "The origin of the Root node is the center of the vehicle’s bounding box projected to the ground, including all vehicle parts in their default positions". It should actually always be the center of the bounding box ob the object projected to the ground for all object classes.

[mettelilienthal]

Thanks for the feedback!

Another question regarding the tables: The tables for the objects that can move (Hair, Clothing, ...) differ because they list the transformation. Would it be possible to extract that information from the table, rather listing it in the definition to ensure consistency? We would then write something like "This object typically moves in the simulation and therefore has its own transforms."

Also, what kinds of transformations are we talking about? Is it only rotation (as mentioned in 7.2.2 Coordinate systems) or also scaling etc.? Maybe we should specify this?

[ClemensLinnhoff]

Hair, Clothing etc. actually don't move independently in the simulation. Their coordinate system stays in the center of the bounding box on the ground, so the object coordinate system.

[mettelilienthal]

Could you then please explain why these objects have a transformation listed in the table?

[ClemensLinnhoff]

Could you then please explain why these objects have a transformation listed in the table?

In my opinion they could be removed here. @ipg-sig @LudwigFriedmann what do you think?

[ipg-sig]

Could you then please explain why these objects have a transformation listed in the table?

In my opinion they could be removed here. @ipg-sig @LudwigFriedmann what do you think?

@ClemensLinnhoff I think we can remove it, if it is clear, that they shouldn´t have any transformations (Location & Rotation at 0, Scale at 1), to be able to properly use them.

The coordinate definitions of the bones are not clear all the time. The y-axis should always be along the bone, right? And the x-axis always forward? Then I would define it that way instead of using up, down, side etc. Might make it more clear for bones that are at an angle in the default position.

If we want to keep the ability to mirror it properly, it is not always forwards. One side is forwards, the other one backwards. I think images of the bone rotation makes it more clear. But we can also change it or call it otherwise. What or how would you prefer to call it to keep it consistent and clear for the reader?

[ClemensLinnhoff]

About the bones, the y-axis is consistently along the bones, right? So we could define it that way.
The x-axis in the example is sometimes pointing forward, sometimes backwards. If we want to keep it that way, we need to adjust the specification here to match that.

[mettelilienthal]

@ClemensLinnhoff please check whether this definition structure works for you :)

[mettelilienthal]

Is it correct to add the bones here? Please also check for the legs accordingly.

[mettelilienthal]

@ACMackenthun please review :)