Enable material mapping through an external file

[ipg-jsc]

The first draft https://github.com/asam-ev/OpenMATERIAL/pull/29/files puts the material mapping directly into the asset file. It should also be possible to refer to an external file for material mapping.

Use cases:

• reuse of existing material mappings
• easier reassignment
• (generation from a 3D graphics software material library?)

[LudwigFriedmann]

Can we have a vote on this topic? Maybe some information on use-cases is still needed... @MatthiasThDs can you help?

[MatthiasThDs]

Options for Material Mapping

A material mapping is needed, so that simulators can exchange a measured OpenMaterial with their own measured OpenMaterial without changing the material assignment within the asset itself (worst case: exchange one color in the baked material ID texturemap).

Option 1: Local included Mapping

Each asset file directly includes the mapping to the materials.

asset1.xoma:

{
  ...
  "material_mapping": [
    ["10;50;255;127", "materials/metal_red.xomp", "metal with red paint"]
    ["11;50;255;127", "materials/metal_green.xomp", "metal with green paint"]
  ]
}

asset2.xoma:

{
  ...
  "material_mapping": [
    ["12;50;255;127", "materials/metal_blue.xomp", "metal with blue paint"]
  ]
}

Option 2: External Vendor Specific

Each asset file links to a external file for material mapping.

asset1.xoma:

{
  ...
  "material_mapping": "vendor1_mapping_version1.xomm"
}

asset2.xoma:

{
  ...
  "material_mapping": "vendor1_mapping_version1.xomm"
}

vendor1_mapping_version1.xomm:

{
  "material_mapping": [
    ["10;50;255;127", "materials/metal_red.xomp", "metal with red paint"],
    ["11;50;255;127", "materials/metal_green.xomp", "metal with green paint"],
    ["12;50;255;127", "materials/metal_blue.xomp", "metal with blue paint"]
  ]
}

The idea is, that each vendor probably uses similar ids across multiple assets. An external mapping file can specify all potential IDs, so that each asset file would not need to keep track of the used IDs. The expected scenario is, that a simulator has a small number of mapping files from different vendors. The main advantage is, that a user can edit those vendor-specific mapping files and, for example, remap a specific material because they got a better measurement for it somewhere else. This is "vendor specific global", because users change multiple assets simultaneously. Disadvantage: To overwrite just a single asset (instead of multiple simultaneously), the user has to create a new copy of the material mapping file, e.g. _mycustom_vendor1mapping.xomm or _asset1_vendor1mapping.xomm, and link that file from the one asset (or a bunch of assets).

Vendor Specific basically means "charge specific" or "group specific". It does not limit a vendor to only use one material mapping for everything.

Option 3: External per Asset

Each asset file links to an external file, specific to that asset for material mapping.

asset1.xoma:

{
  ...
}

asset1.xomm:

{
  "material_mapping": [
    ["10;50;255;127", "materials/metal_red.xomp", "metal with red paint"],
    ["11;50;255;127", "materials/metal_green.xomp", "metal with green paint"],
    ["12;50;255;127", "materials/metal_blue.xomp", "metal with blue paint"]
  ]
}

asset2.xoma:

{
  ...
}

asset2.xomm:

{
  "material_mapping": [
    ["10;50;255;127", "materials/metal_red.xomp", "metal with red paint"],
    ["11;50;255;127", "materials/metal_green.xomp", "metal with green paint"],
    ["12;50;255;127", "materials/metal_blue.xomp", "metal with blue paint"]
  ]
}

This is like option 2, but with the recommendation to have one mapping file per asset file. It removes the disadvantage in that users can easily edit the mapping of a single asset. If we want to force this option, we can leave out the material_mapping entry in the asset file (asset.xoma) and demand the mapping file with the same name (asset.xomm).

It makes broader changes more difficult though: you may have to loop though multiple asset mapping files if you want to update the material mapping for multiple assets of a specific vendor (which may be the most probable use case). The advantage compared to option 1 is still, that the mapping file is external and ought to include all potential material IDs to ease broader changes. Users can copy and paste an edited mapping file for other assets.

Option 4: External Local Mapping

One could think of option 1, with the ability to outsource the locally used materials within that asset into an external mapping file. There should be no advantage in outsourcing the mapping into a file though, if the content is so specific to the asset. However, this is obviously possible when allowing to link to an external mapping file. This practice should just not be recommended.

[MatthiasThDs]

@LudwigFriedmann @ClemensLinnhoff There should be a voting/discussion in one of the next meetings. We as dSPACE recommend Option 2: External Vendor Specific.

[ClemensLinnhoff]

Discussion in the material group also favours Option 2.

[ClemensLinnhoff]

[ClemensLinnhoff]

Having a dedicated mapping table per asset shall be allowed as well as multiple assets sharing one mapping table. This allows maximum flexibility. In any case the mapping table is in a separate file for consistency.

[ClemensLinnhoff]

Mapping shall be possible by either the material name from the 3D model file or an id (color value) of an OpenMATERIAL assignment texture. Multiple key can point to the same material. Example:

["material_red", "materials/material_a.xomp", "metal with red paint"],​
["rgba:10;50;255;127", "materials/material_a.xomp", "metal with red paint"]