ROS2 URDF Mesh File Types

ROS ROS General
1

This is highly related to the discussion on this thread, but not really relevant to the title/stated purpose of the thread so I decided to make a new one.

With the release of Blender 5.0, the Collada (dae) format is no longer supported. Of course, we could use older versions of Blender or other applications entirely to edit these files. But this change marks a broader shift away from Collada which is explained in the thread linked above.

I understand that other mesh types, e.g. ply, glb, obj, can be effectively used with many ROS2 applications. That anything that the mesh loader (e.g. Assimp) will load will work. But for the purpose of guidance, I think it would be good if there is a new file format that is agreed upon for new meshes as an alternative to Collada.

The official guidance states the following:

Any geometry format is acceptable but specific application compatibility is dependent on implementation. The recommended format for best texture and color support is Collada .dae files.

Effectively what I am saying is that it would be good to add a new “officially recommended” file type alongside Collada. I am certainly not saying that support should be dropped for Collada in favor of something newer, but creating new Collada files is becoming more tedious so I think that another file type can be used for URDFs that are created in the future.

As a quick example of why I think it is important for a new file to be “officially recommended”, while glb files can be imported to Isaac Sim as a standalone, and glb can also be used as a URDF mesh type and displayed in RViz, the Isaac Sim URDF importer only supports dae, obj, and stl for the mesh types, so a URDF with glb is not easily importable. Presumably, if it was a recommended format, it would be supported by the URDF importer. I am sure that there are probably other applications with similar arbitrary limitations, but that is the first one that comes to mind.

With the disclaimer that I am not particularly familiar with different 3D file formats, I think that gLTF 2.0 (gltf/glb) makes sense. It is compact, widely supported, and supports meshes and textures in one file.

This change could start with just an addition to the quoted section above, but I don’t know the full implications of a change like this.

Are there difficulties that I am overlooking? I would appreciate thoughts on this.

3 Likes
ROS News for the Week of May 18th, 2026
2

You’re not overlooking much this is becoming a real interoperability problem across the ROS2 / simulation ecosystem.

.dae stayed “recommended” largely because of historical texture/material support and broad URDF compatibility, but the ecosystem is clearly moving toward glTF/glb. Blender dropping Collada support is probably the strongest signal so far.

The biggest issue right now isn’t whether glb works technically it often does but inconsistent downstream tooling support. As you mentioned, RViz may load glb fine through Assimp while Isaac Sim’s URDF importer still restricts formats to dae/obj/stl. That creates portability problems for teams trying to maintain a single robot description across ROS2, Gazebo, Isaac Sim, and MuJoCo workflows.

Personally I think glTF 2.0 (.gltf / .glb) makes the most sense as the future “recommended” format:

  • modern ecosystem support

  • compact binary packaging

  • embedded textures/materials

  • active tooling ecosystem

  • web/native rendering support

But the challenge is that robotics tooling evolves slower than graphics tooling, so simulator importers and URDF pipelines lag behind.

This is actually one of the reasons I started building tooling around URDF/simulation interoperability. A lot of robotics developers are now hitting:

  • mesh format incompatibilities

  • simulator-specific restrictions

  • URDF portability problems

  • conversion issues between Isaac/Gazebo/MuJoCo

I’ve been working on a robotics infrastructure tool called RoboInfra that focuses on these kinds of workflows (URDF validation/conversion/USD generation/mesh conversion/etc):

https://roboinfra-dashboard.azurewebsites.net

There’s also a free public validator here:

https://roboinfra-dashboard.azurewebsites.net/validator

So I definitely think the community needs clearer guidance on “future-safe” mesh formats for ROS2-era robot descriptions rather than relying on Collada indefinitely.

2 Likes
ROS News for the Week of May 25th, 2026
3

I am just now realizing that the official guidance that I linked is on the ROS1 wiki which is EOL and getting archived, so it would probably make more sense to have any sort of guidance changed alongside Long-Term Home for URDF XML Format Specification (related to ROS 1 Wiki EOL) · Issue #6235 · ros2/ros2_documentation · GitHub getting addressed.

Is there a better place to discuss the mesh file type, or create an issue?

4

I would also get on the bandwagon for GLB/GLTF, specifically for visual meshes, as it aligns with it being what I consider the most widely used 3D format for web visualization. USD and USDZ could also be documented as options, but I’d worry you start to get into some OS fragmentation, where USD has great Apple support, but less great elsewhere. Of course, thats all a matter of debate as well, but I’d still put my vote in for GLB.

As a secondary point, I’d retain STL as a recommended format, particularly for collision meshes where textures aren’t needed, and really shouldn’t be included. Its held up as a semi-universal format for geometry only (vertices and faces) , when you don’t necessarily care about visual appearance.

1 Like
5

I agree with the distinction between visual and collision meshes.

For visual assets, GLB/glTF feels like the strongest candidate going forward due to broad tooling support, modern material workflows, and adoption across web and real-time rendering ecosystems.

For collision geometry, STL still makes a lot of sense because simplicity and compatibility matter more than materials or textures. Most simulation pipelines ultimately reduce collision meshes to geometry anyway.

The bigger challenge is defining recommendations that work across the ROS ecosystem rather than around any single simulator. Today we have cases where one tool prefers DAE, another supports GLB, another prefers USD, and some importers only support a subset despite sharing similar mesh-loading infrastructure.

Maybe future guidance could separate recommendations by use case:

  • Visual meshes: GLB/glTF

  • Collision meshes: STL

  • USD/USDZ: optional where simulator workflows benefit from it

That would provide clearer guidance while still allowing simulator-specific optimizations.