Update model paths on both gzclient and gzserver at runtime

[osrf-migration]

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

While investigating a way to update model paths for Ignition Fuel in pull request #2856, I realized that the approach we've been taking to update paths is not working for models with mesh and texture resources.

The call to common::SystemPaths::Instance()->AddModelPaths only affects the process it's called from, and updating gui.ini only affects gzclient.

This is currently used by both the model and building editor, and by the "Add Path" button on the insert widget.

[osrf-migration]

Original comment by Mohamd Ayman (Bitbucket: Mohamd Ayman).

---

When you try to add a model, gzserver seems to first try the local machine models path, then try to download it, gzserver doesn't seem to know of the paths that we add.

[Wrn] [ModelDatabase.cc:212] Unable to connect to model database using [http://gazebosim.org/models//database.config]. Only locally installed models will be available.
[Err] [ModelDatabase.cc:414] Unable to download model[model://number1/meshes/number.dae]
[Err] [SystemPaths.cc:430] File or path does not exist[""]
[Err] [Visual.cc:2912] No mesh specified

So I think we only need to add the path that we are adding to the places where gzserver is looking for the models.

One thing I also noticed is that we insert a path that is the model directory itself, it doesn't read the model within that directory, wouldn't it be more usable if someone would be able to add a model by adding the model's directory path?

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

One thing I also noticed is that we insert a path that is the model directory itself, it doesn't read the model within that directory, wouldn't it be more usable if someone would be able to add a model by adding the model's directory path?

Yes, that makes sense and is a very common pain point for our users

[osrf-migration]

Original comment by Mohamd Ayman (Bitbucket: Mohamd Ayman).

---

I've made a little hack that solves this problem, the problem of not being able to add a model directly through choosing it directory.

Do I open a PR to gazebo8 branch and maybe default too ? or should we wait until we figure out how we are going to communicate the added paths between gzclient and gzserver ?

@chapulina

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Hi @mohamd_ayman , feel free to open a PR against gazebo8 (or even 7) and we can forward port it from there. I imagine that is a big change? I imagine many places in Gazebo assume the path is the model's parent directory.

I'll start working on a way to share paths among server and client.

[osrf-migration]

Original comment by Mohamd Ayman (Bitbucket: Mohamd Ayman).

---

Hi @chapulina, Here is the PR, it is a fairly simple solution, I've open it a week ago and declined it because of the issue of communicating the paths between GzServer and GzClient.

I'm not sure where are the other places that uses that, calling

grep -r 'AddModelPaths'

only shown the InsertWidget, should I search by s different key?

[osrf-migration]

Original comment by Mohamd Ayman (Bitbucket: Mohamd Ayman).

---

@chapulina ping .. :smile:

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

I think that solution will probably be more involved than that, it would be interesting to write some tests to make sure that the models listed under that directory are insertable and all their resources work correctly on both server and client.

[osrf-migration]

Original comment by Mohamd Ayman (Bitbucket: Mohamd Ayman).

---

Yeah this solution doesn't solve the server/client problem, that is why i declined it. it just makes it possible to add a model by selecting it's directory directly.

I still haven't figured out how to solve that server/client paths problem, if you have an idea I guess I can try it.

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

I started brainstorming a little bit about this.

For Ignition Fuel, I'm currently leaning towards making it work outside of Gazebo's model and resource paths. There will be a local cache specified by fuel's yaml configuration file, and the user doesn't need to specify anything else: ign-fuel-tools will be responsible for checking the local cache and pulling resources from the internet if not available.

For everything else, some thoughts:

• gzclient and gzserver could communicate to each other when a new path has been added, using Ignition Transport. The problem is that local paths are less useful if the processes are running in different machines.
• We could have a fallback mechanism which allows transmitting resources using Ignition Transport. For example, if gzclient can't find a resource on its local paths, and it is running in a different machine, gzserver could provide these resources through an Ignition Transport service. Gazebo already sends SDF files through messages, it could also send mesh files (dae, obj, stl...) and texture images, only when necessary, and gzclient could cache them locally for future use.

[osrf-migration]

Original comment by Mohamd Ayman (Bitbucket: Mohamd Ayman).

---

That does sound like a decent approach to solve this problem :thumbsup: