Open osrf-migration opened 6 years ago
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 path
s 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
?
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
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
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.
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?
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.
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.
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.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.Original comment by Mohamd Ayman (Bitbucket: Mohamd Ayman).
That does sound like a decent approach to solve this problem :thumbsup:
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 updatinggui.ini
only affectsgzclient
.This is currently used by both the model and building editor, and by the "Add Path" button on the insert widget.