Complete chapter naming convention #185
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ipg-sig
requested review from
ClemensLinnhoff,
MatthiasThDs,
LudwigFriedmann,
MustafaTrian,
KimuraDIVP and
lyndyRott
LudwigFriedmann
requested changes
Nov 20, 2024
content/geometry/general.adoc
Outdated
| * 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 better human readability and consistent parsing of the file structure |
There was a problem hiding this comment.
[...] to improve human readability and enable [...]
content/geometry/general.adoc
Outdated
| * The naming convention inside the 3D model file (contains 3D informations) must follow the snake_case definition, to better human readability and consistent parsing of the file structure | ||
| * 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. | ||
| * Subkeys are predefined and not (yet) standardized Subkeys are recommended to use. |
There was a problem hiding this comment.
I'm not familiar with the term subkeys. From the context I understand it's a keyword. Would this be more suitable?
content/geometry/general.adoc
Outdated
| === 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. | ||
|
|
||
| * All components should be named according to the snake_case definition, starting with upper letters. |
There was a problem hiding this comment.
[...] starting with uppercase letters.
| //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. | ||
| * The predefined subkeys and keywords must be used for the corresponding asset parts. |
There was a problem hiding this comment.
Keywords are not defined. Since we removed the concept of vehicle parts, I think we should remove keywords, as well.
content/geometry/general.adoc
Outdated
| * 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. | ||
| * The predefined subkeys and keywords must be used for the corresponding asset parts. | ||
| * 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. | ||
| * Meshes, which should be included but not visible, need metadata to define the state of visibility. The deault value is set to 1 (visible), so the metadata is only needed if the mesh should be hidden. |
There was a problem hiding this comment.
Where would this metadata (visibility state) be defined?
There was a problem hiding this comment.
Let's postpone the topic of visibility and create a issue from that for release 2.0.
| | Contains all assets, which represent traffic signs | ||
|
|
||
| | *Traffic_Light* | ||
| | Contains all assets, which represent traffic signs |
There was a problem hiding this comment.
[...] which represent traffic lights.
| | Contains the convertible top of an vehicle | ||
|
|
||
| | *Sensors* | ||
| | Contains the convertible top of an vehicle |
There was a problem hiding this comment.
Contains the sensors reference coordinate frame of the vehicle
| | *Sensors* | ||
| | Contains the convertible top of an vehicle | ||
|
|
||
| | *Sensors* |
There was a problem hiding this comment.
Duplicate from line 47-48
| | Contains all steering wheels of an vehicle | ||
|
|
||
| | *Eyepoint* | ||
| | Contains the eyepoint levels of the passenger(s) |
There was a problem hiding this comment.
I'd remove "levels" here
|
|
||
| |=== | ||
|
|
||
| .Additional and recommended Subkeys |
There was a problem hiding this comment.
Should we make this part of the standard for release 1.0?
We postponed standardization of vehicle_parts...
|
Please remove vehicle_part concept and keywords for now as it is postponed for a later release. |
|
Decision: Grp_Sensor_<sensor_idx> should be renamed to Grp_Rear_Axle_Center and the index should be removed (it's an empty node) |
|
Decision: "Others" within Objects should be removed |
|
Decision: Root (T) Note: Signal_idx can be taken over from OpenDRIVE or OSI just iterated from 0...n. They're valid for both traffic signs and traffic lights so a traffic light can't have the same ID as a traffic signs |
Signed-off-by: Simone Graf <[email protected]>
ipg-sig
force-pushed
the
85-documentation-naming-conventions-723
branch
from
592ddd7
to
a633d7a
Compare
ClemensLinnhoff
requested changes
Nov 25, 2024
| * 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. |
There was a problem hiding this comment.
We are using capital Snake_Case for the node names
| 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. | ||
| * 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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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. |
| === 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. | ||
|
|
||
| * All components should be named according to the snake_case definition, starting with uppercase letters. |
There was a problem hiding this comment.
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. |
| 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. | ||
|
|
||
| * All components should 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. |
There was a problem hiding this comment.
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. |
Comment on lines
+105
to
+109
| * 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. |
There was a problem hiding this comment.
Do we need to specify the specific counting order here? It is also defined in the corresponding node structure.
| * 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. | ||
| * The predefined subkeys and keywords must be used for the corresponding asset parts. | ||
| * 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. |
Comment on lines
+23
to
+47
| .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 | ||
|
|
||
| |=== |
There was a problem hiding this comment.
Has to be adapted to the changed definition of the human structure.
Comment on lines
+50
to
+113
| .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. | ||
|
|
||
| |=== |
There was a problem hiding this comment.
I would not put this in the naming convention, as it is also in the structure.
Comment on lines
+3
to
+54
| .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 | ||
|
|
||
| |=== |
There was a problem hiding this comment.
I would not put this in the naming convention, as it is also in the structure.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Describe your changes
Added naming conventions in the general chapter and in all object chapters
Issue ticket number and link
#85
Mention a member
@ClemensLinnhoff @LudwigFriedmann @MatthiasThDs @MustafaTrian @KimuraDIVP @lyndyRott
Ready for review.
Checklist before requesting a review