Support the PLY geometry format in URDF?

Hello! I posted over in the URDF Github, but this place seems to be a bit more active.

At the moment, the URDF spec only seems to mention Collada / DAE and STL file formats for the mesh node. STL, however, doesn’t support a very robust set of data and Collada is pretty inefficient in terms of file size and pretty complicated to export. What are peoples thoughts on including something like the PLY format as an option for a mesh node file format?

  • Supports a binary format type, which enables to smaller file sizes.
  • Optionally supports texture coordinates so the <texture> tag can be used for a surface texture.
  • Optionally supports normals and vertex colors (and any other custom vertex attribute) for other color and shading.
  • Extremely simple to write an importer / exporter for.

Thoughts? Thanks!
Garrett

Without being familiar with 3D modle formats, I’d say someone would need to give the point of view from the libraries that use these files. I’m thinking of:

  • Rviz. Haven’t found much.
  • Gazebo. Their tutorial just talks about exporting to .dae/
  • Collision computation libraries like fcl which I believe is used in MoveIt.

If they already have support for it, sounds great! If they don’t, a newer version of URDF should at the same time support these big players I guess.

Sounds reasonable. I’m less familiar with the ROS codebase, myself, but I’ve noticed some references to assimp around the ROS repos, and this issue (in the bullet physics repo?) has discussions around gazebo using assimp to load models, as well.

If that’s true, then this may be as simple as extending the spec to include another model format. I’d almost suggest just allowing anything that assimp can load (if it’s actually that easy), but I actually like the constrained list of formats because that makes it easier to consume the format on other platforms (we’re visualizing these models using THREE.js and javascript, as well). To me, all that’s missing is a simple to export, terse, binary geometry format.

Thanks!
Garrett

It will not help to improve the state-of-the-art wrt supported features, but in some testing I did a few months ago it turned out that you can use just about anything that Assimp supports for meshes in urdfs. In the end it all gets converted to vertices & faces anyway, so as long as Assimp can load your mesh it should work.

IIRC I even used fbx at some point.

Note that this is really just about meshes, so none of the ‘advanced’ features formats like Collada and FBX support are used (bones, skins, kinematics, simulation properties, etc).

I did not include Gazebo in these tests, so that may be different.

Collada has a variant where the whole file is compressed using gzip, the extension changes to .zae and it typically results in 90% reduction in file size. It supports all of the things you mentioned, but it is definitely not meant to be human readable and is not straightforward to export to without a library doing it for you.

in some testing I did a few months ago it turned out that you can use just about anything that Assimp supports for meshes in urdfs

Great! That’s more or less what I was expecting. So it sounds like this is more a matter of documentation than anything else. Unless there’s a serious reason not to expand the documented mesh formats, this could be as simple as just adding an extension to the list on the URDF wiki page!

Collada has a variant where the whole file is compressed using gzip, the extension changes to .zae and it typically results in 90% reduction in file size.

I’d heard of zae before, but it also wasn’t listed on the URDF wiki as a suitable format. I’d say it’s worth adding that, as well, if it’s considered a valid format. In a quick test, it looks like PLY is able to get down a bit lower than the zipped collada file, but I understand what you’re getting at.

The reason I’m asking for documentation updates is because, like I said, we’re looking into generating URDF models and visualizing them in the browser and other platforms outside of ROS because it’s a nice, documented, and standard format that’s easy to parse and export. I feel that the density, robustness, and simplicity of use of the PLY format scratches that last itch that isn’t afforded by the other two mesh formats. I’m open to other format suggestions that scratch that, too, though!

Overall I’m pretty happy with URDF – I’m just trying to help the standard grow in a couple ways that accomodate my use cases! Especially if there’s not a lot of work investment to make it happen.

Thanks for your feedback!
Garrett