Integration concept with ASAM OpenSCENARIO XML inconsistent/missing

[LudwigFriedmann]

Describe the bug
In OpenSCENARIO XML, currently, 3D Data Files (.fbx, .gltf, .obj, etc.) are referenced directly to represent entities in the scenario.
For the use of OpenMATERIAL 3D, the Asset File (.xoma) should be referenced at this point.
Otherwise (if the 3D Data File was referenced), there wouldn't be any knowledge about the asset file.
It would be unknown whether OpenMaterial 3D is being used, how the Asset File is named, or whether it exists.

We should therefore discuss whether the Asset File (*.xoma) should be used for referencing OpenMATERIAL 3D objects from OpenSCENARIO XML.
This would enable the usage of information from this file (e.g. bounding box dimensions) and therefore eliminate duplicates and inconsistencies.
For this purpose, a field in the OpenMATERIAL 3D Asset File is required that specifies the file path of the 3D Data File.

The concept can be applied to other standards, such as objects in ASAM OpenDRIVE

To Reproduce
Steps to reproduce the behavior:

1. Integrate a OpenMATERIAL 3D object with OpenSCENARIO XML

Expected behavior

• Intergration concept should be documented
• Field '3D Data File' should be added to Asset File

Screenshots

System Information (please complete the following information):

Additional context

[LudwigFriedmann]

@AsamDiegoSanchez, @ClemensLinnhoff, @MatthiasThDs , @KimuraDIVP, @ipg-sig : What's your opinion on that topic?

[MatthiasThDs]

As a workaround, maybe searching for a XOMA file, when actually a GLTF is given, is still a good workaround. So, on client side, you check if it could be an OpenMaterial Asset, because the xoma file is always named identical to the 3d file.

The better option is to link the XOMA file directly yes. I would approve that.

However, i am thinking if additional parameters within the OpenSCENARIO would be useful. For example, we have a "convertible_top" node in the vehicle. Is there a need for such parameters to be given by the scenario? top open or closed? to further define the state of the asset in use.

[LudwigFriedmann]

We could even have the OSC fields for the bounding box center, axles, wheels etc. in the Asset File.
However, due to potential overlaps with OpenSCENARIO definitions, adding further semantic information could also be resolved in a downstream ASAM OpenX proposal.

[ClemensLinnhoff]

We already have the interaction with OpenSCENARIO XML defined in the documentation: https://asam-ev.github.io/OpenMATERIAL-3D/asamopenmaterial/latest/specification/geometry/introduction.html#_interaction_with_other_asam_standards

There we have defined, that the xoma file shall be the model3d or SceneGraphFile in OpenSCENARIO. And in OSI also the xoma file shall be set as model_reference.

Another property in the xoma file is not necessary, because it must have the same name and be in the same folder as the 3D model file(s).

So in my opinion this is fully addressed by the documentation. I can additionally provide an example xosc file and xodr file with the example environment and example vehicle we have.

[ClemensLinnhoff]

We could even have the OSC fields for the bounding box center, axles, wheels etc. in the Asset File. However, due to potential overlaps with OpenSCENARIO definitions, adding further semantic information could also be resolved in a downstream ASAM OpenX proposal.

We do have fields for axles and wheels. So the OpenSCENARIO XML vehicle catalog could be automatically generated from an xoma file.

[LudwigFriedmann]

We already have the interaction with OpenSCENARIO XML defined in the documentation: https://asam-ev.github.io/OpenMATERIAL-3D/asamopenmaterial/latest/specification/geometry/introduction.html#_interaction_with_other_asam_standards

There we have defined, that the xoma file shall be the model3d or SceneGraphFile in OpenSCENARIO. And in OSI also the xoma file shall be set as model_reference.

Another property in the xoma file is not necessary, because it must have the same name and be in the same folder as the 3D model file(s).

So in my opinion this is fully addressed by the documentation. I can additionally provide an example xosc file and xodr file with the example environment and example vehicle we have.

Oh sorry, I must have overlooked that. However, if there are several other files with the same name but different file extensions in the same path, which one is chosen?

[ClemensLinnhoff]

However, if there are several other files with the same name but different file extensions in the same path, which one is chosen?

I think that is the great feature of this solution, that the simulation tools / models / FMUs can pick the file format that they support, if multiple are available. So let's say I have an environment simulation tool and a connected sensor model FMU. The environment simulation needs an FBX file and the sensor model needs a glTF file. Both can run in the same pipeline, with the same OpenMATERIAL 3D assets.

[LudwigFriedmann]

In this case, we can close the issue.