Currently, CollisionObjects are purely collision shapes, which are usually primitive shapes for performance reasons. However, we don't want our scenes to look like Minecraft, so I want to add a visual representation to objects in the scene, so that we can display complex geometries like this without calculating the collisions for every triangle. The robot and the environment objects already have this feature, but not the CollisionObjects that we add to the PlanningScene.

I would add the fields visual_geometry_mesh and visual_geometry_pose fields to the CollisionObject message, the world object and the AttachedBody. This is the simplest way and should be straight forward to implement. The only downside is that it might affect performance (visual mesh is kept in memory and copied with the world/AttachedBody objects) and that only one mesh can be used for visualization.

Regarding the restriction to a single mesh:
I think this is fine. If we wanted to allow more visual geometries, this would be a much bigger job and break API, so I don't want to do it. It wouldn't be worth it. (outline: split CollisionObject message into visual and collision geometry (like this), and in world/AttachedBody, split shapes_ and shape_poses_ vectors into visual and collision).

Regarding performance:
I think @rhaschke proposed (but I couldn't find where) to only pass in a mesh file location. That requires the mesh to be saved on disc and to be cached in ros_visualization. I would prefer not to implement it this way if it isn't necessary, since it might be premature optimization. Thoughts?

I looked at the visualization code, and using the VisualVisible/CollisionVisible flag to visualize the objects in planning_scene_render.cpp and robot_state_visualization.cpp won't be difficult. But I would like an opinion on the mesh vs mesh file consideration before I start. Thanks!