Heightmap paging cache corruption when mixing LOD values

[scpeters]

Background

The gazebo::rendering::Heightmap class currently caches height values and writes them to the ~/.gazebo/paging folder and reads from this cache to speed up future loads. Some problems have been reported with this cache (such as https://github.com/osrf/gazebo/issues/2604), and a common workaround is to delete the entire ~/.gazebo/paging folder.

Summary of current bug

We have noticed that the Heightmap rendering can be distorted when loading large heightmaps (4096x4096 and larger) with both mixed zero and nonzero values of LOD in gzserver and gzclient. I believe this is related to the changes from bitbucket PR 2655 (merged in https://github.com/osrf/gazebo/commit/b5f39ee5949396951c260f993b4508a435485389). Some observations:

• When using gzserver to load a large heightmap with LOD == 0 with a freshly cleared ~/.gazebo/paging folder, it generates a new subfolder containing a gzterrain.SHA1 and a single gazebo_terrain_00000000.dat.
  • When loading gzclient with a matching value of LOD == 0, rendering is fine.
  • When loading gzclient with a nonzero value of LOD, rendering is distorted.
• When using a gzserver to load a large heightmap with LOD > 0 with a freshly cleaned ~/.gazebo/paging folder, it generates a new subfolder containing a gzterrain.SHA1 and multiple gazebo_terrain_*.dat files.
  • When loading gzclient also with a nonzero value of LOD, rendering is fine.
  • When loading gzclient with LOD == 0, rendering is distorted.

So perhaps we should be creating separate cache folders for LOD == 0 and LOD > 0? Or should we not use the cache if LOD == 0?

[scpeters]

Note that I used the changes in https://github.com/osrf/gazebo/pull/3120 to conveniently set LOD values for gzserver and gzclient