Heightmap caching of geometry / textures is not documented, indicated, or overridable

[osrf-migration]

Original report (archived issue) by Tully Foote (Bitbucket: Tully Foote, GitHub: tfoote).

---

I was generating textured height maps and was having a really hard time debugging them since it seemed that anything I did didn't fix the rendering issue. Then I learned that the output was being cached. Which is why i would see intermittent changes but only if I changed the object name.

It would be great to see:

• that it's documented that caching is the default behavior. It's not mentioned in http://gazebosim.org/tutorials?tut=dem
  • It would be good to print something in at least the verbose console output that this is happening
  • It would be great to have an option to turn off the caching

As a workaround I've been running

rm -rf ~/.gazebo/paging/MODELNAME && gazebo ... when testing.

[scpeters]

I've been having some issues with cached heightmaps not loading textures properly when a different installation of gazebo is used. For example, if I use /usr/bin/gazebo from a debian package to load a heightmap for the first time, it will be cached in ~/.gazebo/paging. If I then open the same heightmap with gazebo compiled from source in a colcon workspace in my home folder, it will fail to load the textures and give errors in the ~/.gazebo/ogre.log file complaining that textures from /usr/share/gazebo-11 could not be found, since they aren't in the proper ogre resource path. It looks like the checksum used for the cache only considers the heights data structure and nothing about the texture paths

[scpeters]

cc @tfoote @iche033

[scpeters]

I too have found deleting the ~/.gazebo/paging folder the only way to fix the cache

[traversaro]

If I then open the same heightmap with gazebo compiled from source in a colcon workspace in my home folder, it will fail to load the textures and give errors in the ~/.gazebo/ogre.log file complaining that textures from /usr/share/gazebo-11 could not be found, since they aren't in the proper ogre resource path. It looks like the checksum used for the cache only considers the heights data structure and nothing about the texture paths

FYI @wolfv @Tobias-Fischer, as this sound like a failure mode that we could have also for users that run both Gazebo from apt and Gazebo from conda, even managing correctly their environments.

[lFatality]

I've ran into the same problem trying to change the textures of a heightmap. What led me to find the solution was running Gazebo (v11.3.0) in verbose mode which printed the message:

Loading heightmap cache data: /home/lfatality/.gazebo/paging/Apollo15/gazebo_terrain_00000000.dat

I think the cache update should be triggered on more occasions than just a change in height. The function Heightmap::PrepareTerrain creates the hash (during the load process of the heightmap, Heightmap::Load in gazebo/rendering/Heightmap.cc): . You can see that it only uses the heights to create the hash. https://github.com/osrf/gazebo/blob/c7f1a5d1d498700f5c7f4461fe98b1113ba0133d/gazebo/rendering/Heightmap.cc#L322

PrepareTerrain sets the variable terrainHashChanged, depending on if a change was detected. https://github.com/osrf/gazebo/blob/c7f1a5d1d498700f5c7f4461fe98b1113ba0133d/gazebo/rendering/Heightmap.cc#L595

This variable is then used to determine if a cache update has to be triggered. https://github.com/osrf/gazebo/blob/c7f1a5d1d498700f5c7f4461fe98b1113ba0133d/gazebo/rendering/Heightmap.cc#L841