Scene: support deletion of Heightmap Visuals

[scpeters]

As noted in #3159, removing a model containing a heightmap causes its collision shape to be remove from the physics subsystem in gzserver, but the heightmap visual remains in gzclient. This pull request fixes that so that height map visuals should now disappear from gzclient when a heightmap model is deleted. The sequence of commits is described below:

• https://github.com/osrf/gazebo/commit/1445ab1d995cfbcaa425936768b4dce9e0cd5504: This was my first simple attempt to support removing the visual by storing the visual Id associated with the heightmap / terrain and adding logic in Scene::RemoveVisual to delete the terrain object when a visual matching terrainVisualId is removed. This didn't actually work.
• https://github.com/osrf/gazebo/commit/e497d4d41ae87ba5c2c613f684b1d14b480a60c7: This includes two fixes needed to allow removal of the heightmap visual: using a proper parent visual and adding the visual to the dataPtr::visuals vector. This code was already present elsewhere in ProcessVisualMsg, so I duplicated it to apply to the heightmap codepath. I didn't like this code duplication, so I worked to eliminate that in the following two commits.
• https://github.com/osrf/gazebo/commit/f3eaaeee12bdb884eb37fb8567045fae6f679015: This changes the Heightmap visual loading to use Visual::LoadFromMsg for consistency with the latter parts of ProcessVisualMsg. It requires construction of an extra boost::shared_ptr but I think the consistency is worth it.
• https://github.com/osrf/gazebo/commit/77bbc8c0814d6fb6d1d2c359696f6b9e860fe08c: This deduplicates the code by moving much of the heightmap processing code to the end of ProcessVisualMsg so it can share the existing portions that it had duplicated. This commit has a net reduction of 25 lines.

[scpeters]

The heightmap will never be visited because it isn't part of visuals.

it should be fixed by https://github.com/osrf/gazebo/commit/e497d4d41ae87ba5c2c613f684b1d14b480a60c7

[tekfr34k]

Thank you for fixing this as it's a functionality I need for a project. I might've spotted a bug however: When using ROS for:

• spawning an SDF model to add a heightmap into the scene
• deleting the heightmap from the scene again
• creating a new heightmap image
• spawning the SDF model again with the new heightmap (same name, no changes in config) into the scene

For some reason it uses the old visual representation (of the old heightmap) but the collisions work as intended (they're based on the new heightmap). A dirty work around that I'm using now is just to spawn the same new heightmap, delete it, then spawn it again, so that "buffer"-like anomaly disappears.

[tekfr34k]

Seems my previously described issue was caused by the cache problems with heightmaps similar to the comments in #2604. Deleting the ~/.gazebo/paging/MODELNAME folder within my script, each time I spawn a new heightmap fixed the problem without needing the workaround of double spawning (which didn't work that great after further testing).

[scpeters]

@tekfr34k can you open an issue describing how to reproduce the problem?

thanks!

[tekfr34k]

@scpeters I couldn't narrow down what exactly the problem is yet. The issue is very inconsistent, depending on if I start Gazebo from my launch scripts or just without any configuration at all it behaves differently. Maybe it has something to do with defining multiple model paths (even if the models are named differently in the SDF/config). Adding a model path in the "Insert" tab which contains the heightmap SDF gives an issue of not showing the model in the overview. Maybe that's something to start with...