Make it possible to supply custom MeshLoader

[mahiuchun]

Desired behavior

A developer using Gazebo could choose to supply a custom MeshLoader.
The choice of MeshLoader could be determined by file extensions. More elaborate choice logic could be considered too.

Alternatives considered

N/A

Implementation suggestion

If we determine MeshLoader by file extensions, replace the current hard-coded logic in MeshManager with a choice logic backed by a hash map.

Additional context

Using the current snapshot of https://github.com/gazebosim/gz-common/tree/luca/assimp_sandbox as an example.
The following was added to MeshManager

else if (extension == "gltf" || extension == "glb" || extension == "fbx")
      loader = &this->dataPtr->assimpLoader;

If one could choose to use Assimp for other file types (as determined by extensions), it's more flexible.

[chapulina]

If one could choose to use Assimp for other file types (as determined by extensions), it's more flexible.

• See Introduces GZ_MESH_FORCE_ASSIMP flag #403

[mahiuchun]

Thanks. I think there are still cases where custom loader would be helpful:

• Using assimp with different importer flags
• Using assimp with custom pre/post-processing
• Load meshes from memory instead of the file system
• Other custom mesh loaders

[onurtore]

Hi @mahiuchun,

I am currently working on the assimp mesh loader, and would love to implement the functionalities you are referring.

• Can you share the flags in your mind? It will make it easier for me to test this functionality locally.
• What type of pre/post processing you are referring? Same reason above.
• I did not exactly understand what you mean by loading meshes from memory. Can you elaborate little bit more.
• I think you can utilize and use every mesh loader with every available file type using current implementation. Do you want to use mesh loaders other than assimp and default loaders? If that is the case, which mesh loaders you are referring.

[sgayda2]

I wanted to add some context on some of the questions posed by onurtore@

For some situation we have geometry loaded in memory inside a gazebo plugin. This plugin then modifies the world by inserting a model with some new geometry. It would be ideal for the plugin to hand over the geometry data directly to gazebo instead of having to write the geometry to disk, and then reference the new files in the inserted model.

As for the other questions, I think there are many flags/options that you specify to the assimp importer like deduplicate vertex and drop points. These are are currently set in the constructor for the AssimpoLoader class:

gz-common/graphics/src/AssimpLoader.cc

Line 610 in 466f83f

this->dataPtr->importer.SetPropertyBool(AI_CONFIG_PP_FD_REMOVE, true);

Anyway I think the main benefit for me specifically is the handover for in memory data.

[iche033]

Regarding handing over in-memory data to gazebo, if vertices, normals, texcords, etc info are available, the user can hand them over by creating a gz::common::Mesh object and registering the mesh with the MeshManager by calling gz::common::MeshManager::Instance()->AddMesh

However, gz-sim still expects meshes to be specified as an URI in SDF. The code that loads meshes in gz sim is:

• here in rendering:
• here in physics

We'll still need to modify these two places to support loading meshes by name (e.g. name of the gz::common::Mesh that's registered with MeshManager) in addition to URI path.