Some STL meshes appear black since assimp was used to load them

[guihomework]

In noetic, some STL meshes appear black when others look fine. (so it is NOT the decimal point issue #1298 with colors being all black )

The behavior is not existing in melodic.

The reason was tracked down to be zero normals in the STL file as shown in this hexdiff

and the culprit was blender 2.69 which had a bug (already fixed) exporting empty normals in some cases. https://developer.blender.org/T39755

however this could still be the case in other STL in the world and would appear only with the use of assimp as it does not recompute the normals if they are zero as did the original internal script of rviz
https://github.com/ros-visualization/rviz/blob/melodic-devel/src/rviz/ogre_helpers/stl_loader.cpp#L209

There are three options

• Expect the world to find this issue and then fix their STLs , one way to do so is to re-export them using meshlab (thanks @rhaschke )

meshlabserver -i myfile.stl -o myfile.stl

this solves the display issue

• Add a check of the normal, and tell the world to fix their STL normals.
• Fix the normals if they are wrong as before.

maybe a combination of the last two options would be ideal for now.

Your environment

• OS Version: e.g. Ubuntu 18.04
• ROS Distro: [Melodic]
• RViz, Qt, OGRE, OpenGl version as printed by rviz:

rviz version 1.13.5
compiled against Qt version 5.9.5
compiled against OGRE version 1.9.0 (Ghadamon)
Forcing OpenGl version 0.
Stereo is NOT SUPPORTED 
OpenGl version: 4.5 (GLSL 4.5).

• If source build, which git commit?

04d4c5f

[rhaschke]

The STL loading was changed in #1365 to use assimp. Thus, this issue should affect all rviz releases >= 1.13.4, i.e. including the two latest melodic releases.

[rhaschke]

We already pass the post-processing flag aiProcess_GenNormals to the assimp importer. Looks like, assimp doesn't check for null normals.