Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete chapter naming convention #185

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 34 additions & 5 deletions content/geometry/general.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -83,13 +83,42 @@ NOTE: Origins of the coordinate frames for specific object classes are under
discussion.

== Naming conventions
=== General
The following naming conventions apply to ASAM OpenMATERIAL geometry files:

* The name of a 3D model file shall have the prefix `omg_` to indicate that the file
complies with the ASAM OpenMATERIAL geometry specification.
* The 3D model file and the related 3D asset file shall have the same base name.

NOTE: Putting more information in file name to be discussed for specific object classes.
* The name of a 3D model file shall have the prefix "omg_" to indicate that the file complies with the ASAM OpenMATERIAL geometry specification.
* The 3D model file and the related 3D asset file must have the same base name.
Example: omg_Example.gltf, omg_Example.xoma
* The naming convention inside the 3D model file (contains 3D informations) must follow the snake_case definition, to improve human readability and enable consistent parsing of the file structure.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are using capital Snake_Case for the node names

* The naming convention inside the 3D asset file (contains meta data) must follow the lowerCamelCase definition, to allow a consistent naming convention in all .json files and an consistent parsing.
* LOD levels (Level of Detail) are not part of the first version of the standard, but will be added in future versions for each asset type.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove this sentence? In my opinion we should not state what is not specified.

* Keywords are predefined names for objects inside the node structure.

=== Node Structure
Every Node Structure for a 3D object uses predfined subkeys to allow a consistent naming convention and parsing. Some subkeys are already defined by the standard and more could follow in future updates. The User is free to add more subkeys for himself, if they are needed.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Every Node Structure for a 3D object uses predfined subkeys to allow a consistent naming convention and parsing. Some subkeys are already defined by the standard and more could follow in future updates. The User is free to add more subkeys for himself, if they are needed.
Every node structure of a 3D object uses predefined subkeys to allow a consistent naming and parsing. The user is free to add custom subkeys, if they are needed.


* All components should be named according to the snake_case definition, starting with uppercase letters.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* All components should be named according to the snake_case definition, starting with uppercase letters.
* All components shall be named according to the Snake_Case definition, starting with uppercase letters.

* Group Nodes (also known as empty nodes or parent nodes) shall have "Grp_" as a Prefix.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Group Nodes (also known as empty nodes or parent nodes) shall have "Grp_" as a Prefix.
* Group nodes (also known as empty nodes or parent nodes) shall have "Grp_" as a prefix.

* Iterators are added as suffixes. In the documentation, iterator names are written in pointy braces (e.g. <type_idx>). In the node names itself, the iterator names are replaced by integer values starting from 0.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Iterators are added as suffixes. In the documentation, iterator names are written in pointy braces (e.g. <type_idx>). In the node names itself, the iterator names are replaced by integer values starting from 0.
* Iterators are added as suffixes. In the documentation, iterator names are written in pointy braces (e.g. <type_idx>). In the node names themselves, the iterator names are replaced by integer values starting from 0.

* Enums (e.g. from OpenDRIVE road/lane type) should be added as suffixes in capital letters.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually have that?

* Sequence of suffixes: 1: Iterator 2: Type Enumerator 3: Subtype Enumerator.
* Count the axle index by following the OSI definition from front to rear starting with 0.
* Count the wheel index by following the OSI definition counting per axle from right to left (in positive y-direction).
//Note: Please add link to OSI definition (https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/gen/structosi3_1_1MovingObject_1_1VehicleAttributes_1_1WheelData.html#a094de989f5a2aab080f9a65f0feb3867)
* Count the door index per side from front to rear and right to left (in positive y-direction).
* Count the seat index per level from first level front to rear, and right to left, to the next level from right to left and front to rear. Note: A rear bench with 3 seats will be consideres as 3 seats, because 3 passengers could take a seat on it.
Comment on lines +105 to +109
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to specify the specific counting order here? It is also defined in the corresponding node structure.

* The predefined subkeys and keywords must be used for the corresponding asset parts.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keywords are not defined. Since we removed the concept of vehicle parts, I think we should remove keywords, as well.

* LOD levels (Level of Detail) are not part of the first version of the standard, but will be added in future versions for each asset type.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplication

* All keywords can be found in the according subchapters.
//Note: Please add links to the vehicle structure, human structure and environment structure

=== Metadata

* Naming of fields must be according to lowerCamelCase definition, starting with lower letters.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[...] with lowercase letters.

* Naming of Custom Properties must follow the predefined keys.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are keys in this context?

* Objects, Arrays (lists) and Enums must follow the .json notation.

//NOTE: Putting more information in file name to be discussed for specific object classes.

== 3D asset file
The 3D asset file provides meta data as well as a mapping table to ASAM OpenMATERIAL material property files.
Expand Down
113 changes: 113 additions & 0 deletions content/geometry/object-human/human-naming-convention.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
=== Naming convention

General naming structure for the bones: BoneName_Side

.Side indicator
[%header, cols="20, 80"]
|===

2+^| Side

| *Keyword*
| *Usage*

|*Left*
| Specifies the left side

|*Right*
| Specifies the right side

|===


.Node Names
[%header, cols="20, 80"]
|===

2+^| Node Names

| *Keyword*
| *Usage*

| *Grp*
| Prefix for group nodes

|*Accessories*
| Prefix all (exchangable) accessories

|*Body*
| Prefix for the body

|*Clothing*
| Prefix for all (exchangable) clothings

|*Hair*
| Prefix all (exchangable) hairs

|===
Comment on lines +23 to +47
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has to be adapted to the changed definition of the human structure.



.Bone names
[%header, cols="20, 80"]
|===

2+^| Bones

| *Bone name*
| *Usage*

| *Root*
| Bone to transform the whole skeleton

| *Lower_Spine*
| Bone for the lowest part of the spine

| *Middle_Spine*
| Bone for the middle part of the spine

| *Upper_Spine*
| Bone for the upper part of the spine

| *Hip_<Side>*
| Bone for the hip

| *Neck*
| Bone for the neck

| *Head*
| Bone for the head

| *Eye_<Side>*
| Bone for the eye

| *Shoulder_<Side>*
| Bone for the shoulder

| *Upper_Arm_<Side>*
| Bone for the upper arm

| *Lower_Arm_<Side>*
| Bone for the lower arm

| *Hand_<Side>*
| Bone for the hand

| *Full_Thumb_<Side>*
| Bone for the thumb

| *Full_Fingers_<Side>*
| Bone for all fingers, exluding the thumb

| *Upper_Leg_<Side>*
| Bone for the upper part of the leg (thigh)

|*Lower_leg_<Side>*
| Bone for the lower part of the leg (leg)

| *Foot_<Side>*
| Bone for the foot, excluding the toes

| *Full_Toes_<Side>*
| Bone for the toes.

|===
Comment on lines +50 to +113
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not put this in the naming convention, as it is also in the structure.

Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
=== Naming convention

.Keyword
[%header, cols="20, 80"]
|===

2+^| Keywords

| *Keyword*
| *Usage*

| *Grp*
| Prefix for group nodes

| *Root*
| Used as parent node for all assets

| *Terrain*
| Contains all assets, which represent the ground (terrain)

| *Objects*
| Contains all assets, which can be placed onto the terrain or road network

| *Buildings*
| Contains all buildings

| *Vegetation*
| Contains all vegetation

| *Road_Network*
| Contains all assets, which represent the road network

| *Driving_Area*
| Contains all assets, which represent the drivable areas

| *Sidewalks*
| Contains all assets, which represent the sidewalks

| *Road_Marks*
| Contains all assets, which represent the road markings

| *Road_Object*
| Contains all road objects from OpenDRIVE

| *Signals*
| Contains all assets, which represent signals

| *Sign*
| Contains all assets, which represent traffic signs

| *Traffic_Light*
| Contains all assets, which represent traffic lights

|===
Comment on lines +3 to +54
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not put this in the naming convention, as it is also in the structure.

174 changes: 174 additions & 0 deletions content/geometry/object-vehicle/vehicle-naming-convention.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,174 @@
=== Naming convention


.Vehicle Keywords
[%header, cols="20, 80"]
|===

2+^| Vehicle Keywords

| *Keyword*
| *Usage*

| *Grp*
| Prefix for group nodes

| *Static*
| Contains all static components

| *Dynamic*
| Contains all dynamic components

| *Exterior*
| Contains the exterior of an vehicle

| *Interior*
| Contains the interior of an vehicle

| *Wheel*
| Contains wheels of an vehicle

| *Wheel_Steering*
| Contains the wheel steering

| *Door*
| Contains doors of an vehicle (inlucding trunks, engine hoods, etc.).
After this subkey always follows a subkey which indicates the specific view side

| *Number_Plate*
| Contains license plates of an vehicle

| *Convertible_Top*
| Contains the convertible top of an vehicle

| *Rear_Axle_Center*
| Contains the sensors reference coordinate frame of the vehicle

| *Mirror*
| Contains all mirrors of an vehicle

| *Steering_Wheel*
| Contains all steering wheels of an vehicle

| *Eyepoint*
| Contains the eyepoint of the passenger(s)

| *Seat*
| Contains the seat positions of the passenger(s)

|===

.View Keyword
[%header, cols="20, 80"]
|===

2+^| Vehicle View Keyword

| *Front*
| Specifies the front view side

| *Left*
| Specifies the left view side

| *Right*
| Specifies the right view side

| *Top*
| Specifies the top view side

| *Rear*
| Specifies the rear view side

|===


.Light Keyword
[%header, cols="20, 80"]
|===

2+^| Vehicle Light Keyword

| *Light*
| Contains vehicle lights
After this keyword always follows a keyword which indicates the specific vehicle light

| *Day*
| Specifies day lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Low_Beam*
| Specifies low beam lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *High_Beam*
| Specifies high beam lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Corner*
| Specifies corner lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Position*
| Specifies position lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Park*
| Specifies park lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Indicator*
| Specifies indicator lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *License_Plate*
| Specifies license plate lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Tail*
| Specifies tail lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Brake*
| Specifies brake lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Reverse*
| Specifies reverse lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Fog*
| Specifies fog lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

| *Warning*
| Specifies warning lights of the vehicle and is always used after the keyword "Light".
After this keyword always follows a keyword which indicates the specific view side.

|===

.Mirror Keywords
[%header, cols="20, 80"]
|===

2+^| Vehicle Mirror Keywords

| *Side*
| Specifies the side mirror(s) of an vehicle.

| *Blindspot*
| Specifies the blindspot mirror(s) of an vehicle

| *Rearview*
| Specifies the rearview mirror(s) of an vehicle

| *Mounting*
| Specifies the mirror mounting on the vehicle, always used after the keyword , which specifies the type of the mirror

|*Joint*
| Specifies the movable part of the mirror on the mirror mounting.
After this keyword always follows a keyword which indicates the specific view side.

| *View*
| Specifies the view direction of the mirror glass on a the mirror

|===