Introduction

Accurate sensor simulation that replicates physical phenomena is essential for evaluating the safety of AD/ADAS (automated driving/automated driving assistance systems) in virtual environments.

However, previous simulations were limited by computational power and memory, making them visually believable but not physically accurate. Consequently, these simulations were mainly used in the early development stages, where precise physical modeling was not necessary.

With increased computing power and improved simulation techniques, virtual testing now plays a crucial role at all stages of system development. This aligns with the growing need to accurately represent the real world in simulations, known as digital twins, especially as the demand for physical sensor simulation rises. A fundamental step in virtually describing the real world is providing a full physical description of all objects, including their material properties and 3D geometries.

Standardizing the representation of data and attributes, such as scenarios, road data, and asset data, is extremely important for AD/ADAS simulation. This promotes data circulation and ensures consistent results across different systems.

Standardization efforts have been made for scenarios and road data using ASAM OpenSCENARIO, ASAM OpenDRIVE, ASAM OpenCRG, and other standards. ASAM OpenMATERIAL 3D advances standardization by providing standardized definitions of material properties and 3D geometry.

ASAM OpenMATERIAL 3D is divided into distinct yet complementary segments enabling a modular approach to implementation. Key to this is the distinction between material and geometry. Based on specific use cases, users of ASAM OpenMATERIAL 3D can implement the standard for one or both segments. At least one of the two segments shall be implemented to conform with the standard.

For a full exchange of simulation-ready 3D assets however, both segments must be supported. Systems or tools providing full support for both material and geometric data can be described as follows: “This tool supports ASAM OpenMATERIAL 3D”.

A list of use cases examples can be found in Section 6, "Use cases", each highlighting its relevance to the material segment, the geometry segment, or both.

ASAM OpenMATERIAL 3D defines various file formats for specifying assets, material properties, and the mapping between them. Figure 1 illustrates these file formats and their interconnections. The definitions of the geometry related data formats marked in red can be found in the geometry segment. The definitions of the material related data formats marked in blue can be found in the material segment.

The first interaction with an ASAM OpenMATERIAL 3D-compliant 3D model is through the asset file.

The asset file is a JSON file with the file extension .xoma (ASAM OpenMATERIAL 3D Asset). A detailed definition of the asset file JSON schema is given in Section 7.5, "Asset schema". The asset file shall have the same name as a corresponding 3D data file in glTF, FBX, or USD format. To facilitate instancing, multiple asset files may be linked to a single 3D model file by adding an index separated by a dot (.) as a suffix to the asset file name. It contains metadata, such as description, unique identifier, version information, copyright details, and so on. It also includes a material texture assignment table, allowing dedicated material mapping textures to be assigned to materials within 3D data files. This enables comprehensive material properties to be mapped to the geometry at a texture level. Each texel of this dedicated texture contains a 32 Bit code (8 Bit values in the RGBA channels) which is mapped to a material property file (.xomp) in a separate material mapping file (.xomm), linked in the asset file with a URI. For the mapping currently only the RGB channels are used (first 24 Bits). The last channel is reserved for future use. An example asset is provided in the examples folder of the repository.

The 3D data file is a standard 3D model file in glTF, FBX, or USD format. Multiple formats can exist in parallel, so one asset file can have multiple 3D data files with different formats with the same name as the asset file. However, to be compliant with ASAM OpenMATERIAL 3D, a simulation environment must support at least one of the named 3D data formats. 3D data files may contain conventional materials, supporting visual rendering. These materials are unaffected by ASAM OpenMATERIAL 3D and may still be used in parallel. Figure 1 shows that the 3D data file has the exemplary materials "asphalt", "concrete", and "texture". The "texture" material has the visual texture of a stop sign. All these materials are purely visual materials embedded in the 3D data file. They may be used by conventional rendering systems. However, the material names given in the 3D data files are used to map material properties in the material mapping file, as described in the next section. More information about the file formats is given in Section 7.4, "File format". An example model is provided in the examples folder of the repository.

The material mapping file is separated from the asset file to facilitate reusability. Multiple assets can link to the same material mapping, allowing simulation systems to have a unified mapping table for all assets. A detailed definition of the mapping file JSON schema is given in Section 7.6, "Mapping schema". It contains metadata, such as description, unique identifier, version information, and the material mapping table. Each row in this table maps a material name, given in the 3D data file, or an RGB value, given in a dedicated assignment texture, to a material property file (.xomp). The table also includes a human-readable description of the material. This setup therefore allows for two mapping possibilities:

An example mapping file is provided in the examples folder of the repository.

The material property file contains metadata and the properties of one material. Similar to the mapping file, material property files can also be reused for different assets. A detailed definition of the material file JSON schema is given in Section 8.2, "Material schema". Some material properties depend on other simulation quantities, such as wavelength of the simulated sensor, temperature, and humidity. To avoid overloading one material file with large look-up tables, these are placed in auxiliary look-up table files linked with URIs in the main material property file. The defined look-up tables include:

Examples for material property files and look-up table files are provided in the examples folder of the repository.

To ensure compliance with the ASAM OpenMATERIAL 3D specification, users need to be able to distinguish between requirements, recommendations, permissions, possibilities and capabilities, and external constraints.

The rules listed in Table 1 for using modal verbs apply:

Content in this specification can be normative or informative. The sections listed in Table 3 are normative or informative per definition. Further informative content is shown in Table 4.

All other sections in this specification are normative.

Notes, footnotes, and examples shall not contain requirements or any information considered indispensable for the use of the document, for example, instructions or permission.