Closed iche033 closed 4 months ago
sdf::ParserConfig
has an option to store resolved URIs. @mjcarroll I remember this was implemented in https://github.com/gazebosim/sdformat/pull/1147 to support Bullet-featherstone, but I don't see it actually being used in gz-sim.
Attention: 19 lines
in your changes are missing coverage. Please review.
Comparison is base (
ea90ada
) 78.52% compared to head (d1cdbc7
) 78.34%.
Files | Patch % | Lines |
---|---|---|
bullet-featherstone/src/SDFFeatures.cc | 0.00% | 19 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
but I don't see it actually being used in gz-sim
That shouldn't be the case, I looked a bit, but can't find any substantial reason it was excluded in the final merge?
Just checking how sdf::ParserConfig
can be used here to resolve URIs relative to model.sdf. I see sdf::ParserConfig
can resolve URIs based on user provided callback. In this case we want to resolve the mesh URI path relative to meshURI->FilePath()
. Does the user callback help here?
IIRC, your callback should be fired when the mesh URI is parsed. You can then choose to resolve the URL however you want and then that's what sdformat will return to anyone parsing the sdf file. Previously, the mesh URI would just be passed directly from the SDF file to the downstream user, this gives an opportunity to resolve that URI in a different way before the consumer sees it.
ok so we want to do this in gz-sim to resolve all URIs before passing to gz-phsyics. The tricky part is that the user callback takes a single URI
string argument so we'll then need to figure out how to pass different meshURI->FilePath()
to the callback each time it tries to resolve an URI.
proposed an alternative approach in https://github.com/gazebosim/sdformat/pull/1373
closing this in favor of the new approach in https://github.com/gazebosim/sdformat/pull/1373
🦟 Bug fix
Summary
When loading a model sdf that contains relative path to meshes, bullet featherstone implementation will fail to load the mesh and print out errors like these:
bullet featherstone implementation works differently from other physics engines. It does not rely on gz-sim to load the mesh and attach it using the
AttachMeshFeature
. Instead, it uses its own mesh manager for loading meshes. So we'll also need to resolve the mesh URI here in gz-physics. This is done using theasFullPath
function taken from gz-sim. We should consider refactoring this function, e.g. to gz-common, in the main branches so it can be reused in gz-physics.To test
You can download these world sdf and box mesh model files for testing:
and run the test world with bullet-featherstone physics engine in gz-sim:
Hit play and the box mesh should fall, collide (and then explode) instead of falling through the ground :)
Checklist
codecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-by
messages.