7.2 General

7.2.1 Dimensions

The following quantities and units are relevant for ASAM OpenMATERIAL:

Name Unit

acceleration

(m/s^2)

angle

(rad)

distance

(m)

mass

(kg)

time

(s)

velocity

(m/s)

7.2.2 Coordinate systems

ASAM OpenMATERIAL uses the following types of coordinate systems:

Both coordinate systems consist of three orthogonal directions associated with x-, y-, and z-axes, and a coordinate origin where axes meet. The coordinate systems are right-handed Cartesian coordinate systems according to ISO 8855. For a non-rotated coordinate system, the following applies:

  • Forward matches x-axis

  • Left matches y-axis

  • Up matches z-axis

The positive rotation is assumed to be counter-clockwise ("right-hand rule"). Orientation of objects is expressed extrinsically by the yaw, pitch, and roll angles derived from the Euler rotation sequence in the order z-axis, then y-axis, then x-axis.

img
Figure 2. Yaw, pitch, and roll angle in an ISO 8855:2011 compliant coordinate system

Figure 2 shows a right-handed coordinate system.

img
Figure 3. Coordinate system with defined rotations

Figure 3 shows the positive axes and positive directions of the corresponding angles.

img
Figure 4. Examples of rotations in coordinate system

Figure 4 shows the different states of a coordinate system with defined rotations. x’/y’/(z’=z) denotes the coordinate system after rotating x/y/z with the heading angle around the z-axis. The coordinate system x’’/(y’’=y’)/z’’ denotes the coordinate system after rotating x’/y’/z’ with the pitch angle around the y’-axis. The final rotated coordinate system (x’’’=x’’)/y’’’/z’’’ is obtained after rotating system x’’/y’’/z’’ with roll angle.

Each 3D model has an individual reference frame. Individual nodes of an object may have local coordinate frames, for example, each wheel of a vehicle.

7.2.2.1 World coordinate system

A coordinate system of type (x, y, z) that is fixed in the inertial reference frame of the simulation environment has the xw- and yw-axes parallel to the ground plane and the zw-axis pointing upward.

Neither origin nor orientation of the world coordinate system are defined by the ASAM OpenMATERIAL standard. Nevertheless, the origin of the world coordinate system in an OpenMATERIAL 3D environment should coincide with the origin of a corresponding ASAM OpenDRIVE map (if available). The origin of the world coordinate system in ASAM OSI should also be aligned with these two coordinate systems.

7.2.2.2 Local coordinate system

Top-most local coordinate frames of 3D assets (so-called reference coordinate frames) in OpenMATERIAL are defined in the center of the bounding box of the corresponding asset, projected to the bottom of the bounding box. By static transformations, these coordinate frames may be synchronized with reference coordinate frames in ASAM OpenSCENARIO and ASAM OSI. Besides reference coordinate frames, 3D assets may incorporate other local coordinate frames, see Object classes.

7.2.3 Naming conventions

7.2.3.1 General

The following naming conventions apply to ASAM OpenMATERIAL geometry files:

  • The 3D model file and the related 3D asset file shall have the same base name. Example: Example.gltf, Example.xoma

  • The naming convention inside the 3D model file (contains 3D information) must follow the capital Snake_Case definition, to improve human readability and enable consistent parsing of the file structure.

  • The naming convention inside the 3D asset file (contains metadata) must follow the lowerCamelCase definition, to allow a consistent naming convention in all .json files and consistent parsing.

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

7.2.3.2 Node structure

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

  • All components shall be named according to the capital Snake_Case definition, starting with uppercase letters.

  • 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.

  • Sequence of suffixes: 1: Iterator 2: Type Enumerator 3: Subtype Enumerator.

  • The predefined keywords shall be used for the corresponding asset parts and can be found in the according subchapters.

7.2.3.3 Metadata

  • Naming of fields shall be according to lowerCamelCase definition, starting with lower letters.

  • Naming of custom properties shall follow the predefined keys.

  • Objects, arrays (lists) and enums shall follow the .json notation.

7.2.4 3D asset file

The 3D asset file provides metadata as well as a mapping table to ASAM OpenMATERIAL material property files. This information extends the geometry of an asset given in standard 3D model file formats, e.g. glTF, FBX or USD. The 3D asset file is in JSON format with the file extension xoma. As indicated above, the asset file has to have the same file name as the accompanying 3D model. This is an example of a 3D model file in glTF format with an accompanying 3D asset file:

  • my-model.gltf

  • my-model.xoma

7.2.5 Requirements

  • The object’s geometry shall be in real word scale, using meters as unit for measurement for distances.

  • The object’s origins and pivot points shall coincide with position and orientation of the origin of the object’s reference coordinate frame if not specified otherwise.

  • Meshes shall not contain problematic characteristics such as doubled/isolated/coincident/coplanar/degenerate primitives.

  • Meshes shall have outside facing normals. Soft or hard edges shall be set correctly.

  • Meshes shall not be empty, nor contain multiple LODs.

  • Meshes shall be triangulated and potential normal maps shall match that triangulation.

  • Rendering materials shall support PBR workflows and there shall not be geometry without assigned material.

  • Additional requirements apply, when OpenMATERIAL 3D assignment textures are used:

    • UV channel 1 shall be used for assignment textures.

    • UV Islands shall have margins inbetween, so that assignment texture interpolation errors are avoided.

    • There shall not be any geometry without UV coverage.

7.2.6 Recommendations

  • UVs should not overlap and be within 0-1 UV space.

  • Elongated primitives should be avoided as they fit badly in acceleration structures.

  • Alpha-textured meshes should be optimized to minimize the amount of alpha testing.

  • Meshes should not have holes or gaps.

  • Meshes should have clean edgeflow.

  • Usage of N-Gons is not recommended.

  • Faces should be one-sided.

  • The lowest number of polygons possible should be strived for while still retaining the object’s shape.

  • Texel density should be homogeneous and as low as possible.

  • UV stretching should be minimized.

  • Naming of files, nodes, meshes and materials should be meaningful.

  • Usage of multiple PBR maps is encouraged (albedo/roughness/metallic/normals).

  • Smaller objects should have one material per object (e.g. baked traffic cone), while larger objects should contain multiple seamless repeatable materials (e.g. brick building).