Introduction

Accurate sensor simulation that replicates physical phenomena is essential for evaluating the safety of AD/ADAS 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 advances standardization by providing standardized definitions of material properties and 3D geometry.

ASAM OpenMATERIAL 3D is divided into distinct yet complementary chapters: Geometry and Material. Each chapter addresses specific aspects of the standard, enabling users to adopt and implement the parts most relevant to their needs.

ASAM OpenMATERIAL 3D supports a modular approach to compliance. Based on their individual use-cases, users of ASAM OpenMATERIAL 3D can decide if they want to implement the standard for 3D models, materials, or both:

A list of use cases examples can be found in the Use Cases chapter, each highlighting its relevance to the Material chapter, the Geometry chapter, or both.

ASAM OpenMATERIAL 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 Geometry. The definitions of the material related data formats marked in blue can be found in Material.

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

The asset file is a JSON file with the file extension .xoma (ASAM OpenMATERIAL 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 file 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 the texture contains a 32 Bit code (8 Bit values in the rgba channels) which is mapped to a material property file in a separate material mapping file, linked in the asset file with a URI. For the mapping currently only the rba channels are used (first 24 Bit). 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 standard compliant, a simulation environment must support at least one of the named 3D data formats. More information about the file formats is given in 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 or an RGB value to a material property file and includes a human-readable description of the material. This setup 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 specification, users need to be able to distinguish between requirements, recommendations, permissions, possibilities and capabilities, and external constraints.

The following rules for using modal verbs apply:

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

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.