Skip to content

Commit

Permalink
Merge pull request #166 from asam-ev/164-add-main-introduction-page
Browse files Browse the repository at this point in the history
Add main introduction
  • Loading branch information
ClemensLinnhoff authored Nov 7, 2024
2 parents e104d55 + ea96adf commit 2adfa39
Show file tree
Hide file tree
Showing 2 changed files with 73 additions and 1 deletion.
Binary file added content/_images/openmaterial_overview.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
74 changes: 73 additions & 1 deletion content/general-docs/introduction.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,11 +3,83 @@

ifndef::include-only-once[]
:root-path: ../
:imagesdir: {root-path}/_images
:includedir: {root-path}/_images
include::{root-path}_config.adoc[]
endif::[]

== Overview
Overview of {THIS_STANDARD}.

=== Motivation

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.

=== The two parts of ASAM OpenMATERIAL

ASAM OpenMATERIAL consists of two main parts:

* *Material*: This part includes definitions and file formats for storing and exchanging material properties. These properties can be physical, such as surface roughness, permittivity, and index of refraction, or measured data, like wavelength and angle-dependent reflectance values.
* *Geometry*: This part contains node hierarchies for different object classes. These structures use a uniform naming scheme and coordinate definitions to enable the exchange of 3D models between various simulation systems.

=== Structure and file formats

ASAM OpenMATERIAL defines various file formats for specifying assets, material properties, and the mapping between them.
<<fig-openmaterial-overview>> illustrates these file formats and their interconnections.

[#fig-openmaterial-overview]
.Overview of ASAM OpenMATERIAL file formats and data flow
image::openmaterial_overview.png[,1100]

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 https://github.com/asam-ev/OpenMATERIAL/blob/main/schemas/asset_schema.json[asset file JSON schema] is given in xref:geometry/asset-schema.adoc[].
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.

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 xref:geometry/file-format-support.adoc[].

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 https://github.com/asam-ev/OpenMATERIAL/blob/main/schemas/mapping_schema.json[mapping file JSON schema] is given in xref:geometry/mapping-schema.adoc[].
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:

* Mapping one material property file per material in the 3D model.
* Mapping a texture code of an ASAM OpenMATERIAL assignment texture to a material property file, enabling detailed differentiation between material properties.

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 https://github.com/asam-ev/OpenMATERIAL/blob/main/schemas/material_schema.json[material file JSON schema] is given in xref:material/material-schema.adoc[].
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 lookup tables, these are placed in auxiliary lookup table files linked with URIs in the main material property file.
The defined lookup tables include:

* xref:material/material-emp-schema.adoc[Electromagnetic properties]
* xref:material/material-optical-schema.adoc[Optical properties]
* xref:material/material-brdf-schema.adoc[Bidirectional reflectance distribution functions (BRDFs)]

== Conventions and notations

Expand Down

0 comments on commit 2adfa39

Please sign in to comment.